Re: Odd Shortcut behaviour in PG14

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Zahir Lalani <ZahirLalani(at)oliver(dot)agency>
Cc: Ron Johnson <ronljohnsonjr(at)gmail(dot)com>, "pgsql-generallists(dot)postgresql(dot)org" <pgsql-general(at)lists(dot)postgresql(dot)org>
Subject: Re: Odd Shortcut behaviour in PG14
Date: 2023-11-24 15:34:45
Message-ID: 3307508.1700840085@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

Zahir Lalani <ZahirLalani(at)oliver(dot)agency> writes:
> Looking at the application logs this function is being called once per
> display row - it is running successfully around 10 times with the same
> input params. When it fails, it is with the same params!

You *still* haven't defined what you mean by "fails". We can't help
you effectively with such tiny dribs and drabs of information.
At the very least I'd like to see the whole query, because the
fragment you've shown us does not reveal what ekey is or why you
think the system should believe that it is or is not zero.
But it's also unclear why that should matter.

Having said that ... if the statement is being executed with a cached
plan (via a named statement, or PREPARE, or inside plpgsql) then
maybe the problem occurs if the plan switches from custom to generic?
If so, messing with the plan_cache_mode setting might provide a
workaround.

regards, tom lane

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Les 2023-11-24 15:59:55 Re: replication primary writting infinite number of WAL files
Previous Message Laurenz Albe 2023-11-24 15:00:40 Re: replication primary writting infinite number of WAL files