Re: [PATCH] VACUUM: avoid pre-creation transactions holding back cleanup of newly created relations

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

In response to

Responses

Browse pgsql-hackers by date

  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]