2011-03-07 00:39:14 +01:00
|
|
|
/*-------------------------------------------------------------------------
|
|
|
|
*
|
|
|
|
* syncrep.c
|
|
|
|
*
|
|
|
|
* Synchronous replication is new as of PostgreSQL 9.1.
|
|
|
|
*
|
|
|
|
* If requested, transaction commits wait until their commit LSN is
|
|
|
|
* acknowledged by the sync standby.
|
|
|
|
*
|
|
|
|
* This module contains the code for waiting and release of backends.
|
|
|
|
* All code in this module executes on the primary. The core streaming
|
|
|
|
* replication transport remains within WALreceiver/WALsender modules.
|
|
|
|
*
|
|
|
|
* The essence of this design is that it isolates all logic about
|
|
|
|
* waiting/releasing onto the primary. The primary defines which standbys
|
|
|
|
* it wishes to wait for. The standby is completely unaware of the
|
|
|
|
* durability requirements of transactions on the primary, reducing the
|
|
|
|
* complexity of the code and streamlining both standby operations and
|
|
|
|
* network bandwidth because there is no requirement to ship
|
|
|
|
* per-transaction state information.
|
|
|
|
*
|
|
|
|
* Replication is either synchronous or not synchronous (async). If it is
|
|
|
|
* async, we just fastpath out of here. If it is sync, then in 9.1 we wait
|
|
|
|
* for the flush location on the standby before releasing the waiting backend.
|
|
|
|
* Further complexity in that interaction is expected in later releases.
|
|
|
|
*
|
|
|
|
* The best performing way to manage the waiting backends is to have a
|
|
|
|
* single ordered queue of waiting backends, so that we can avoid
|
|
|
|
* searching the through all waiters each time we receive a reply.
|
|
|
|
*
|
|
|
|
* In 9.1 we support only a single synchronous standby, chosen from a
|
|
|
|
* priority list of synchronous_standby_names. Before it can become the
|
|
|
|
* synchronous standby it must have caught up with the primary; that may
|
|
|
|
* take some time. Once caught up, the current highest priority standby
|
|
|
|
* will release waiters from the queue.
|
|
|
|
*
|
|
|
|
* Portions Copyright (c) 2010-2011, PostgreSQL Global Development Group
|
|
|
|
*
|
|
|
|
* IDENTIFICATION
|
2011-03-10 07:05:33 +01:00
|
|
|
* src/backend/replication/syncrep.c
|
2011-03-07 00:39:14 +01:00
|
|
|
*
|
|
|
|
*-------------------------------------------------------------------------
|
|
|
|
*/
|
|
|
|
#include "postgres.h"
|
|
|
|
|
|
|
|
#include <unistd.h>
|
|
|
|
|
|
|
|
#include "access/xact.h"
|
|
|
|
#include "access/xlog_internal.h"
|
|
|
|
#include "miscadmin.h"
|
|
|
|
#include "postmaster/autovacuum.h"
|
|
|
|
#include "replication/syncrep.h"
|
|
|
|
#include "replication/walsender.h"
|
|
|
|
#include "storage/latch.h"
|
|
|
|
#include "storage/ipc.h"
|
|
|
|
#include "storage/pmsignal.h"
|
|
|
|
#include "storage/proc.h"
|
Fix various possible problems with synchronous replication.
1. Don't ignore query cancel interrupts. Instead, if the user asks to
cancel the query after we've already committed it, but before it's on
the standby, just emit a warning and let the COMMIT finish.
2. Don't ignore die interrupts (pg_terminate_backend or fast shutdown).
Instead, emit a warning message and close the connection without
acknowledging the commit. Other backends will still see the effect of
the commit, but there's no getting around that; it's too late to abort
at this point, and ignoring die interrupts altogether doesn't seem like
a good idea.
3. If synchronous_standby_names becomes empty, wake up all backends
waiting for synchronous replication to complete. Without this, someone
attempting to shut synchronous replication off could easily wedge the
entire system instead.
4. Avoid depending on the assumption that if a walsender updates
MyProc->syncRepState, we'll see the change even if we read it without
holding the lock. The window for this appears to be quite narrow (and
probably doesn't exist at all on machines with strong memory ordering)
but protecting against it is practically free, so do that.
5. Remove useless state SYNC_REP_MUST_DISCONNECT, which isn't needed and
doesn't actually do anything.
There's still some further work needed here to make the behavior of fast
shutdown plausible, but that looks complex, so I'm leaving it for a
separate commit. Review by Fujii Masao.
2011-03-17 18:10:42 +01:00
|
|
|
#include "tcop/tcopprot.h"
|
2011-03-07 00:39:14 +01:00
|
|
|
#include "utils/builtins.h"
|
|
|
|
#include "utils/guc.h"
|
|
|
|
#include "utils/guc_tables.h"
|
|
|
|
#include "utils/memutils.h"
|
|
|
|
#include "utils/ps_status.h"
|
|
|
|
|
|
|
|
/* User-settable parameters for sync rep */
|
2011-03-10 21:38:39 +01:00
|
|
|
bool synchronous_replication = false; /* Only set in user backends */
|
2011-03-07 00:39:14 +01:00
|
|
|
char *SyncRepStandbyNames;
|
|
|
|
|
Fix various possible problems with synchronous replication.
1. Don't ignore query cancel interrupts. Instead, if the user asks to
cancel the query after we've already committed it, but before it's on
the standby, just emit a warning and let the COMMIT finish.
2. Don't ignore die interrupts (pg_terminate_backend or fast shutdown).
Instead, emit a warning message and close the connection without
acknowledging the commit. Other backends will still see the effect of
the commit, but there's no getting around that; it's too late to abort
at this point, and ignoring die interrupts altogether doesn't seem like
a good idea.
3. If synchronous_standby_names becomes empty, wake up all backends
waiting for synchronous replication to complete. Without this, someone
attempting to shut synchronous replication off could easily wedge the
entire system instead.
4. Avoid depending on the assumption that if a walsender updates
MyProc->syncRepState, we'll see the change even if we read it without
holding the lock. The window for this appears to be quite narrow (and
probably doesn't exist at all on machines with strong memory ordering)
but protecting against it is practically free, so do that.
5. Remove useless state SYNC_REP_MUST_DISCONNECT, which isn't needed and
doesn't actually do anything.
There's still some further work needed here to make the behavior of fast
shutdown plausible, but that looks complex, so I'm leaving it for a
separate commit. Review by Fujii Masao.
2011-03-17 18:10:42 +01:00
|
|
|
#define SyncStandbysDefined() \
|
|
|
|
(SyncRepStandbyNames != NULL && SyncRepStandbyNames[0] != '\0')
|
|
|
|
|
2011-03-07 00:39:14 +01:00
|
|
|
static bool announce_next_takeover = true;
|
|
|
|
|
|
|
|
static void SyncRepQueueInsert(void);
|
Fix various possible problems with synchronous replication.
1. Don't ignore query cancel interrupts. Instead, if the user asks to
cancel the query after we've already committed it, but before it's on
the standby, just emit a warning and let the COMMIT finish.
2. Don't ignore die interrupts (pg_terminate_backend or fast shutdown).
Instead, emit a warning message and close the connection without
acknowledging the commit. Other backends will still see the effect of
the commit, but there's no getting around that; it's too late to abort
at this point, and ignoring die interrupts altogether doesn't seem like
a good idea.
3. If synchronous_standby_names becomes empty, wake up all backends
waiting for synchronous replication to complete. Without this, someone
attempting to shut synchronous replication off could easily wedge the
entire system instead.
4. Avoid depending on the assumption that if a walsender updates
MyProc->syncRepState, we'll see the change even if we read it without
holding the lock. The window for this appears to be quite narrow (and
probably doesn't exist at all on machines with strong memory ordering)
but protecting against it is practically free, so do that.
5. Remove useless state SYNC_REP_MUST_DISCONNECT, which isn't needed and
doesn't actually do anything.
There's still some further work needed here to make the behavior of fast
shutdown plausible, but that looks complex, so I'm leaving it for a
separate commit. Review by Fujii Masao.
2011-03-17 18:10:42 +01:00
|
|
|
static void SyncRepCancelWait(void);
|
2011-03-07 00:39:14 +01:00
|
|
|
|
|
|
|
static int SyncRepGetStandbyPriority(void);
|
2011-03-07 08:56:53 +01:00
|
|
|
#ifdef USE_ASSERT_CHECKING
|
2011-03-07 00:39:14 +01:00
|
|
|
static bool SyncRepQueueIsOrderedByLSN(void);
|
2011-03-07 08:56:53 +01:00
|
|
|
#endif
|
2011-03-07 00:39:14 +01:00
|
|
|
|
|
|
|
/*
|
|
|
|
* ===========================================================
|
|
|
|
* Synchronous Replication functions for normal user backends
|
|
|
|
* ===========================================================
|
|
|
|
*/
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Wait for synchronous replication, if requested by user.
|
Fix various possible problems with synchronous replication.
1. Don't ignore query cancel interrupts. Instead, if the user asks to
cancel the query after we've already committed it, but before it's on
the standby, just emit a warning and let the COMMIT finish.
2. Don't ignore die interrupts (pg_terminate_backend or fast shutdown).
Instead, emit a warning message and close the connection without
acknowledging the commit. Other backends will still see the effect of
the commit, but there's no getting around that; it's too late to abort
at this point, and ignoring die interrupts altogether doesn't seem like
a good idea.
3. If synchronous_standby_names becomes empty, wake up all backends
waiting for synchronous replication to complete. Without this, someone
attempting to shut synchronous replication off could easily wedge the
entire system instead.
4. Avoid depending on the assumption that if a walsender updates
MyProc->syncRepState, we'll see the change even if we read it without
holding the lock. The window for this appears to be quite narrow (and
probably doesn't exist at all on machines with strong memory ordering)
but protecting against it is practically free, so do that.
5. Remove useless state SYNC_REP_MUST_DISCONNECT, which isn't needed and
doesn't actually do anything.
There's still some further work needed here to make the behavior of fast
shutdown plausible, but that looks complex, so I'm leaving it for a
separate commit. Review by Fujii Masao.
2011-03-17 18:10:42 +01:00
|
|
|
*
|
|
|
|
* Initially backends start in state SYNC_REP_NOT_WAITING and then
|
|
|
|
* change that state to SYNC_REP_WAITING before adding ourselves
|
|
|
|
* to the wait queue. During SyncRepWakeQueue() a WALSender changes
|
|
|
|
* the state to SYNC_REP_WAIT_COMPLETE once replication is confirmed.
|
|
|
|
* This backend then resets its state to SYNC_REP_NOT_WAITING.
|
2011-03-07 00:39:14 +01:00
|
|
|
*/
|
|
|
|
void
|
|
|
|
SyncRepWaitForLSN(XLogRecPtr XactCommitLSN)
|
|
|
|
{
|
|
|
|
char *new_status = NULL;
|
|
|
|
const char *old_status;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Fast exit if user has not requested sync replication, or
|
|
|
|
* there are no sync replication standby names defined.
|
|
|
|
* Note that those standbys don't need to be connected.
|
|
|
|
*/
|
Fix various possible problems with synchronous replication.
1. Don't ignore query cancel interrupts. Instead, if the user asks to
cancel the query after we've already committed it, but before it's on
the standby, just emit a warning and let the COMMIT finish.
2. Don't ignore die interrupts (pg_terminate_backend or fast shutdown).
Instead, emit a warning message and close the connection without
acknowledging the commit. Other backends will still see the effect of
the commit, but there's no getting around that; it's too late to abort
at this point, and ignoring die interrupts altogether doesn't seem like
a good idea.
3. If synchronous_standby_names becomes empty, wake up all backends
waiting for synchronous replication to complete. Without this, someone
attempting to shut synchronous replication off could easily wedge the
entire system instead.
4. Avoid depending on the assumption that if a walsender updates
MyProc->syncRepState, we'll see the change even if we read it without
holding the lock. The window for this appears to be quite narrow (and
probably doesn't exist at all on machines with strong memory ordering)
but protecting against it is practically free, so do that.
5. Remove useless state SYNC_REP_MUST_DISCONNECT, which isn't needed and
doesn't actually do anything.
There's still some further work needed here to make the behavior of fast
shutdown plausible, but that looks complex, so I'm leaving it for a
separate commit. Review by Fujii Masao.
2011-03-17 18:10:42 +01:00
|
|
|
if (!SyncRepRequested() || !SyncStandbysDefined())
|
2011-03-07 00:39:14 +01:00
|
|
|
return;
|
|
|
|
|
|
|
|
Assert(SHMQueueIsDetached(&(MyProc->syncRepLinks)));
|
Fix various possible problems with synchronous replication.
1. Don't ignore query cancel interrupts. Instead, if the user asks to
cancel the query after we've already committed it, but before it's on
the standby, just emit a warning and let the COMMIT finish.
2. Don't ignore die interrupts (pg_terminate_backend or fast shutdown).
Instead, emit a warning message and close the connection without
acknowledging the commit. Other backends will still see the effect of
the commit, but there's no getting around that; it's too late to abort
at this point, and ignoring die interrupts altogether doesn't seem like
a good idea.
3. If synchronous_standby_names becomes empty, wake up all backends
waiting for synchronous replication to complete. Without this, someone
attempting to shut synchronous replication off could easily wedge the
entire system instead.
4. Avoid depending on the assumption that if a walsender updates
MyProc->syncRepState, we'll see the change even if we read it without
holding the lock. The window for this appears to be quite narrow (and
probably doesn't exist at all on machines with strong memory ordering)
but protecting against it is practically free, so do that.
5. Remove useless state SYNC_REP_MUST_DISCONNECT, which isn't needed and
doesn't actually do anything.
There's still some further work needed here to make the behavior of fast
shutdown plausible, but that looks complex, so I'm leaving it for a
separate commit. Review by Fujii Masao.
2011-03-17 18:10:42 +01:00
|
|
|
Assert(WalSndCtl != NULL);
|
|
|
|
|
|
|
|
/* Reset the latch before adding ourselves to the queue. */
|
|
|
|
ResetLatch(&MyProc->waitLatch);
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Set our waitLSN so WALSender will know when to wake us, and add
|
|
|
|
* ourselves to the queue.
|
|
|
|
*/
|
|
|
|
LWLockAcquire(SyncRepLock, LW_EXCLUSIVE);
|
|
|
|
Assert(MyProc->syncRepState == SYNC_REP_NOT_WAITING);
|
|
|
|
if (!WalSndCtl->sync_standbys_defined)
|
|
|
|
{
|
|
|
|
/*
|
|
|
|
* We don't wait for sync rep if WalSndCtl->sync_standbys_defined is
|
|
|
|
* not set. See SyncRepUpdateSyncStandbysDefined.
|
|
|
|
*/
|
|
|
|
LWLockRelease(SyncRepLock);
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
MyProc->waitLSN = XactCommitLSN;
|
|
|
|
MyProc->syncRepState = SYNC_REP_WAITING;
|
|
|
|
SyncRepQueueInsert();
|
|
|
|
Assert(SyncRepQueueIsOrderedByLSN());
|
|
|
|
LWLockRelease(SyncRepLock);
|
|
|
|
|
|
|
|
/* Alter ps display to show waiting for sync rep. */
|
|
|
|
if (update_process_title)
|
|
|
|
{
|
|
|
|
int len;
|
|
|
|
|
|
|
|
old_status = get_ps_display(&len);
|
|
|
|
new_status = (char *) palloc(len + 32 + 1);
|
|
|
|
memcpy(new_status, old_status, len);
|
|
|
|
sprintf(new_status + len, " waiting for %X/%X",
|
|
|
|
XactCommitLSN.xlogid, XactCommitLSN.xrecoff);
|
|
|
|
set_ps_display(new_status, false);
|
|
|
|
new_status[len] = '\0'; /* truncate off " waiting ..." */
|
|
|
|
}
|
2011-03-07 00:39:14 +01:00
|
|
|
|
|
|
|
/*
|
|
|
|
* Wait for specified LSN to be confirmed.
|
|
|
|
*
|
|
|
|
* Each proc has its own wait latch, so we perform a normal latch
|
|
|
|
* check/wait loop here.
|
|
|
|
*/
|
|
|
|
for (;;)
|
|
|
|
{
|
Fix various possible problems with synchronous replication.
1. Don't ignore query cancel interrupts. Instead, if the user asks to
cancel the query after we've already committed it, but before it's on
the standby, just emit a warning and let the COMMIT finish.
2. Don't ignore die interrupts (pg_terminate_backend or fast shutdown).
Instead, emit a warning message and close the connection without
acknowledging the commit. Other backends will still see the effect of
the commit, but there's no getting around that; it's too late to abort
at this point, and ignoring die interrupts altogether doesn't seem like
a good idea.
3. If synchronous_standby_names becomes empty, wake up all backends
waiting for synchronous replication to complete. Without this, someone
attempting to shut synchronous replication off could easily wedge the
entire system instead.
4. Avoid depending on the assumption that if a walsender updates
MyProc->syncRepState, we'll see the change even if we read it without
holding the lock. The window for this appears to be quite narrow (and
probably doesn't exist at all on machines with strong memory ordering)
but protecting against it is practically free, so do that.
5. Remove useless state SYNC_REP_MUST_DISCONNECT, which isn't needed and
doesn't actually do anything.
There's still some further work needed here to make the behavior of fast
shutdown plausible, but that looks complex, so I'm leaving it for a
separate commit. Review by Fujii Masao.
2011-03-17 18:10:42 +01:00
|
|
|
int syncRepState;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Wait on latch for up to 60 seconds. This allows us to
|
|
|
|
* check for postmaster death regularly while waiting.
|
|
|
|
* Note that timeout here does not necessarily release from loop.
|
|
|
|
*/
|
|
|
|
WaitLatch(&MyProc->waitLatch, 60000000L);
|
|
|
|
|
|
|
|
/* Must reset the latch before testing state. */
|
2011-03-07 00:39:14 +01:00
|
|
|
ResetLatch(&MyProc->waitLatch);
|
|
|
|
|
|
|
|
/*
|
Fix various possible problems with synchronous replication.
1. Don't ignore query cancel interrupts. Instead, if the user asks to
cancel the query after we've already committed it, but before it's on
the standby, just emit a warning and let the COMMIT finish.
2. Don't ignore die interrupts (pg_terminate_backend or fast shutdown).
Instead, emit a warning message and close the connection without
acknowledging the commit. Other backends will still see the effect of
the commit, but there's no getting around that; it's too late to abort
at this point, and ignoring die interrupts altogether doesn't seem like
a good idea.
3. If synchronous_standby_names becomes empty, wake up all backends
waiting for synchronous replication to complete. Without this, someone
attempting to shut synchronous replication off could easily wedge the
entire system instead.
4. Avoid depending on the assumption that if a walsender updates
MyProc->syncRepState, we'll see the change even if we read it without
holding the lock. The window for this appears to be quite narrow (and
probably doesn't exist at all on machines with strong memory ordering)
but protecting against it is practically free, so do that.
5. Remove useless state SYNC_REP_MUST_DISCONNECT, which isn't needed and
doesn't actually do anything.
There's still some further work needed here to make the behavior of fast
shutdown plausible, but that looks complex, so I'm leaving it for a
separate commit. Review by Fujii Masao.
2011-03-17 18:10:42 +01:00
|
|
|
* Try checking the state without the lock first. There's no guarantee
|
|
|
|
* that we'll read the most up-to-date value, so if it looks like we're
|
|
|
|
* still waiting, recheck while holding the lock. But if it looks like
|
|
|
|
* we're done, we must really be done, because once walsender changes
|
|
|
|
* the state to SYNC_REP_WAIT_COMPLETE, it will never update it again,
|
|
|
|
* so we can't be seeing a stale value in that case.
|
2011-03-07 00:39:14 +01:00
|
|
|
*/
|
Fix various possible problems with synchronous replication.
1. Don't ignore query cancel interrupts. Instead, if the user asks to
cancel the query after we've already committed it, but before it's on
the standby, just emit a warning and let the COMMIT finish.
2. Don't ignore die interrupts (pg_terminate_backend or fast shutdown).
Instead, emit a warning message and close the connection without
acknowledging the commit. Other backends will still see the effect of
the commit, but there's no getting around that; it's too late to abort
at this point, and ignoring die interrupts altogether doesn't seem like
a good idea.
3. If synchronous_standby_names becomes empty, wake up all backends
waiting for synchronous replication to complete. Without this, someone
attempting to shut synchronous replication off could easily wedge the
entire system instead.
4. Avoid depending on the assumption that if a walsender updates
MyProc->syncRepState, we'll see the change even if we read it without
holding the lock. The window for this appears to be quite narrow (and
probably doesn't exist at all on machines with strong memory ordering)
but protecting against it is practically free, so do that.
5. Remove useless state SYNC_REP_MUST_DISCONNECT, which isn't needed and
doesn't actually do anything.
There's still some further work needed here to make the behavior of fast
shutdown plausible, but that looks complex, so I'm leaving it for a
separate commit. Review by Fujii Masao.
2011-03-17 18:10:42 +01:00
|
|
|
syncRepState = MyProc->syncRepState;
|
|
|
|
if (syncRepState == SYNC_REP_WAITING)
|
2011-03-07 00:39:14 +01:00
|
|
|
{
|
Fix various possible problems with synchronous replication.
1. Don't ignore query cancel interrupts. Instead, if the user asks to
cancel the query after we've already committed it, but before it's on
the standby, just emit a warning and let the COMMIT finish.
2. Don't ignore die interrupts (pg_terminate_backend or fast shutdown).
Instead, emit a warning message and close the connection without
acknowledging the commit. Other backends will still see the effect of
the commit, but there's no getting around that; it's too late to abort
at this point, and ignoring die interrupts altogether doesn't seem like
a good idea.
3. If synchronous_standby_names becomes empty, wake up all backends
waiting for synchronous replication to complete. Without this, someone
attempting to shut synchronous replication off could easily wedge the
entire system instead.
4. Avoid depending on the assumption that if a walsender updates
MyProc->syncRepState, we'll see the change even if we read it without
holding the lock. The window for this appears to be quite narrow (and
probably doesn't exist at all on machines with strong memory ordering)
but protecting against it is practically free, so do that.
5. Remove useless state SYNC_REP_MUST_DISCONNECT, which isn't needed and
doesn't actually do anything.
There's still some further work needed here to make the behavior of fast
shutdown plausible, but that looks complex, so I'm leaving it for a
separate commit. Review by Fujii Masao.
2011-03-17 18:10:42 +01:00
|
|
|
LWLockAcquire(SyncRepLock, LW_SHARED);
|
|
|
|
syncRepState = MyProc->syncRepState;
|
|
|
|
LWLockRelease(SyncRepLock);
|
2011-03-07 00:39:14 +01:00
|
|
|
}
|
Fix various possible problems with synchronous replication.
1. Don't ignore query cancel interrupts. Instead, if the user asks to
cancel the query after we've already committed it, but before it's on
the standby, just emit a warning and let the COMMIT finish.
2. Don't ignore die interrupts (pg_terminate_backend or fast shutdown).
Instead, emit a warning message and close the connection without
acknowledging the commit. Other backends will still see the effect of
the commit, but there's no getting around that; it's too late to abort
at this point, and ignoring die interrupts altogether doesn't seem like
a good idea.
3. If synchronous_standby_names becomes empty, wake up all backends
waiting for synchronous replication to complete. Without this, someone
attempting to shut synchronous replication off could easily wedge the
entire system instead.
4. Avoid depending on the assumption that if a walsender updates
MyProc->syncRepState, we'll see the change even if we read it without
holding the lock. The window for this appears to be quite narrow (and
probably doesn't exist at all on machines with strong memory ordering)
but protecting against it is practically free, so do that.
5. Remove useless state SYNC_REP_MUST_DISCONNECT, which isn't needed and
doesn't actually do anything.
There's still some further work needed here to make the behavior of fast
shutdown plausible, but that looks complex, so I'm leaving it for a
separate commit. Review by Fujii Masao.
2011-03-17 18:10:42 +01:00
|
|
|
if (syncRepState == SYNC_REP_WAIT_COMPLETE)
|
|
|
|
break;
|
2011-03-07 00:39:14 +01:00
|
|
|
|
|
|
|
/*
|
Fix various possible problems with synchronous replication.
1. Don't ignore query cancel interrupts. Instead, if the user asks to
cancel the query after we've already committed it, but before it's on
the standby, just emit a warning and let the COMMIT finish.
2. Don't ignore die interrupts (pg_terminate_backend or fast shutdown).
Instead, emit a warning message and close the connection without
acknowledging the commit. Other backends will still see the effect of
the commit, but there's no getting around that; it's too late to abort
at this point, and ignoring die interrupts altogether doesn't seem like
a good idea.
3. If synchronous_standby_names becomes empty, wake up all backends
waiting for synchronous replication to complete. Without this, someone
attempting to shut synchronous replication off could easily wedge the
entire system instead.
4. Avoid depending on the assumption that if a walsender updates
MyProc->syncRepState, we'll see the change even if we read it without
holding the lock. The window for this appears to be quite narrow (and
probably doesn't exist at all on machines with strong memory ordering)
but protecting against it is practically free, so do that.
5. Remove useless state SYNC_REP_MUST_DISCONNECT, which isn't needed and
doesn't actually do anything.
There's still some further work needed here to make the behavior of fast
shutdown plausible, but that looks complex, so I'm leaving it for a
separate commit. Review by Fujii Masao.
2011-03-17 18:10:42 +01:00
|
|
|
* If a wait for synchronous replication is pending, we can neither
|
|
|
|
* acknowledge the commit nor raise ERROR or FATAL. The latter
|
|
|
|
* would lead the client to believe that that the transaction
|
|
|
|
* aborted, which is not true: it's already committed locally.
|
|
|
|
* The former is no good either: the client has requested
|
|
|
|
* synchronous replication, and is entitled to assume that an
|
|
|
|
* acknowledged commit is also replicated, which may not be true.
|
|
|
|
* So in this case we issue a WARNING (which some clients may
|
|
|
|
* be able to interpret) and shut off further output. We do NOT
|
|
|
|
* reset ProcDiePending, so that the process will die after the
|
|
|
|
* commit is cleaned up.
|
2011-03-07 00:39:14 +01:00
|
|
|
*/
|
Fix various possible problems with synchronous replication.
1. Don't ignore query cancel interrupts. Instead, if the user asks to
cancel the query after we've already committed it, but before it's on
the standby, just emit a warning and let the COMMIT finish.
2. Don't ignore die interrupts (pg_terminate_backend or fast shutdown).
Instead, emit a warning message and close the connection without
acknowledging the commit. Other backends will still see the effect of
the commit, but there's no getting around that; it's too late to abort
at this point, and ignoring die interrupts altogether doesn't seem like
a good idea.
3. If synchronous_standby_names becomes empty, wake up all backends
waiting for synchronous replication to complete. Without this, someone
attempting to shut synchronous replication off could easily wedge the
entire system instead.
4. Avoid depending on the assumption that if a walsender updates
MyProc->syncRepState, we'll see the change even if we read it without
holding the lock. The window for this appears to be quite narrow (and
probably doesn't exist at all on machines with strong memory ordering)
but protecting against it is practically free, so do that.
5. Remove useless state SYNC_REP_MUST_DISCONNECT, which isn't needed and
doesn't actually do anything.
There's still some further work needed here to make the behavior of fast
shutdown plausible, but that looks complex, so I'm leaving it for a
separate commit. Review by Fujii Masao.
2011-03-17 18:10:42 +01:00
|
|
|
if (ProcDiePending)
|
|
|
|
{
|
|
|
|
ereport(WARNING,
|
|
|
|
(errcode(ERRCODE_ADMIN_SHUTDOWN),
|
|
|
|
errmsg("canceling the wait for replication and terminating connection due to administrator command"),
|
|
|
|
errdetail("The transaction has already been committed locally but might have not been replicated to the standby.")));
|
|
|
|
whereToSendOutput = DestNone;
|
|
|
|
SyncRepCancelWait();
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* It's unclear what to do if a query cancel interrupt arrives. We
|
|
|
|
* can't actually abort at this point, but ignoring the interrupt
|
|
|
|
* altogether is not helpful, so we just terminate the wait with
|
|
|
|
* a suitable warning.
|
|
|
|
*/
|
|
|
|
if (QueryCancelPending)
|
|
|
|
{
|
|
|
|
QueryCancelPending = false;
|
|
|
|
ereport(WARNING,
|
|
|
|
(errmsg("canceling wait for synchronous replication due to user request"),
|
|
|
|
errdetail("The transaction has committed locally, but may not have replicated to the standby.")));
|
|
|
|
SyncRepCancelWait();
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* If the postmaster dies, we'll probably never get an acknowledgement,
|
|
|
|
* because all the wal sender processes will exit. So just bail out.
|
|
|
|
*/
|
|
|
|
if (!PostmasterIsAlive(true))
|
|
|
|
{
|
|
|
|
ProcDiePending = true;
|
|
|
|
whereToSendOutput = DestNone;
|
|
|
|
SyncRepCancelWait();
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* WalSender has checked our LSN and has removed us from queue. Clean up
|
|
|
|
* state and leave. It's OK to reset these shared memory fields without
|
|
|
|
* holding SyncRepLock, because any walsenders will ignore us anyway when
|
|
|
|
* we're not on the queue.
|
|
|
|
*/
|
|
|
|
Assert(SHMQueueIsDetached(&(MyProc->syncRepLinks)));
|
|
|
|
MyProc->syncRepState = SYNC_REP_NOT_WAITING;
|
|
|
|
MyProc->waitLSN.xlogid = 0;
|
|
|
|
MyProc->waitLSN.xrecoff = 0;
|
|
|
|
|
|
|
|
if (new_status)
|
|
|
|
{
|
|
|
|
/* Reset ps display */
|
|
|
|
set_ps_display(new_status, false);
|
|
|
|
pfree(new_status);
|
2011-03-07 00:39:14 +01:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Insert MyProc into SyncRepQueue, maintaining sorted invariant.
|
|
|
|
*
|
2011-03-10 21:56:18 +01:00
|
|
|
* Usually we will go at tail of queue, though it's possible that we arrive
|
2011-03-07 00:39:14 +01:00
|
|
|
* here out of order, so start at tail and work back to insertion point.
|
|
|
|
*/
|
|
|
|
static void
|
|
|
|
SyncRepQueueInsert(void)
|
|
|
|
{
|
|
|
|
PGPROC *proc;
|
|
|
|
|
|
|
|
proc = (PGPROC *) SHMQueuePrev(&(WalSndCtl->SyncRepQueue),
|
|
|
|
&(WalSndCtl->SyncRepQueue),
|
|
|
|
offsetof(PGPROC, syncRepLinks));
|
|
|
|
|
|
|
|
while (proc)
|
|
|
|
{
|
|
|
|
/*
|
|
|
|
* Stop at the queue element that we should after to
|
|
|
|
* ensure the queue is ordered by LSN.
|
|
|
|
*/
|
|
|
|
if (XLByteLT(proc->waitLSN, MyProc->waitLSN))
|
|
|
|
break;
|
|
|
|
|
|
|
|
proc = (PGPROC *) SHMQueuePrev(&(WalSndCtl->SyncRepQueue),
|
|
|
|
&(proc->syncRepLinks),
|
|
|
|
offsetof(PGPROC, syncRepLinks));
|
|
|
|
}
|
|
|
|
|
|
|
|
if (proc)
|
|
|
|
SHMQueueInsertAfter(&(proc->syncRepLinks), &(MyProc->syncRepLinks));
|
|
|
|
else
|
|
|
|
SHMQueueInsertAfter(&(WalSndCtl->SyncRepQueue), &(MyProc->syncRepLinks));
|
|
|
|
}
|
|
|
|
|
Fix various possible problems with synchronous replication.
1. Don't ignore query cancel interrupts. Instead, if the user asks to
cancel the query after we've already committed it, but before it's on
the standby, just emit a warning and let the COMMIT finish.
2. Don't ignore die interrupts (pg_terminate_backend or fast shutdown).
Instead, emit a warning message and close the connection without
acknowledging the commit. Other backends will still see the effect of
the commit, but there's no getting around that; it's too late to abort
at this point, and ignoring die interrupts altogether doesn't seem like
a good idea.
3. If synchronous_standby_names becomes empty, wake up all backends
waiting for synchronous replication to complete. Without this, someone
attempting to shut synchronous replication off could easily wedge the
entire system instead.
4. Avoid depending on the assumption that if a walsender updates
MyProc->syncRepState, we'll see the change even if we read it without
holding the lock. The window for this appears to be quite narrow (and
probably doesn't exist at all on machines with strong memory ordering)
but protecting against it is practically free, so do that.
5. Remove useless state SYNC_REP_MUST_DISCONNECT, which isn't needed and
doesn't actually do anything.
There's still some further work needed here to make the behavior of fast
shutdown plausible, but that looks complex, so I'm leaving it for a
separate commit. Review by Fujii Masao.
2011-03-17 18:10:42 +01:00
|
|
|
/*
|
|
|
|
* Acquire SyncRepLock and cancel any wait currently in progress.
|
|
|
|
*/
|
|
|
|
static void
|
|
|
|
SyncRepCancelWait(void)
|
|
|
|
{
|
|
|
|
LWLockAcquire(SyncRepLock, LW_EXCLUSIVE);
|
|
|
|
if (!SHMQueueIsDetached(&(MyProc->syncRepLinks)))
|
|
|
|
SHMQueueDelete(&(MyProc->syncRepLinks));
|
|
|
|
MyProc->syncRepState = SYNC_REP_NOT_WAITING;
|
|
|
|
LWLockRelease(SyncRepLock);
|
|
|
|
}
|
|
|
|
|
2011-03-07 00:39:14 +01:00
|
|
|
void
|
|
|
|
SyncRepCleanupAtProcExit(int code, Datum arg)
|
|
|
|
{
|
|
|
|
if (!SHMQueueIsDetached(&(MyProc->syncRepLinks)))
|
|
|
|
{
|
|
|
|
LWLockAcquire(SyncRepLock, LW_EXCLUSIVE);
|
|
|
|
SHMQueueDelete(&(MyProc->syncRepLinks));
|
|
|
|
LWLockRelease(SyncRepLock);
|
|
|
|
}
|
|
|
|
|
|
|
|
DisownLatch(&MyProc->waitLatch);
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* ===========================================================
|
|
|
|
* Synchronous Replication functions for wal sender processes
|
|
|
|
* ===========================================================
|
|
|
|
*/
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Take any action required to initialise sync rep state from config
|
|
|
|
* data. Called at WALSender startup and after each SIGHUP.
|
|
|
|
*/
|
|
|
|
void
|
|
|
|
SyncRepInitConfig(void)
|
|
|
|
{
|
|
|
|
int priority;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Determine if we are a potential sync standby and remember the result
|
|
|
|
* for handling replies from standby.
|
|
|
|
*/
|
|
|
|
priority = SyncRepGetStandbyPriority();
|
|
|
|
if (MyWalSnd->sync_standby_priority != priority)
|
|
|
|
{
|
|
|
|
LWLockAcquire(SyncRepLock, LW_EXCLUSIVE);
|
|
|
|
MyWalSnd->sync_standby_priority = priority;
|
|
|
|
LWLockRelease(SyncRepLock);
|
|
|
|
ereport(DEBUG1,
|
|
|
|
(errmsg("standby \"%s\" now has synchronous standby priority %u",
|
|
|
|
application_name, priority)));
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Update the LSNs on each queue based upon our latest state. This
|
|
|
|
* implements a simple policy of first-valid-standby-releases-waiter.
|
|
|
|
*
|
|
|
|
* Other policies are possible, which would change what we do here and what
|
|
|
|
* perhaps also which information we store as well.
|
|
|
|
*/
|
|
|
|
void
|
|
|
|
SyncRepReleaseWaiters(void)
|
|
|
|
{
|
|
|
|
volatile WalSndCtlData *walsndctl = WalSndCtl;
|
|
|
|
volatile WalSnd *syncWalSnd = NULL;
|
|
|
|
int numprocs = 0;
|
|
|
|
int priority = 0;
|
|
|
|
int i;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* If this WALSender is serving a standby that is not on the list of
|
|
|
|
* potential standbys then we have nothing to do. If we are still
|
|
|
|
* starting up or still running base backup, then leave quickly also.
|
|
|
|
*/
|
|
|
|
if (MyWalSnd->sync_standby_priority == 0 ||
|
|
|
|
MyWalSnd->state < WALSNDSTATE_STREAMING)
|
|
|
|
return;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* We're a potential sync standby. Release waiters if we are the
|
|
|
|
* highest priority standby. If there are multiple standbys with
|
|
|
|
* same priorities then we use the first mentioned standby.
|
|
|
|
* If you change this, also change pg_stat_get_wal_senders().
|
|
|
|
*/
|
|
|
|
LWLockAcquire(SyncRepLock, LW_EXCLUSIVE);
|
|
|
|
|
|
|
|
for (i = 0; i < max_wal_senders; i++)
|
|
|
|
{
|
|
|
|
/* use volatile pointer to prevent code rearrangement */
|
|
|
|
volatile WalSnd *walsnd = &walsndctl->walsnds[i];
|
|
|
|
|
|
|
|
if (walsnd->pid != 0 &&
|
|
|
|
walsnd->sync_standby_priority > 0 &&
|
|
|
|
(priority == 0 ||
|
|
|
|
priority > walsnd->sync_standby_priority))
|
|
|
|
{
|
|
|
|
priority = walsnd->sync_standby_priority;
|
|
|
|
syncWalSnd = walsnd;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* We should have found ourselves at least.
|
|
|
|
*/
|
|
|
|
Assert(syncWalSnd);
|
|
|
|
|
|
|
|
/*
|
|
|
|
* If we aren't managing the highest priority standby then just leave.
|
|
|
|
*/
|
|
|
|
if (syncWalSnd != MyWalSnd)
|
|
|
|
{
|
|
|
|
LWLockRelease(SyncRepLock);
|
|
|
|
announce_next_takeover = true;
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (XLByteLT(walsndctl->lsn, MyWalSnd->flush))
|
|
|
|
{
|
|
|
|
/*
|
|
|
|
* Set the lsn first so that when we wake backends they will
|
|
|
|
* release up to this location.
|
|
|
|
*/
|
|
|
|
walsndctl->lsn = MyWalSnd->flush;
|
|
|
|
numprocs = SyncRepWakeQueue(false);
|
|
|
|
}
|
|
|
|
|
|
|
|
LWLockRelease(SyncRepLock);
|
|
|
|
|
|
|
|
elog(DEBUG3, "released %d procs up to %X/%X",
|
|
|
|
numprocs,
|
|
|
|
MyWalSnd->flush.xlogid,
|
|
|
|
MyWalSnd->flush.xrecoff);
|
|
|
|
|
|
|
|
/*
|
|
|
|
* If we are managing the highest priority standby, though we weren't
|
|
|
|
* prior to this, then announce we are now the sync standby.
|
|
|
|
*/
|
|
|
|
if (announce_next_takeover)
|
|
|
|
{
|
|
|
|
announce_next_takeover = false;
|
|
|
|
ereport(LOG,
|
|
|
|
(errmsg("standby \"%s\" is now the synchronous standby with priority %u",
|
|
|
|
application_name, MyWalSnd->sync_standby_priority)));
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Check if we are in the list of sync standbys, and if so, determine
|
|
|
|
* priority sequence. Return priority if set, or zero to indicate that
|
|
|
|
* we are not a potential sync standby.
|
|
|
|
*
|
|
|
|
* Compare the parameter SyncRepStandbyNames against the application_name
|
|
|
|
* for this WALSender, or allow any name if we find a wildcard "*".
|
|
|
|
*/
|
|
|
|
static int
|
|
|
|
SyncRepGetStandbyPriority(void)
|
|
|
|
{
|
|
|
|
char *rawstring;
|
|
|
|
List *elemlist;
|
|
|
|
ListCell *l;
|
|
|
|
int priority = 0;
|
|
|
|
bool found = false;
|
|
|
|
|
|
|
|
/* Need a modifiable copy of string */
|
|
|
|
rawstring = pstrdup(SyncRepStandbyNames);
|
|
|
|
|
|
|
|
/* Parse string into list of identifiers */
|
|
|
|
if (!SplitIdentifierString(rawstring, ',', &elemlist))
|
|
|
|
{
|
|
|
|
/* syntax error in list */
|
|
|
|
pfree(rawstring);
|
|
|
|
list_free(elemlist);
|
2011-03-10 22:24:52 +01:00
|
|
|
/* GUC machinery will have already complained - no need to do again */
|
2011-03-07 00:39:14 +01:00
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
foreach(l, elemlist)
|
|
|
|
{
|
|
|
|
char *standby_name = (char *) lfirst(l);
|
|
|
|
|
|
|
|
priority++;
|
|
|
|
|
|
|
|
if (pg_strcasecmp(standby_name, application_name) == 0 ||
|
|
|
|
pg_strcasecmp(standby_name, "*") == 0)
|
|
|
|
{
|
|
|
|
found = true;
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
pfree(rawstring);
|
|
|
|
list_free(elemlist);
|
|
|
|
|
|
|
|
return (found ? priority : 0);
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
2011-03-10 20:57:02 +01:00
|
|
|
* Walk queue from head. Set the state of any backends that need to be woken,
|
|
|
|
* remove them from the queue, and then wake them. Pass all = true to wake
|
|
|
|
* whole queue; otherwise, just wake up to the walsender's LSN.
|
2011-03-07 00:39:14 +01:00
|
|
|
*
|
|
|
|
* Must hold SyncRepLock.
|
|
|
|
*/
|
|
|
|
int
|
|
|
|
SyncRepWakeQueue(bool all)
|
|
|
|
{
|
|
|
|
volatile WalSndCtlData *walsndctl = WalSndCtl;
|
|
|
|
PGPROC *proc = NULL;
|
|
|
|
PGPROC *thisproc = NULL;
|
|
|
|
int numprocs = 0;
|
|
|
|
|
|
|
|
Assert(SyncRepQueueIsOrderedByLSN());
|
|
|
|
|
|
|
|
proc = (PGPROC *) SHMQueueNext(&(WalSndCtl->SyncRepQueue),
|
|
|
|
&(WalSndCtl->SyncRepQueue),
|
|
|
|
offsetof(PGPROC, syncRepLinks));
|
|
|
|
|
|
|
|
while (proc)
|
|
|
|
{
|
|
|
|
/*
|
|
|
|
* Assume the queue is ordered by LSN
|
|
|
|
*/
|
|
|
|
if (!all && XLByteLT(walsndctl->lsn, proc->waitLSN))
|
|
|
|
return numprocs;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Move to next proc, so we can delete thisproc from the queue.
|
|
|
|
* thisproc is valid, proc may be NULL after this.
|
|
|
|
*/
|
|
|
|
thisproc = proc;
|
|
|
|
proc = (PGPROC *) SHMQueueNext(&(WalSndCtl->SyncRepQueue),
|
|
|
|
&(proc->syncRepLinks),
|
|
|
|
offsetof(PGPROC, syncRepLinks));
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Set state to complete; see SyncRepWaitForLSN() for discussion
|
|
|
|
* of the various states.
|
|
|
|
*/
|
|
|
|
thisproc->syncRepState = SYNC_REP_WAIT_COMPLETE;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Remove thisproc from queue.
|
|
|
|
*/
|
|
|
|
SHMQueueDelete(&(thisproc->syncRepLinks));
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Wake only when we have set state and removed from queue.
|
|
|
|
*/
|
|
|
|
Assert(SHMQueueIsDetached(&(thisproc->syncRepLinks)));
|
|
|
|
Assert(thisproc->syncRepState == SYNC_REP_WAIT_COMPLETE);
|
|
|
|
SetLatch(&(thisproc->waitLatch));
|
|
|
|
|
|
|
|
numprocs++;
|
|
|
|
}
|
|
|
|
|
|
|
|
return numprocs;
|
|
|
|
}
|
|
|
|
|
Fix various possible problems with synchronous replication.
1. Don't ignore query cancel interrupts. Instead, if the user asks to
cancel the query after we've already committed it, but before it's on
the standby, just emit a warning and let the COMMIT finish.
2. Don't ignore die interrupts (pg_terminate_backend or fast shutdown).
Instead, emit a warning message and close the connection without
acknowledging the commit. Other backends will still see the effect of
the commit, but there's no getting around that; it's too late to abort
at this point, and ignoring die interrupts altogether doesn't seem like
a good idea.
3. If synchronous_standby_names becomes empty, wake up all backends
waiting for synchronous replication to complete. Without this, someone
attempting to shut synchronous replication off could easily wedge the
entire system instead.
4. Avoid depending on the assumption that if a walsender updates
MyProc->syncRepState, we'll see the change even if we read it without
holding the lock. The window for this appears to be quite narrow (and
probably doesn't exist at all on machines with strong memory ordering)
but protecting against it is practically free, so do that.
5. Remove useless state SYNC_REP_MUST_DISCONNECT, which isn't needed and
doesn't actually do anything.
There's still some further work needed here to make the behavior of fast
shutdown plausible, but that looks complex, so I'm leaving it for a
separate commit. Review by Fujii Masao.
2011-03-17 18:10:42 +01:00
|
|
|
/*
|
|
|
|
* WAL writer calls this as needed to update the shared sync_standbys_defined
|
|
|
|
* flag, so that backends don't remain permanently wedged if
|
|
|
|
* synchronous_standby_names is unset. It's safe to check the current value
|
|
|
|
* without the lock, because it's only ever updated by one process. But we
|
|
|
|
* must take the lock to change it.
|
|
|
|
*/
|
|
|
|
void
|
|
|
|
SyncRepUpdateSyncStandbysDefined(void)
|
|
|
|
{
|
|
|
|
bool sync_standbys_defined = SyncStandbysDefined();
|
|
|
|
|
|
|
|
if (sync_standbys_defined != WalSndCtl->sync_standbys_defined)
|
|
|
|
{
|
|
|
|
LWLockAcquire(SyncRepLock, LW_EXCLUSIVE);
|
|
|
|
|
|
|
|
/*
|
|
|
|
* If synchronous_standby_names has been reset to empty, it's futile
|
|
|
|
* for backends to continue to waiting. Since the user no longer
|
|
|
|
* wants synchronous replication, we'd better wake them up.
|
|
|
|
*/
|
|
|
|
if (!sync_standbys_defined)
|
|
|
|
SyncRepWakeQueue(true);
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Only allow people to join the queue when there are synchronous
|
|
|
|
* standbys defined. Without this interlock, there's a race
|
|
|
|
* condition: we might wake up all the current waiters; then, some
|
|
|
|
* backend that hasn't yet reloaded its config might go to sleep on
|
|
|
|
* the queue (and never wake up). This prevents that.
|
|
|
|
*/
|
|
|
|
WalSndCtl->sync_standbys_defined = sync_standbys_defined;
|
|
|
|
|
|
|
|
LWLockRelease(SyncRepLock);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2011-03-07 00:39:14 +01:00
|
|
|
#ifdef USE_ASSERT_CHECKING
|
|
|
|
static bool
|
|
|
|
SyncRepQueueIsOrderedByLSN(void)
|
|
|
|
{
|
|
|
|
PGPROC *proc = NULL;
|
|
|
|
XLogRecPtr lastLSN;
|
|
|
|
|
|
|
|
lastLSN.xlogid = 0;
|
|
|
|
lastLSN.xrecoff = 0;
|
|
|
|
|
|
|
|
proc = (PGPROC *) SHMQueueNext(&(WalSndCtl->SyncRepQueue),
|
|
|
|
&(WalSndCtl->SyncRepQueue),
|
|
|
|
offsetof(PGPROC, syncRepLinks));
|
|
|
|
|
|
|
|
while (proc)
|
|
|
|
{
|
|
|
|
/*
|
|
|
|
* Check the queue is ordered by LSN and that multiple
|
|
|
|
* procs don't have matching LSNs
|
|
|
|
*/
|
|
|
|
if (XLByteLE(proc->waitLSN, lastLSN))
|
|
|
|
return false;
|
|
|
|
|
|
|
|
lastLSN = proc->waitLSN;
|
|
|
|
|
|
|
|
proc = (PGPROC *) SHMQueueNext(&(WalSndCtl->SyncRepQueue),
|
|
|
|
&(proc->syncRepLinks),
|
|
|
|
offsetof(PGPROC, syncRepLinks));
|
|
|
|
}
|
|
|
|
|
|
|
|
return true;
|
|
|
|
}
|
|
|
|
#endif
|
|
|
|
|
|
|
|
/*
|
|
|
|
* ===========================================================
|
|
|
|
* Synchronous Replication functions executed by any process
|
|
|
|
* ===========================================================
|
|
|
|
*/
|
|
|
|
|
|
|
|
const char *
|
|
|
|
assign_synchronous_standby_names(const char *newval, bool doit, GucSource source)
|
|
|
|
{
|
|
|
|
char *rawstring;
|
|
|
|
List *elemlist;
|
|
|
|
|
|
|
|
/* Need a modifiable copy of string */
|
|
|
|
rawstring = pstrdup(newval);
|
|
|
|
|
|
|
|
/* Parse string into list of identifiers */
|
|
|
|
if (!SplitIdentifierString(rawstring, ',', &elemlist))
|
|
|
|
{
|
|
|
|
/* syntax error in list */
|
|
|
|
pfree(rawstring);
|
|
|
|
list_free(elemlist);
|
2011-03-10 22:24:52 +01:00
|
|
|
ereport(GUC_complaint_elevel(source),
|
2011-03-07 00:39:14 +01:00
|
|
|
(errcode(ERRCODE_INVALID_PARAMETER_VALUE),
|
|
|
|
errmsg("invalid list syntax for parameter \"synchronous_standby_names\"")));
|
|
|
|
return NULL;
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Any additional validation of standby names should go here.
|
|
|
|
*
|
|
|
|
* Don't attempt to set WALSender priority because this is executed by
|
|
|
|
* postmaster at startup, not WALSender, so the application_name is
|
|
|
|
* not yet correctly set.
|
|
|
|
*/
|
|
|
|
|
|
|
|
pfree(rawstring);
|
|
|
|
list_free(elemlist);
|
|
|
|
|
|
|
|
return newval;
|
|
|
|
}
|