Horton

Re: TRAP: FailedAssertion("HaveRegisteredOrActiveSnapshot()", File: "toast_internals.c", Line: 670, PID: 19403)

Andres Freund <andres@anarazel.de>

View thread View on postgr.es
From: Andres Freund <andres@anarazel.de>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Robert Haas <robertmhaas@gmail.com>, Justin Pryzby <pryzby@telsasoft.com>, Kyotaro Horiguchi <horikyota.ntt@gmail.com>, Erik Rijkers <er@xs4all.nl>, Matthias van de Meent <boekewurm+postgres@gmail.com>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Date: 2022-04-15T01:30:10Z
Lists: pgsql-hackers 
Hi,

On 2022-04-14 15:05:50 -0400, Tom Lane wrote:
> Andres' complaint is that that snapshot might get invalidated when you
> weren't expecting it, but I'm not really convinced that we have all
> that many bugs of that ilk.  Wouldn't CLOBBER_CACHE_ALWAYS testing
> find them?

Don't see why it would - we don't have any mechanism in place for
enforcing that we don't update / delete a tuple we've looked up with an
xmin that wasn't continually enforced.  A typical pattern is to use a
catalog cache (registered an all) for a syscache lookup, but then not
have a registered / active snapshot until an eventual update / delete
(after the syscache scan ends). Which isn't safe, because without a
MyProc->xmin set, the tuple we're updating / deleting could be updated,
removed and replaced with another tuple.

Greetings,

Andres Freund

Commits

  1. Fix incorrect logic in HaveRegisteredOrActiveSnapshot().

  2. Fix temporary object cleanup failing due to toast access without snapshot.

  3. Account for catalog snapshot in PGXACT->xmin updates.