MIME-Version: 1.0
References: <dbebe820-eec3-d643-aab7-26a33392c27b@xs4all.nl>
 <20220330.100617.1491348930290941094.horikyota.ntt@gmail.com>
 <20220330.114613.1177577626285014184.horikyota.ntt@gmail.com>
 <20220330.175824.936439875658680065.horikyota.ntt@gmail.com>
 <20220413202819.GR26620@telsasoft.com> <20220414003802.e37dgzkgbi5t7ha4@alap3.anarazel.de>
 <CA+TgmoZ1P5XxBvk1sU9s5hpHXAZf8u5oHTP1+h_otx2kHaG9QQ@mail.gmail.com>
 <1471620.1649947373@sss.pgh.pa.us> <CA+TgmoagKyvcMip+thF8JS0Jc9kAnQnZS0xBpTetixRukdh=qg@mail.gmail.com>
 <1484483.1649951206@sss.pgh.pa.us>
In-Reply-To: <1484483.1649951206@sss.pgh.pa.us>
From: Robert Haas <robertmhaas@gmail.com>
Date: Thu, 14 Apr 2022 12:16:45 -0400
Message-ID: <CA+TgmoaLb0j9zEfkk6bmuKM5422JenzzcJLJSiPLgwfMd+xnBw@mail.gmail.com>
Subject: Re: TRAP: FailedAssertion("HaveRegisteredOrActiveSnapshot()", File:
 "toast_internals.c", Line: 670, PID: 19403)
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Andres Freund <andres@anarazel.de>, 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>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <https://www.postgresql.org/message-id/CA%2BTgmoaLb0j9zEfkk6bmuKM5422JenzzcJLJSiPLgwfMd%2BxnBw%40mail.gmail.com>
Precedence: bulk

On Thu, Apr 14, 2022 at 11:46 AM Tom Lane <tgl@sss.pgh.pa.us> wrote:
> I don't think Andres had any intention of ignoring it indefinitely.
> What he is doing is prioritizing it lower than several of the other
> open items, an opinion I fully agree with.

Well, my point is that, historically, relegating things to the older
bugs section often means nothing happens, which I think would not be
great in this case. However, I'll try to shut up about the procedural
issues for the moment, since I seem to be in the minority.

I got curious and looked at the underlying problem here and I am
wondering whether HaveRegisteredOrActiveSnapshot() is just buggy. It
seems to me that the code is always going to return true if there are
any active snapshots, and the rest of the function is intended to test
whether there is a registered snapshot other than the catalog
snapshot. But I don't think that's what this code does:

     if (pairingheap_is_empty(&RegisteredSnapshots) ||
         !pairingheap_is_singular(&RegisteredSnapshots))
         return false;

     return CatalogSnapshot == NULL;

So, if there are 0 active snapshots we return false. And if there is 1
active snapshot then we return true if there's no catalog snapshot and
otherwise false. So far so good. But if there are 2 or more registered
snapshots then the pairing heap will be neither empty nor singular so
it seems to me we will return false, which seems to me to be the wrong
answer. I tried this:

diff --git a/src/backend/utils/time/snapmgr.c b/src/backend/utils/time/snapmgr.c
index a0be0c411a..4e8e26a362 100644
--- a/src/backend/utils/time/snapmgr.c
+++ b/src/backend/utils/time/snapmgr.c
@@ -1646,9 +1646,10 @@ HaveRegisteredOrActiveSnapshot(void)
      * removed at any time due to invalidation processing. If explicitly
      * registered more than one snapshot has to be in RegisteredSnapshots.
      */
-    if (pairingheap_is_empty(&RegisteredSnapshots) ||
-        !pairingheap_is_singular(&RegisteredSnapshots))
+    if (pairingheap_is_empty(&RegisteredSnapshots))
         return false;
+    if (!pairingheap_is_singular(&RegisteredSnapshots))
+        return true;

     return CatalogSnapshot == NULL;
 }

I find that 'make check-world' passes with this change, which is
disturbing, because it also passes without this change. That means we
don't have any tests that reach HaveRegisteredOrActiveSnapshot() with
more than one registered snapshot.

Also, unless we have plans to use HaveRegisteredOrActiveSnapshot() in
more places, I think we should consider revising the whole approach
here. The way init_toast_snapshot() is coded, we basically have some
code that tests for active and registered snapshots and finds the
oldest one. We error out if there isn't one. And then we get to this
assertion, which checks the same stuff a second time but with an
additional check to see whether we ended up with the catalog snapshot.
Wouldn't it make more sense if GetOldestSnapshot() just refused to
return the catalog snapshot in the first place?

-- 
Robert Haas
EDB: http://www.enterprisedb.com