Re: Eliminating SPI from RI triggers - take 2 - Mailing list pgsql-hackers

From Amit Langote
Subject Re: Eliminating SPI from RI triggers - take 2
Date
Msg-id CA+HiwqEgtt=ry=ns6cVbjUgRHjX09-bDf6Z36h9qumYh3_v7KQ@mail.gmail.com
Whole thread Raw
In response to Re: Eliminating SPI from RI triggers - take 2  (Amit Langote <amitlangote09@gmail.com>)
Responses Re: Eliminating SPI from RI triggers - take 2
List pgsql-hackers
On Wed, Jul 13, 2022 at 8:59 PM Amit Langote <amitlangote09@gmail.com> wrote:
> On Sat, Jul 9, 2022 at 1:15 AM Robert Haas <robertmhaas@gmail.com> wrote:
> Thanks for taking a look at this.  I'll try to respond to other points
> in a separate email, but I wanted to clarify something about below:
>
> > I find my ego slightly wounded by the comment that "the partition
> > descriptor machinery has a hack that assumes that the queries
> > originating in this module push the latest snapshot in the
> > transaction-snapshot mode." It's true that the partition descriptor
> > machinery gives different answers depending on the active snapshot,
> > but, err, is that a hack, or just a perfectly reasonable design
> > decision?
>
> I think my calling it a hack of "partition descriptor machinery" is
> not entirely fair (sorry), because it's talking about the following
> comment in find_inheritance_children_extended(), which describes it as
> being a hack, so I mentioned the word "hack" in my comment too:
>
>         /*
>          * Cope with partitions concurrently being detached.  When we see a
>          * partition marked "detach pending", we omit it from the returned set
>          * of visible partitions if caller requested that and the tuple's xmin
>          * does not appear in progress to the active snapshot.  (If there's no
>          * active snapshot set, that means we're not running a user query, so
>          * it's OK to always include detached partitions in that case; if the
>          * xmin is still running to the active snapshot, then the partition
>          * has not been detached yet and so we include it.)
>          *
>          * The reason for this hack is that we want to avoid seeing the
>          * partition as alive in RI queries during REPEATABLE READ or
>          * SERIALIZABLE transactions: such queries use a different snapshot
>          * than the one used by regular (user) queries.
>          */
>
> That bit came in to make DETACH CONCURRENTLY produce sane answers for
> RI queries in some cases.
>
> I guess my comment should really have said something like:
>
> HACK: find_inheritance_children_extended() has a hack that assumes
> that the queries originating in this module push the latest snapshot
> in transaction-snapshot mode.

Posting a new version with this bit fixed; cfbot complained that 0002
needed a rebase over 3592e0ff98.

I will try to come up with a patch to enhance the PartitionDirectory
interface to allow passing the snapshot to use when scanning
pg_inherits explicitly, so we won't need the above "hack".

--
Thanks, Amit Langote
EDB: http://www.enterprisedb.com

Attachment

pgsql-hackers by date:

Previous
From: Andres Freund
Date:
Subject: Re: Cleaning up historical portability baggage
Next
From: Amit Kapila
Date:
Subject: Re: [PATCH] Use indexes on the subscriber when REPLICA IDENTITY is full on the publisher