Re: Issue in GIN fast-insert: XLogBeginInsert + Read/LockBuffer ordering - Mailing list pgsql-hackers

From Alvaro Herrera
Subject Re: Issue in GIN fast-insert: XLogBeginInsert + Read/LockBuffer ordering
Date
Msg-id 20221025073708.jpqiorm2neo34s6z@alvherre.pgsql
Whole thread Raw
In response to Re: Issue in GIN fast-insert: XLogBeginInsert + Read/LockBuffer ordering  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Issue in GIN fast-insert: XLogBeginInsert + Read/LockBuffer ordering
List pgsql-hackers
On 2022-Oct-25, Tom Lane wrote:

> Michael Paquier <michael@paquier.xyz> writes:
> > On Mon, Oct 24, 2022 at 02:22:16PM +0200, Alvaro Herrera wrote:
> >> 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?
> 
> > Yeah, you are right that it would not matter for XLogBeginInsert(),
> > though I'd like to think that this is a good practice on consistency
> > grounds with anywhere else, and we respect what's documented in the
> > README.
> 
> Yeah --- it's documented that way, and there doesn't seem to be
> a good reason not to honor that here.

Okay, so if we follow this argument, then the logical conclusion is that
this *should* be backpatched, after all.

-- 
Álvaro Herrera        Breisgau, Deutschland  —  https://www.EnterpriseDB.com/
Maybe there's lots of data loss but the records of data loss are also lost.
(Lincoln Yeoh)



pgsql-hackers by date:

Previous
From: Julien Rouhaud
Date:
Subject: Re: Allow file inclusion in pg_hba and pg_ident files
Next
From: Alvaro Herrera
Date:
Subject: Re: fixing typo in comment for restriction_is_or_clause