[pgpool-general: 9453] Re: Clarification on query results cache visibility

[Achilleas Mantzios]

On 4/30/25 10:49, Achilleas Mantzios - cloud wrote:

>
> On 4/30/25 09:40, Achilleas Mantzios - cloud wrote:
>>
>>
>> On 4/30/25 08:12, Achilleas Mantzios - cloud wrote:
>>> On 4/30/25 07:48, Tatsuo Ishii wrote:
>>>
>>>>>>> Thank you a lot for such a quick response ! I applied, and 
>>>>>>> re-run the
>>>>>>> test, it works correctly.
>>>>>>>
>>>>>>> We will keep testing as in live conditions, with wildfly , etc.
>>>> I have updated the patch. In the previous patch, information on
>>>> whether the query is "cache safe", which means it is safe to cache the
>>>> result of the query, is checked on the global state. Attached patch
>>>> instead checks it directly on the information contained in the bind
>>>> message data, which is an argument of the function responsible for
>>>> processing execute messages. In most cases the global state is synced
>>>> with the bind state, but obtaining information from the bind message
>>>> is safer.
>>>
>>> Ok, I applied and restarted, thank you!
>>>
>>> Now the cache seems very robust, and fast.
>>
>> Unfortunately the 2nd patch (query_cache-v2.patch) broke something. 
>> Cannot figure yet.
>>
>> Reverting to the previous patch (yesterday) : query_cache.patch Rev, 
>> seems to work correctly.
>>
>> The scenario involved arrays (pgsql int[] ). (and intarray 
>> extension). I dont know if I am able to do anything (debug) today, 
>> due to immense work load.
>>
> update the bug is in there no matter the patch's version, will keep 
> testing.

update : the bug (this new bug) is not present prior to the first patch. 
So the bug (the new one) is not present in plain vanilla : 
pgpool-II-4.6.0 . Reverting both patches solves the issue with the new 
bug which has most probably to do with an array function called "first" :

select defid, description from machdefs where first(parents)=214766150 
order by description;

I haven't been able to reproduce with SQL (from psql).

Also reverting both patches, i.e. going back to plain vanilla 
pgpool-II-4.6.0 solves this new bug, but re-introduces the previous ( 
with seeing stale and data and not invalidate data on table testpgpool)

>>>
>>>>
>>>> Best regards,
>>>> -- 
>>>> Tatsuo Ishii
>>>> SRA OSS K.K.
>>>> English: http://www.sraoss.co.jp/index_en/
>>>> Japanese:http://www.sraoss.co.jp
>>> _______________________________________________
>>> pgpool-general mailing list
>>> pgpool-general at pgpool.net
>>> http://www.pgpool.net/mailman/listinfo/pgpool-general
>>
>> _______________________________________________
>> pgpool-general mailing list
>> pgpool-general at pgpool.net
>> http://www.pgpool.net/mailman/listinfo/pgpool-general
>
> _______________________________________________
> pgpool-general mailing list
> pgpool-general at pgpool.net
> http://www.pgpool.net/mailman/listinfo/pgpool-general
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.pgpool.net/pipermail/pgpool-general/attachments/20250430/6132ce75/attachment-0001.htm>