[pgpool-general: 8295] Re: Timestamp cast not cached

[Avi Raboah]

Maybe it’s not a big issue.

But more than that the way postgresql using casting function is related to
the procvolatile.

I believe the solution for pgpool should be related to which casting
function postgres using.

In case the procvolatile for that cast function is “i” the query should be
cached and if the procvolatile is “s” it shouldn’t.

But maybe I am wrong.

Do your magic.

Thanks,

Avi

On Mon, 4 Jul 2022 at 14:36 Tatsuo Ishii <ishii at sraoss.co.jp> wrote:

> > Hi,
> >
> > I found some issue with timestamptz cast.
> > See the following:
> >
> > 1. Select ‘2022-02-18 07:00:00.006547+02’::timestamptz;
> >
> > 2. Select ‘2022-02-18 07:00:00.006547+02’::timestamptz; ―> will retrieved
> > from cache
> >
> > 3. Set time zone to ‘Some time zone’;
> >
> > 4. Select ‘2022-02-18 07:00:00.006547+02’::timestamptz; ―> will returned
> > from cache but shouldn’t because the time zone has been changed.
> >
> > I think the right behaviour should be that if we using cast which
> involved
> > timezone like timestamptz or timetz these queries shouldn’t saved in
> cache.
> >
> > What are your thoughts?
>
> You are right. Let me think about how to deal with the case.
>
> > Thanks,
> >
> > Avi.
> >
> > On Mon, 4 Jul 2022 at 11:41 Tatsuo Ishii <ishii at sraoss.co.jp> wrote:
> >
> >> Glad to hear that :-)
> >>
> >> > My mistake it’s working like a charm :)
> >> >
> >> > On Mon, 4 Jul 2022 at 11:32 Avi Raboah <avi.raboah at gmail.com> wrote:
> >> >
> >> >> I added the patch and it still not working.
> >> >> After your change the query
> >> >> Select ‘2022-02-18 07:00:00.006547’::timestamp;
> >> >>
> >> >> Still not cached
> >> >>
> >> >> On Mon, 4 Jul 2022 at 11:21 Tatsuo Ishii <ishii at sraoss.co.jp> wrote:
> >> >>
> >> >>> Hi,
> >> >>>
> >> >>> > Hi,
> >> >>> >
> >> >>> > I saw your patch thanks for that.
> >> >>>
> >> >>> You are welcome.
> >> >>>
> >> >>> > One question, in order to enable the not_used block you add, Do I
> >> need
> >> >>> to
> >> >>> > define this macro in the same page?
> >> >>>
> >> >>> No. You should *not* define NOT_USED symbol. Otherwise, the block
> will
> >> >>> be enabled, which is opposite to what the patch wants to do.
> >> >>>
> >> >>> > For example:
> >> >>> > #define NOT_USED
> >> >>> > #ifdef NOT_USED
> >> >>> > …
> >> >>> > …
> >> >>> > #endif
> >> >>> >
> >> >>> > Or I don’t need to add that ?
> >> >>> >
> >> >>> > Thanks,
> >> >>> >
> >> >>> > Avi.
> >> >>> >
> >> >>> > On Mon, 4 Jul 2022 at 9:54 Avi Raboah <avi.raboah at gmail.com>
> wrote:
> >> >>> >
> >> >>> >> Awesome, thanks!
> >> >>> >>
> >> >>> >> On Mon, 4 Jul 2022 at 9:52 Tatsuo Ishii <ishii at sraoss.co.jp>
> wrote:
> >> >>> >>
> >> >>> >>> > Thanks a lot for your fast reaponse!
> >> >>> >>> >
> >> >>> >>> > Do you know when the fix will be available?
> >> >>> >>>
> >> >>> >>> I have just pushed the fix. It will available in the next
> scheduled
> >> >>> >>> release (Aug 18).
> >> >>> >>>
> >> >>> >>> https://pgpool.net/mediawiki/index.php/Roadmap
> >> >>> >>>
> >> >>> >>> If you need patches, you can grab from the git repository.
> >> >>> >>>
> >> >>> >>> https://pgpool.net/mediawiki/index.php/Source_code_repository
> >> >>> >>>
> >> >>> >>> Best reagards,
> >> >>> >>> --
> >> >>> >>> Tatsuo Ishii
> >> >>> >>> SRA OSS, Inc. Japan
> >> >>> >>> English: http://www.sraoss.co.jp/index_en.php
> >> >>> >>> Japanese:http://www.sraoss.co.jp
> >> >>> >>>
> >> >>> >>
> >> >>>
> >> >>
> >>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.pgpool.net/pipermail/pgpool-general/attachments/20220704/308b4bae/attachment-0001.htm>