Re: Shutdown indefinitely stuck due to unflushed FPI_FOR_HINT record - Mailing list pgsql-hackers

From Anthonin Bonnefoy
Subject Re: Shutdown indefinitely stuck due to unflushed FPI_FOR_HINT record
Date
Msg-id CAO6_XqqKDV+AuP=Gf4kRKPqzyYTsOyGd3LE8Jqkwi7EMPJpbhA@mail.gmail.com
Whole thread
In response to Re: Shutdown indefinitely stuck due to unflushed FPI_FOR_HINT record  (Anthonin Bonnefoy <anthonin.bonnefoy@datadoghq.com>)
Responses Re: Shutdown indefinitely stuck due to unflushed FPI_FOR_HINT record
List pgsql-hackers
Here's a small updated version of the patch, with the 2 different approaches.

- 0001: This is the XLogSetAsyncXactLSN call in RecordTransactionAbort
approach. The small difference with v3 is that the 'XactLastRecEnd !=
0' condition is now merged with !isSubXact:
+if (!isSubXact && XactLastRecEnd != 0)
+{
+        XLogSetAsyncXactLSN(XactLastRecEnd);
         XactLastRecEnd = 0;
+}

- 0002: This is the ShutdownXLOG approach. I've used
XLogFlush(WriteRqstPtr) instead of updating the async LSN. It feels
like if we're going to stop the walsenders, we may as well flush
everything and get the WAL in a good state.
The spinlock to access XLogCtl->LogwrtRqst.Write is probably
unnecessary since we're at a point where no additional WAL records
should be written, but it doesn't hurt to keep consistency.

Regards,
Anthonin Bonnefoy

Attachment

pgsql-hackers by date:

Previous
From: Andres Freund
Date:
Subject: Re: Reduce timing overhead of EXPLAIN ANALYZE using rdtsc?
Next
From: Nathan Bossart
Date:
Subject: Re: pg_dumpall --roles-only interact with other options