Re: [Patch] ALTER SYSTEM READ ONLY

Amul Sul <sulamul@gmail.com>

From: amul sul <sulamul@gmail.com>
To: Robert Haas <robertmhaas@gmail.com>
Cc: Amit Kapila <amit.kapila16@gmail.com>, PostgreSQL-development <pgsql-hackers@postgresql.org>
Date: 2020-06-19T03:58:53Z
Lists: pgsql-hackers
On Thu, Jun 18, 2020 at 8:23 PM Robert Haas <robertmhaas@gmail.com> wrote:
>
> On Thu, Jun 18, 2020 at 5:55 AM Amit Kapila <amit.kapila16@gmail.com> wrote:
> > For buffer replacement, many-a-times we have to also perform
> > XLogFlush, what do we do for that?  We can't proceed without doing
> > that and erroring out from there means stopping read-only query from
> > the user perspective.
>
> I think we should stop WAL writes, then XLogFlush() once, then declare
> the system R/O. After that there might be more XLogFlush() calls but
> there won't be any new WAL, so they won't do anything.
>
Yeah, the proposed v1 patch does the same.

Regards,
Amul



Commits

  1. Initialize variable to placate compiler.

  2. StartupXLOG: Don't repeatedly disable/enable local xlog insertion.

  3. StartupXLOG: Call CleanupAfterArchiveRecovery after XLogReportParameters.

  4. Postpone some end-of-recovery operations related to allowing WAL.

  5. Refactor some end-of-recovery code out of StartupXLOG().

  6. Re-enable contrib/bloom's TAP tests.

  7. Remove unnecessary call to ReadCheckpointRecord().

  8. Allow for error or refusal while absorbing a ProcSignalBarrier.

  9. Add comment to explain an unused function parameter

  10. Extend the ProcSignal mechanism to support barriers.

  11. At promotion, don't leave behind a partial segment on the old timeline.