Re: pg14b1 stuck in lazy_scan_prune/heap_page_prune of pg_statistic

On Thu, 10 Jun 2021 at 19:43, Peter Geoghegan <pg(at)bowt(dot)ie> wrote:
>
> On Thu, Jun 10, 2021 at 10:29 AM Matthias van de Meent
> <boekewurm+postgres(at)gmail(dot)com> wrote:
> > I see one exit for HEAPTUPLE_DEAD on a potentially recently committed
> > xvac (?), and we might also check against recently committed
> > transactions if xmin == xmax, although apparently that is not
> > implemented right now.
>
> I don't follow. Perhaps you can produce a test case?

If you were to delete a tuple in the same transaction that you create
it (without checkpoints / subtransactions), I would assume that this
would allow us to vacuum the tuple, as the only snapshot that could
see the tuple must commit or roll back. In any case, inside the
transaction the tuple is not visible anymore, and outside the
transaction the tuple will never be seen. That being the case, any
such tuple that has xmin == xmax should be vacuumable at any time,
except that you might want to wait for the transaction to have
committed/rolled back to prevent any race conditions with (delayed)
index insertions.

example:

BEGIN;
INSERT INTO tab VALUES (1);
DELETE FROM tab;
-- At this point, the tuple inserted cannot be seen in any
-- current or future snapshot, and could thus be vacuumed.
COMMIT;

Because I am not quite yet well versed with the xid assignment and
heapam deletion subsystems, it could very well be that either this
case is impossible to reach, or that the heapam tuple delete logic
already applies this at tuple delete time.

With regards,

Matthias van de Meent