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

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Andres Freund <andres(at)anarazel(dot)de>, Justin Pryzby <pryzby(at)telsasoft(dot)com>, Kyotaro Horiguchi <horikyota(dot)ntt(at)gmail(dot)com>, Erik Rijkers <er(at)xs4all(dot)nl>, Matthias van de Meent <boekewurm+postgres(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: TRAP: FailedAssertion("HaveRegisteredOrActiveSnapshot()", File: "toast_internals.c", Line: 670, PID: 19403)
Date: 2022-04-18 15:14:48
Message-ID: CA+Tgmoa3Z+DgdvW2Lp9S=NbYFa53tXioe9SUDh6ozixUmGaF5g@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Mon, Apr 18, 2022 at 10:53 AM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> > I still think it would be better to have GetOldestSnapshot() be
> > smarter and refuse to return the catalog snapshot. For one thing, that
> > way we'd be testing for the problem case in non-assert builds also.
>
> I was wondering about that too. On the other hand, given that
> we know this area is squishy, transforming fails-in-assert-builds
> to fails-everywhere is not necessarily desirable.

I agree that it's a little unclear. In general, I think if we're going
to blow up and die, doing it closer to the place where the problem is
happening is for the best. On the other hand, if in most practical
cases we're going to stumble through and get the right answer anyway,
then it's maybe not great to break a bunch of accidentally-working
cases. However, it does strikes me that this principal could easily be
overdone. init_toast_snapshot() could pick a random snapshot (or take
a new one) in order to call InitToastSnapshot() and that would often
work fine. Yet, upon realizing that things are busted, it chooses to
error out instead. I approve of that choice, and don't think we should
rule out the idea of making that check more robust.

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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Stephen Frost 2022-04-18 15:18:00 Re: pg_walcleaner - new tool to detect, archive and delete the unneeded wal files (was Re: pg_archivecleanup - add the ability to detect, archive and delete the unneeded wal files on the primary)
Previous Message Bharath Rupireddy 2022-04-18 15:05:49 Re: pg_walcleaner - new tool to detect, archive and delete the unneeded wal files (was Re: pg_archivecleanup - add the ability to detect, archive and delete the unneeded wal files on the primary)