Re: Accept invalidation messages before the query starts inside a transaction - Mailing list pgsql-hackers

From Andrei Lepikhov
Subject Re: Accept invalidation messages before the query starts inside a transaction
Date
Msg-id 7f3d0270-380b-46a8-bd41-34f3328b7fb7@gmail.com
Whole thread Raw
In response to Re: Accept invalidation messages before the query starts inside a transaction  ("David G. Johnston" <david.g.johnston@gmail.com>)
List pgsql-hackers
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




pgsql-hackers by date:

Previous
From: Maxim Orlov
Date:
Subject: Re: Add 64-bit XIDs into PostgreSQL 15
Next
From: Aleksander Alekseev
Date:
Subject: Re: [PATCH] Refactor SLRU to always use long file names