Re: Bugs in pgoutput.c - Mailing list pgsql-hackers

From Robert Haas
Subject Re: Bugs in pgoutput.c
Date
Msg-id CA+TgmoZopS7mn_fCAj5Lmn9r=7E-k71=V1TAOSR1fmPKXaPK=Q@mail.gmail.com
Whole thread Raw
In response to Re: Bugs in pgoutput.c  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On Thu, Jan 6, 2022 at 2:58 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
> That might be okay for the system catalog entries, but I don't see
> how it prevents some other session from dropping the table entirely,
> thereby causing the on-disk storage to go away.  Is it guaranteed
> that logical decoding will never try to fetch any on-disk data?
> (I can sort of believe that that might be true, but there are scary
> corner cases for toasted data, such as an UPDATE that carries forward
> a pre-existing toast datum.)

If I'm not mistaken, logical decoding is only allowed to read data
from system catalog tables or tables that are flagged as being "like
system catalog tables for logical decoding purposes only". See
RelationIsAccessibleInLogicalDecoding and
RelationIsUsedAsCatalogTable. As far as the actual table data is
concerned, it has to be reconstructed solely from the WAL.

I am not sure what locking is required here and am not taking a
position on that ... but it's definitely not the case that a logical
decoding plugin can decide to just read from any old table it likes.

-- 
Robert Haas
EDB: http://www.enterprisedb.com



pgsql-hackers by date:

Previous
From: "Joel Jacobson"
Date:
Subject: Re: pl/pgsql feature request: shorthand for argument and local variable references
Next
From: Pavel Stehule
Date:
Subject: Re: pl/pgsql feature request: shorthand for argument and local variable references