Horton
Menu

Re: Assertion failure in SnapBuildInitialSnapshot()

Amit Kapila <amit.kapila16@gmail.com>

View thread
From: Amit Kapila <amit.kapila16@gmail.com>
To: Andres Freund <andres@anarazel.de>
Cc: PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>, Sawada Masahiko <sawada.mshk@gmail.com>, kuroda.hayato@fujitsu.com, Thomas Munro <thomas.munro@gmail.com>
Date: 2022-11-16T08:52:01Z
Lists: pgsql-hackers 
On Wed, Nov 16, 2022 at 7:30 AM Andres Freund <andres@anarazel.de> wrote:
>
> On 2022-11-15 16:20:00 +0530, Amit Kapila wrote:
> > On Tue, Nov 15, 2022 at 8:08 AM Andres Freund <andres@anarazel.de> wrote:
> > > nor do we enforce in an obvious place that we
> > > don't already hold a snapshot.
> > >
> >
> > We have a check for (FirstXactSnapshot == NULL) in
> > RestoreTransactionSnapshot->SetTransactionSnapshot. Won't that be
> > sufficient?
>
> I don't think that'd e.g. catch a catalog snapshot being held, yet that'd
> still be bad. And I think checking in SetTransactionSnapshot() is too late,
> we've already overwritten MyProc->xmin by that point.
>

So, shall we add the below Asserts in SnapBuildInitialSnapshot() after
we have the Assert for Assert(!FirstSnapshotSet)?
Assert(FirstXactSnapshot == NULL);
Assert(!HistoricSnapshotActive());

-- 
With Regards,
Amit Kapila.

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →

  1. Fix a race condition in updating procArray->replication_slot_xmin.

  2. Don't retreat slot's confirmed_flush LSN.

  3. Add additional checks while creating the initial decoding snapshot.