Re: Tuples inserted and deleted by the same transaction

From: Laurenz Albe <laurenz(dot)albe(at)cybertec(dot)at>
To: Matthias van de Meent <boekewurm+postgres(at)gmail(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Nikita Malakhov <hukutoc(at)gmail(dot)com>, pgsql-hackers(at)lists(dot)postgresql(dot)org
Subject: Re: Tuples inserted and deleted by the same transaction
Date: 2022-09-13 17:06:02
Message-ID: 4365e20c6826a8b3e7da1f0c2056676cfd217c73.camel@cybertec.at
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Tue, 2022-09-13 at 16:13 +0200, Matthias van de Meent wrote:
> On Tue, 13 Sept 2022 at 15:45, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> > Laurenz Albe <laurenz(dot)albe(at)cybertec(dot)at> writes:
> > > But once they are deleted or updated, even the transaction that created them cannot
> > > see them any more, right?
> >
> > I would not trust that claim very far.  The transaction might have active
> > snapshots with a command ID between the times of insertion and deletion.
> > (Consider a query that is firing triggers as it goes, and the triggers
> > are performing new actions that cause the command counter to advance.
> > The outer query should not see the results of those actions.)
>
> I hadn't realized that triggers indeed consume command ids but might
> not be visible to the outer query (that might still be running). That
> invalidates the "or (e.g.) the existence of another tuple with the
> same XID but with a newer CID" claim I made earlier, so thanks for
> clarifying.

Yes, that makes sense. Thanks.

Yours,
Laurenz Albe

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Alexander Korotkov 2022-09-13 17:50:20 Re: Making pg_rewind faster
Previous Message Jacob Champion 2022-09-13 16:52:04 Re: [PATCH] Log details for client certificate failures