| 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: | Whole Thread | Raw Message | 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
| 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 |