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>
In-Reply-To: <1471620.1649947373@sss.pgh.pa.us>
From: Robert Haas <robertmhaas@gmail.com>
Date: Thu, 14 Apr 2022 11:33:45 -0400
Message-ID: <CA+TgmoagKyvcMip+thF8JS0Jc9kAnQnZS0xBpTetixRukdh=qg@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%2BTgmoagKyvcMip%2BthF8JS0Jc9kAnQnZS0xBpTetixRukdh%3Dqg%40mail.gmail.com>
Precedence: bulk

On Thu, Apr 14, 2022 at 10:42 AM Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Robert Haas <robertmhaas@gmail.com> writes:
> > On Wed, Apr 13, 2022 at 8:38 PM Andres Freund <andres@anarazel.de> wrote:
> >> FWIW, that'd just mean it's an old bug that wasn't easily noticeable
> >> before, not that it's the fault of 277692220.
>
> > I think you're still on the hook to do something about it for this
> > release.
>
> I think you're trying to shoot the messenger.  As Andres says,
> 277692220 just exposes that there is some pre-existing bug here.
> It's probably related to 84f5c2908, so I was planning to take a
> look at it at some point, but there are a few other higher-priority
> bugs in the way.

Well, if you're willing to look at it that's fine, but I just don't
agree that it's OK to just commit things that add failing assertions
and drive off into the sunset. The code is always going to have a
certain number of unfixed bugs, and that's fine, and finding them is
good in itself, but people want to be able to run the software in the
meantime, and some of those people are developers or other individuals
who want to run it with assertions enabled. It's a judgement call
whether this assertion failure is going to bite enough people to be a
problem, but if it were something that happened easily enough to
prevent you from working on the source code, I'm sure you wouldn't be
OK with leaving it in there until someone got around to looking at it.
Given that it took about a month and a half for someone to report them
problem, it's not as bad as all that, but I guess I won't be surprised
if we keep getting complaints until something gets done.

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