Thread: Re: Accept invalidation messages before the query starts inside a transaction
Re: Accept invalidation messages before the query starts inside a transaction
From
"David G. Johnston"
Date:
On Wednesday, September 11, 2024, Andrei Lepikhov <lepihov@gmail.com> wrote:
I don't know whether to classify this as a bug.
[1] https://www.postgresql.org/docs/16/mvcc-caveats.html
Seems we need to add another sentence to that final paragraph. Something like:
However, once an object is accessed within a transaction its definition is cached for the duration of the transaction. Of particular note are routine bodies modified using create or replace. If a replacement gets committed mid-transaction the old code body will still be executed for the remainder of the transaction.
David J.
Re: Accept invalidation messages before the query starts inside a transaction
From
Andrei Lepikhov
Date:
On 12/9/2024 08:31, David G. Johnston wrote: > On Wednesday, September 11, 2024, Andrei Lepikhov <lepihov@gmail.com > <mailto:lepihov@gmail.com>> wrote: > > > I don't know whether to classify this as a bug. > > [1] https://www.postgresql.org/docs/16/mvcc-caveats.html > <https://www.postgresql.org/docs/16/mvcc-caveats.html> > > > Seems we need to add another sentence to that final paragraph. > Something like: > > However, once an object is accessed within a transaction its definition > is cached for the duration of the transaction. Of particular note are > routine bodies modified using create or replace. If a replacement gets > committed mid-transaction the old code body will still be executed for > the remainder of the transaction. I'm not sure we need any changes here yet unless Yurii provides an example of a real issue. But for the record, let me explain the initial reason in more detail. Extensions have always been challenging to maintain because they include hook calls from the core and stored procedures visible in databases where the extension was created. At the same time, we should control the UPDATE/DROP/CREATE extension commands. And don't forget, we have some data in shared memory as well that can't be easily versioned. Our primary goal is to establish a stable point that can provide extension developers (and users who call their functions) with a reliable guarantee that we are up to date with all the changes made to the extension. Last week, Michael Paquer's patch introduced sys caches and invalidation callbacks to watch such actions. But curiously, while we just execute some extension's functions like: SELECT pg_extension.smth() we don't lock any table, don't apply invalidation messages at all, don't have an information about updating/altering/deletion of our extension's objects! -- regards, Andrei Lepikhov