Re: Issue in GIN fast-insert: XLogBeginInsert + Read/LockBuffer ordering

On 2022-Oct-13, Michael Paquier wrote:

> On Wed, Oct 12, 2022 at 08:54:34PM -0400, Tom Lane wrote:
> > Don't we need to back-patch these fixes?
> 
> I guess I should, though I have finished by not doing due to the
> unlikeliness of the problem, where we would need the combination of a
> page eviction with an error in the critical section to force a PANIC,
> or a crash before the WAL gets inserted.  Other opinions?

I suppose it's a matter of whether any bugs are possible outside of
Neon.  If yes, then definitely this should be backpatched.  Offhand, I
don't see any.  On the other hand, even if no bugs are known, then it's
still valuable to have all code paths do WAL insertion in the same way,
rather than having a single place that is alone in doing it in a
different way.  But if we don't know of any bugs, then backpatching
might be more risk than not doing so.

I confess I don't understand why is it important that XLogBeginInsert is
called inside the critical section.  It seems to me that that part is
only a side-effect of having to acquire the buffer locks in the critical
section.  Right?

I noticed that line 427 logs the GIN metapage with flag REGBUF_STANDARD;
is the GIN metapage really honoring pd_upper?  I see only pg_lower being
set.

-- 
Álvaro Herrera               48°01'N 7°57'E  —  https://www.EnterpriseDB.com/
"La grandeza es una experiencia transitoria.  Nunca es consistente.
Depende en gran parte de la imaginación humana creadora de mitos"
(Irulan)