Re: Accept invalidation messages before the query starts inside a transaction

On 12/9/2024 08:31, David G. Johnston wrote:
> On Wednesday, September 11, 2024, Andrei Lepikhov <lepihov(at)gmail(dot)com
> <mailto:lepihov(at)gmail(dot)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