From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Simon Riggs <simon(dot)riggs(at)enterprisedb(dot)com> |
Cc: | PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Pruning never visible changes |
Date: | 2022-09-16 14:26:29 |
Message-ID: | 3677239.1663338389@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Simon Riggs <simon(dot)riggs(at)enterprisedb(dot)com> writes:
> A user asked me whether we prune never visible changes, such as
> BEGIN;
> INSERT...
> UPDATE.. (same row)
> COMMIT;
Didn't we just have this discussion in another thread? You cannot
do that, at least not without checking that the originating
transaction has no snapshots that could see the older row version.
I'm not sure whether or not snapmgr.c has enough information to
determine that, but in any case this formulation is surely
unsafe, because it isn't even checking whether that transaction is
our own, let alone asking snapmgr.c.
I'm dubious that a safe version would fire often enough to be
worth the cycles spent.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2022-09-16 14:29:38 | Re: BUG #17448: In Windows 10, version 1703 and later, huge_pages doesn't work. |
Previous Message | Maxim Orlov | 2022-09-16 13:59:04 | Re: Add 64-bit XIDs into PostgreSQL 15 |