| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Victor Yegorov <vyegorov(at)gmail(dot)com> |
| Cc: | Pierre Forstmann <pierre(dot)forstmann(at)gmail(dot)com>, pgsql-general <pgsql-general(at)postgresql(dot)org> |
| Subject: | Re: Unexpected results from CALL and AUTOCOMMIT=off |
| Date: | 2024-06-03 19:28:10 |
| Message-ID: | 90052.1717442890@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-general pgsql-hackers |
Victor Yegorov <vyegorov(at)gmail(dot)com> writes:
> пн, 3 июн. 2024 г. в 20:40, Pierre Forstmann <pierre(dot)forstmann(at)gmail(dot)com>:
>> If you remove stable from function declaration, it works as expected:
> ... therefore I assume STABLE should work in this case. Well, it seems not
> to.
I agree that this looks like a bug, since your example shows that the
same function works as-expected in an ordinary expression but not in
a CALL. The dependency on AUTOCOMMIT (that is, being within an outer
transaction block) seems even odder. I've not dug into it yet, but
I suppose we're passing the wrong snapshot to the CALL arguments.
A volatile function wouldn't use that snapshot, explaining Pierre's
result.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2024-06-04 01:32:28 | Re: Unexpected results from CALL and AUTOCOMMIT=off |
| Previous Message | Victor Yegorov | 2024-06-03 18:15:07 | Re: Unexpected results from CALL and AUTOCOMMIT=off |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Nathan Bossart | 2024-06-03 19:28:13 | Re: allow changing autovacuum_max_workers without restarting |
| Previous Message | David E. Wheeler | 2024-06-03 19:21:04 | Re: Proposal: Document ABI Compatibility |