Horton

Re: [Patch] ALTER SYSTEM READ ONLY

Simon Riggs <simon@2ndquadrant.com>

View thread View on postgr.es
From: Simon Riggs <simon@2ndquadrant.com>
To: amul sul <sulamul@gmail.com>
Cc: PostgreSQL-development <pgsql-hackers@postgresql.org>
Date: 2020-06-18T10:39:33Z
Lists: pgsql-hackers 
On Tue, 16 Jun 2020 at 14:56, amul sul <sulamul@gmail.com> wrote:


> The high-level goal is to make the availability/scale-out situation
> better.  The feature
> will help HA setup where the master server needs to stop accepting WAL
> writes
> immediately and kick out any transaction expecting WAL writes at the end,
> in case
> of network down on master or replication connections failures.
>
> For example, this feature allows for a controlled switchover without
> needing to shut
> down the master. You can instead make the master read-only, wait until the
> standby
> catches up, and then promote the standby. The master remains available for
> read
> queries throughout, and also for WAL streaming, but without the
> possibility of any
> new write transactions. After switchover is complete, the master can be
> shut down
> and brought back up as a standby without needing to use pg_rewind.
> (Eventually, it
> would be nice to be able to make the read-only master into a standby
> without having
> to restart it, but that is a problem for another patch.)
>
> This might also help in failover scenarios. For example, if you detect
> that the master
> has lost network connectivity to the standby, you might make it read-only
> after 30 s,
> and promote the standby after 60 s, so that you never have two writable
> masters at
> the same time. In this case, there's still some split-brain, but it's
> still better than what
> we have now.
>


> If there are open transactions that have acquired an XID, the sessions are
> killed
> before the barrier is absorbed.
>


> inbuilt graceful failover for PostgreSQL
>

That doesn't appear to be very graceful. Perhaps objections could be
assuaged by having a smoother transition and perhaps not even a full
barrier, initially.

-- 
Simon Riggs                http://www.2ndQuadrant.com/
<http://www.2ndquadrant.com/>
Mission Critical Databases

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.