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

HI,

On Sep 8, 2022, 19:08 +0800, Matthias van de Meent <boekewurm+postgres(at)gmail(dot)com>, wrote:
>  In general, this works fine, except that in ginHeapTupleFastInsert we
> call XLogBeginInsert() before the last of the buffers for the eventual
> record was read, thus creating a path where eviction is possible in a
> `begininsert_called = true` context. That breaks our current code by
> being unable to evict (WAL-log) the dirtied hint pages.
Does it break Postgres or Neon?
I look around the codes and as far as I can see, dirty pages could be flushed whether begininsert_called is true or false.
>
> PFA a patch that rectifies this issue, by moving the XLogBeginInsert()
> down to where 1.) we have all relevant buffers pinned and locked, and
> 2.) we're in a critical section, making that part of the code
> consistent with the general scheme for XLog insertion.
+1, Make sense.

Regards,
Zhang Mingli