Re: Duplicated LSN in ReorderBuffer - Mailing list pgsql-hackers

From Alvaro Herrera
Subject Re: Duplicated LSN in ReorderBuffer
Date
Msg-id 20190726224635.GA26091@alvherre.pgsql
Whole thread Raw
In response to Re: Duplicated LSN in ReorderBuffer  (Masahiko Sawada <sawada.mshk@gmail.com>)
Responses Re: Duplicated LSN in ReorderBuffer  (Andres Freund <andres@anarazel.de>)
List pgsql-hackers
On 2019-Jul-09, Masahiko Sawada wrote:

> I think the cause of this bug would be that a ReorderBufferTXN entry
> of sub transaction is created as top-level transaction. And this
> happens because we skip to decode ASSIGNMENT during the state of
> snapshot builder < SNAPBUILD_FULL.

That explanation seems to make sense.

> Instead, I wonder if we can decode ASSIGNMENT even when the state of
> snapshot builder < SNAPBUILD_FULL_SNAPSHOT. That way, the
> ReorderBufferTXN entries of both top transaction and sub transaction
> are created properly before we decode NEW_CID.

Yeah, that seems a sensible remediation to me.

I would reduce the scope a little bit -- only create the assignment in
the BUILDING state, and skip it in the START state.  I'm not sure that
it's possible to get assignments while in START state that are
significant (I'm still trying to digest SnapBuildFindSnapshot).

I would propose the attached.  Andres, do you have an opinion on this?

-- 
Álvaro Herrera                https://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

Attachment

pgsql-hackers by date:

Previous
From: Alvaro Herrera
Date:
Subject: Re: Attached partition not considering altered column properties ofroot partition.
Next
From: Andres Freund
Date:
Subject: Re: TopoSort() fix