| From: | Andres Freund <andres(at)anarazel(dot)de> |
|---|---|
| To: | Melanie Plageman <melanieplageman(at)gmail(dot)com> |
| Cc: | Mikhail Kharitonov <mikhail(dot)kharitonov(dot)dev(at)gmail(dot)com>, pgsql-hackers(at)lists(dot)postgresql(dot)org |
| Subject: | Re: [PATCH] VACUUM: avoid pre-creation transactions holding back cleanup of newly created relations |
| Date: | 2025-12-09 19:25:44 |
| Message-ID: | 6rze5qbzj5rjax4aqkqtjyxierlympkl5l42yw74kh4qyz3c2v@gfizkrng2yim |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Hi,
On 2025-12-09 14:10:24 -0500, Melanie Plageman wrote:
> I'll start by admitting that I am not sure exactly how to do this
> feature correctly.
Isn't the whole idea that it would be safe to allow freezing in this case
incorrect? Consider the following scenario:
A1: BEGIN TRANSACTION ISOLATION LEVEL REPEATABLE READ; SELECT;
B1: CREATE TABLE foo AS SELECT random();
B2: VACUUM FREEZE foo;
A2: SELECT * FROM foo;
If you allowed freezing of the rows in B2, A2 will see the rows as visible,
despite them not being supposed to be visible.
Note that the catalog lookup during A2 will actually see the catalog data, as
we always use a recent snapshot for catalog lookups (and a lot of stuff would
otherwise be broken).
Greetings,
Andres Freund
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Melanie Plageman | 2025-12-09 19:31:09 | Re: [PATCH] VACUUM: avoid pre-creation transactions holding back cleanup of newly created relations |
| Previous Message | Alvaro Herrera | 2025-12-09 19:22:09 | Re: Adding REPACK [concurrently] |