Introduce latches. A latch is a boolean variable, with the capability to
wait until it is set. Latches can be used to reliably wait until a signal
arrives, which is hard otherwise because signals don't interrupt select()
on some platforms, and even when they do, there's race conditions.
On Unix, latches use the so called self-pipe trick under the covers to
implement the sleep until the latch is set, without race conditions. On
Windows, Windows events are used.
Use the new latch abstraction to sleep in walsender, so that as soon as
a transaction finishes, walsender is woken up to immediately send the WAL
to the standby. This reduces the latency between master and standby, which
is good.
Preliminary work by Fujii Masao. The latch implementation is by me, with
helpful comments from many people.
2010-09-11 17:48:04 +02:00
|
|
|
/*-------------------------------------------------------------------------
|
|
|
|
*
|
|
|
|
* unix_latch.c
|
|
|
|
* Routines for inter-process latches
|
|
|
|
*
|
|
|
|
* The Unix implementation uses the so-called self-pipe trick to overcome
|
|
|
|
* the race condition involved with select() and setting a global flag
|
|
|
|
* in the signal handler. When a latch is set and the current process
|
|
|
|
* is waiting for it, the signal handler wakes up the select() in
|
|
|
|
* WaitLatch by writing a byte to a pipe. A signal by itself doesn't
|
|
|
|
* interrupt select() on all platforms, and even on platforms where it
|
|
|
|
* does, a signal that arrives just before the select() call does not
|
|
|
|
* prevent the select() from entering sleep. An incoming byte on a pipe
|
2011-08-09 21:30:45 +02:00
|
|
|
* however reliably interrupts the sleep, and causes select() to return
|
|
|
|
* immediately even if the signal arrives before select() begins.
|
Introduce latches. A latch is a boolean variable, with the capability to
wait until it is set. Latches can be used to reliably wait until a signal
arrives, which is hard otherwise because signals don't interrupt select()
on some platforms, and even when they do, there's race conditions.
On Unix, latches use the so called self-pipe trick under the covers to
implement the sleep until the latch is set, without race conditions. On
Windows, Windows events are used.
Use the new latch abstraction to sleep in walsender, so that as soon as
a transaction finishes, walsender is woken up to immediately send the WAL
to the standby. This reduces the latency between master and standby, which
is good.
Preliminary work by Fujii Masao. The latch implementation is by me, with
helpful comments from many people.
2010-09-11 17:48:04 +02:00
|
|
|
*
|
2011-08-11 18:49:45 +02:00
|
|
|
* (Actually, we prefer poll() over select() where available, but the
|
|
|
|
* same comments apply to it.)
|
|
|
|
*
|
Introduce latches. A latch is a boolean variable, with the capability to
wait until it is set. Latches can be used to reliably wait until a signal
arrives, which is hard otherwise because signals don't interrupt select()
on some platforms, and even when they do, there's race conditions.
On Unix, latches use the so called self-pipe trick under the covers to
implement the sleep until the latch is set, without race conditions. On
Windows, Windows events are used.
Use the new latch abstraction to sleep in walsender, so that as soon as
a transaction finishes, walsender is woken up to immediately send the WAL
to the standby. This reduces the latency between master and standby, which
is good.
Preliminary work by Fujii Masao. The latch implementation is by me, with
helpful comments from many people.
2010-09-11 17:48:04 +02:00
|
|
|
* When SetLatch is called from the same process that owns the latch,
|
|
|
|
* SetLatch writes the byte directly to the pipe. If it's owned by another
|
|
|
|
* process, SIGUSR1 is sent and the signal handler in the waiting process
|
|
|
|
* writes the byte to the pipe on behalf of the signaling process.
|
|
|
|
*
|
2016-01-02 19:33:40 +01:00
|
|
|
* Portions Copyright (c) 1996-2016, PostgreSQL Global Development Group
|
Introduce latches. A latch is a boolean variable, with the capability to
wait until it is set. Latches can be used to reliably wait until a signal
arrives, which is hard otherwise because signals don't interrupt select()
on some platforms, and even when they do, there's race conditions.
On Unix, latches use the so called self-pipe trick under the covers to
implement the sleep until the latch is set, without race conditions. On
Windows, Windows events are used.
Use the new latch abstraction to sleep in walsender, so that as soon as
a transaction finishes, walsender is woken up to immediately send the WAL
to the standby. This reduces the latency between master and standby, which
is good.
Preliminary work by Fujii Masao. The latch implementation is by me, with
helpful comments from many people.
2010-09-11 17:48:04 +02:00
|
|
|
* Portions Copyright (c) 1994, Regents of the University of California
|
|
|
|
*
|
|
|
|
* IDENTIFICATION
|
2010-09-20 22:08:53 +02:00
|
|
|
* src/backend/port/unix_latch.c
|
Introduce latches. A latch is a boolean variable, with the capability to
wait until it is set. Latches can be used to reliably wait until a signal
arrives, which is hard otherwise because signals don't interrupt select()
on some platforms, and even when they do, there's race conditions.
On Unix, latches use the so called self-pipe trick under the covers to
implement the sleep until the latch is set, without race conditions. On
Windows, Windows events are used.
Use the new latch abstraction to sleep in walsender, so that as soon as
a transaction finishes, walsender is woken up to immediately send the WAL
to the standby. This reduces the latency between master and standby, which
is good.
Preliminary work by Fujii Masao. The latch implementation is by me, with
helpful comments from many people.
2010-09-11 17:48:04 +02:00
|
|
|
*
|
|
|
|
*-------------------------------------------------------------------------
|
|
|
|
*/
|
|
|
|
#include "postgres.h"
|
|
|
|
|
|
|
|
#include <fcntl.h>
|
2012-11-18 21:39:51 +01:00
|
|
|
#include <limits.h>
|
Introduce latches. A latch is a boolean variable, with the capability to
wait until it is set. Latches can be used to reliably wait until a signal
arrives, which is hard otherwise because signals don't interrupt select()
on some platforms, and even when they do, there's race conditions.
On Unix, latches use the so called self-pipe trick under the covers to
implement the sleep until the latch is set, without race conditions. On
Windows, Windows events are used.
Use the new latch abstraction to sleep in walsender, so that as soon as
a transaction finishes, walsender is woken up to immediately send the WAL
to the standby. This reduces the latency between master and standby, which
is good.
Preliminary work by Fujii Masao. The latch implementation is by me, with
helpful comments from many people.
2010-09-11 17:48:04 +02:00
|
|
|
#include <signal.h>
|
|
|
|
#include <unistd.h>
|
2010-09-11 18:26:04 +02:00
|
|
|
#include <sys/time.h>
|
|
|
|
#include <sys/types.h>
|
2011-08-11 18:49:45 +02:00
|
|
|
#ifdef HAVE_POLL_H
|
|
|
|
#include <poll.h>
|
|
|
|
#endif
|
|
|
|
#ifdef HAVE_SYS_POLL_H
|
|
|
|
#include <sys/poll.h>
|
|
|
|
#endif
|
2010-09-11 18:26:04 +02:00
|
|
|
#ifdef HAVE_SYS_SELECT_H
|
|
|
|
#include <sys/select.h>
|
|
|
|
#endif
|
Introduce latches. A latch is a boolean variable, with the capability to
wait until it is set. Latches can be used to reliably wait until a signal
arrives, which is hard otherwise because signals don't interrupt select()
on some platforms, and even when they do, there's race conditions.
On Unix, latches use the so called self-pipe trick under the covers to
implement the sleep until the latch is set, without race conditions. On
Windows, Windows events are used.
Use the new latch abstraction to sleep in walsender, so that as soon as
a transaction finishes, walsender is woken up to immediately send the WAL
to the standby. This reduces the latency between master and standby, which
is good.
Preliminary work by Fujii Masao. The latch implementation is by me, with
helpful comments from many people.
2010-09-11 17:48:04 +02:00
|
|
|
|
|
|
|
#include "miscadmin.h"
|
2012-11-09 02:04:48 +01:00
|
|
|
#include "portability/instr_time.h"
|
Introduce a pipe between postmaster and each backend, which can be used to
detect postmaster death. Postmaster keeps the write-end of the pipe open,
so when it dies, children get EOF in the read-end. That can conveniently
be waited for in select(), which allows eliminating some of the polling
loops that check for postmaster death. This patch doesn't yet change all
the loops to use the new mechanism, expect a follow-on patch to do that.
This changes the interface to WaitLatch, so that it takes as argument a
bitmask of events that it waits for. Possible events are latch set, timeout,
postmaster death, and socket becoming readable or writeable.
The pipe method behaves slightly differently from the kill() method
previously used in PostmasterIsAlive() in the case that postmaster has died,
but its parent has not yet read its exit code with waitpid(). The pipe
returns EOF as soon as the process dies, but kill() continues to return
true until waitpid() has been called (IOW while the process is a zombie).
Because of that, change PostmasterIsAlive() to use the pipe too, otherwise
WaitLatch() would return immediately with WL_POSTMASTER_DEATH, while
PostmasterIsAlive() would claim it's still alive. That could easily lead to
busy-waiting while postmaster is in zombie state.
Peter Geoghegan with further changes by me, reviewed by Fujii Masao and
Florian Pflug.
2011-07-08 17:27:49 +02:00
|
|
|
#include "postmaster/postmaster.h"
|
2015-01-13 12:58:43 +01:00
|
|
|
#include "storage/barrier.h"
|
Introduce latches. A latch is a boolean variable, with the capability to
wait until it is set. Latches can be used to reliably wait until a signal
arrives, which is hard otherwise because signals don't interrupt select()
on some platforms, and even when they do, there's race conditions.
On Unix, latches use the so called self-pipe trick under the covers to
implement the sleep until the latch is set, without race conditions. On
Windows, Windows events are used.
Use the new latch abstraction to sleep in walsender, so that as soon as
a transaction finishes, walsender is woken up to immediately send the WAL
to the standby. This reduces the latency between master and standby, which
is good.
Preliminary work by Fujii Masao. The latch implementation is by me, with
helpful comments from many people.
2010-09-11 17:48:04 +02:00
|
|
|
#include "storage/latch.h"
|
2012-05-10 20:34:22 +02:00
|
|
|
#include "storage/pmsignal.h"
|
Introduce latches. A latch is a boolean variable, with the capability to
wait until it is set. Latches can be used to reliably wait until a signal
arrives, which is hard otherwise because signals don't interrupt select()
on some platforms, and even when they do, there's race conditions.
On Unix, latches use the so called self-pipe trick under the covers to
implement the sleep until the latch is set, without race conditions. On
Windows, Windows events are used.
Use the new latch abstraction to sleep in walsender, so that as soon as
a transaction finishes, walsender is woken up to immediately send the WAL
to the standby. This reduces the latency between master and standby, which
is good.
Preliminary work by Fujii Masao. The latch implementation is by me, with
helpful comments from many people.
2010-09-11 17:48:04 +02:00
|
|
|
#include "storage/shmem.h"
|
|
|
|
|
2016-03-18 19:43:59 +01:00
|
|
|
/*
|
|
|
|
* Select the fd readiness primitive to use. Normally the "most modern"
|
|
|
|
* primitive supported by the OS will be used, but for testing it can be
|
|
|
|
* useful to manually specify the used primitive. If desired, just add a
|
|
|
|
* define somewhere before this block.
|
|
|
|
*/
|
|
|
|
#if defined(LATCH_USE_POLL) || defined(LATCH_USE_SELECT)
|
|
|
|
/* don't overwrite manual choice */
|
|
|
|
#elif defined(HAVE_POLL)
|
|
|
|
#define LATCH_USE_POLL
|
|
|
|
#elif HAVE_SYS_SELECT_H
|
|
|
|
#define LATCH_USE_SELECT
|
|
|
|
#else
|
|
|
|
#error "no latch implementation available"
|
|
|
|
#endif
|
|
|
|
|
Introduce latches. A latch is a boolean variable, with the capability to
wait until it is set. Latches can be used to reliably wait until a signal
arrives, which is hard otherwise because signals don't interrupt select()
on some platforms, and even when they do, there's race conditions.
On Unix, latches use the so called self-pipe trick under the covers to
implement the sleep until the latch is set, without race conditions. On
Windows, Windows events are used.
Use the new latch abstraction to sleep in walsender, so that as soon as
a transaction finishes, walsender is woken up to immediately send the WAL
to the standby. This reduces the latency between master and standby, which
is good.
Preliminary work by Fujii Masao. The latch implementation is by me, with
helpful comments from many people.
2010-09-11 17:48:04 +02:00
|
|
|
/* Are we currently in WaitLatch? The signal handler would like to know. */
|
|
|
|
static volatile sig_atomic_t waiting = false;
|
|
|
|
|
2011-08-09 21:30:45 +02:00
|
|
|
/* Read and write ends of the self-pipe */
|
2011-04-10 17:42:00 +02:00
|
|
|
static int selfpipe_readfd = -1;
|
|
|
|
static int selfpipe_writefd = -1;
|
Introduce latches. A latch is a boolean variable, with the capability to
wait until it is set. Latches can be used to reliably wait until a signal
arrives, which is hard otherwise because signals don't interrupt select()
on some platforms, and even when they do, there's race conditions.
On Unix, latches use the so called self-pipe trick under the covers to
implement the sleep until the latch is set, without race conditions. On
Windows, Windows events are used.
Use the new latch abstraction to sleep in walsender, so that as soon as
a transaction finishes, walsender is woken up to immediately send the WAL
to the standby. This reduces the latency between master and standby, which
is good.
Preliminary work by Fujii Masao. The latch implementation is by me, with
helpful comments from many people.
2010-09-11 17:48:04 +02:00
|
|
|
|
2012-10-15 04:59:56 +02:00
|
|
|
/* Private function prototypes */
|
Introduce latches. A latch is a boolean variable, with the capability to
wait until it is set. Latches can be used to reliably wait until a signal
arrives, which is hard otherwise because signals don't interrupt select()
on some platforms, and even when they do, there's race conditions.
On Unix, latches use the so called self-pipe trick under the covers to
implement the sleep until the latch is set, without race conditions. On
Windows, Windows events are used.
Use the new latch abstraction to sleep in walsender, so that as soon as
a transaction finishes, walsender is woken up to immediately send the WAL
to the standby. This reduces the latency between master and standby, which
is good.
Preliminary work by Fujii Masao. The latch implementation is by me, with
helpful comments from many people.
2010-09-11 17:48:04 +02:00
|
|
|
static void sendSelfPipeByte(void);
|
2012-10-15 04:59:56 +02:00
|
|
|
static void drainSelfPipe(void);
|
|
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Initialize the process-local latch infrastructure.
|
|
|
|
*
|
|
|
|
* This must be called once during startup of any process that can wait on
|
|
|
|
* latches, before it issues any InitLatch() or OwnLatch() calls.
|
|
|
|
*/
|
|
|
|
void
|
|
|
|
InitializeLatchSupport(void)
|
|
|
|
{
|
|
|
|
int pipefd[2];
|
|
|
|
|
|
|
|
Assert(selfpipe_readfd == -1);
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Set up the self-pipe that allows a signal handler to wake up the
|
|
|
|
* select() in WaitLatch. Make the write-end non-blocking, so that
|
|
|
|
* SetLatch won't block if the event has already been set many times
|
|
|
|
* filling the kernel buffer. Make the read-end non-blocking too, so that
|
|
|
|
* we can easily clear the pipe by reading until EAGAIN or EWOULDBLOCK.
|
|
|
|
*/
|
|
|
|
if (pipe(pipefd) < 0)
|
|
|
|
elog(FATAL, "pipe() failed: %m");
|
|
|
|
if (fcntl(pipefd[0], F_SETFL, O_NONBLOCK) < 0)
|
|
|
|
elog(FATAL, "fcntl() failed on read-end of self-pipe: %m");
|
|
|
|
if (fcntl(pipefd[1], F_SETFL, O_NONBLOCK) < 0)
|
|
|
|
elog(FATAL, "fcntl() failed on write-end of self-pipe: %m");
|
Introduce latches. A latch is a boolean variable, with the capability to
wait until it is set. Latches can be used to reliably wait until a signal
arrives, which is hard otherwise because signals don't interrupt select()
on some platforms, and even when they do, there's race conditions.
On Unix, latches use the so called self-pipe trick under the covers to
implement the sleep until the latch is set, without race conditions. On
Windows, Windows events are used.
Use the new latch abstraction to sleep in walsender, so that as soon as
a transaction finishes, walsender is woken up to immediately send the WAL
to the standby. This reduces the latency between master and standby, which
is good.
Preliminary work by Fujii Masao. The latch implementation is by me, with
helpful comments from many people.
2010-09-11 17:48:04 +02:00
|
|
|
|
2012-10-15 04:59:56 +02:00
|
|
|
selfpipe_readfd = pipefd[0];
|
|
|
|
selfpipe_writefd = pipefd[1];
|
|
|
|
}
|
Introduce latches. A latch is a boolean variable, with the capability to
wait until it is set. Latches can be used to reliably wait until a signal
arrives, which is hard otherwise because signals don't interrupt select()
on some platforms, and even when they do, there's race conditions.
On Unix, latches use the so called self-pipe trick under the covers to
implement the sleep until the latch is set, without race conditions. On
Windows, Windows events are used.
Use the new latch abstraction to sleep in walsender, so that as soon as
a transaction finishes, walsender is woken up to immediately send the WAL
to the standby. This reduces the latency between master and standby, which
is good.
Preliminary work by Fujii Masao. The latch implementation is by me, with
helpful comments from many people.
2010-09-11 17:48:04 +02:00
|
|
|
|
|
|
|
/*
|
|
|
|
* Initialize a backend-local latch.
|
|
|
|
*/
|
|
|
|
void
|
|
|
|
InitLatch(volatile Latch *latch)
|
|
|
|
{
|
2012-10-15 04:59:56 +02:00
|
|
|
/* Assert InitializeLatchSupport has been called in this process */
|
|
|
|
Assert(selfpipe_readfd >= 0);
|
Introduce latches. A latch is a boolean variable, with the capability to
wait until it is set. Latches can be used to reliably wait until a signal
arrives, which is hard otherwise because signals don't interrupt select()
on some platforms, and even when they do, there's race conditions.
On Unix, latches use the so called self-pipe trick under the covers to
implement the sleep until the latch is set, without race conditions. On
Windows, Windows events are used.
Use the new latch abstraction to sleep in walsender, so that as soon as
a transaction finishes, walsender is woken up to immediately send the WAL
to the standby. This reduces the latency between master and standby, which
is good.
Preliminary work by Fujii Masao. The latch implementation is by me, with
helpful comments from many people.
2010-09-11 17:48:04 +02:00
|
|
|
|
|
|
|
latch->is_set = false;
|
|
|
|
latch->owner_pid = MyProcPid;
|
|
|
|
latch->is_shared = false;
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Initialize a shared latch that can be set from other processes. The latch
|
2011-08-09 21:30:45 +02:00
|
|
|
* is initially owned by no-one; use OwnLatch to associate it with the
|
Introduce latches. A latch is a boolean variable, with the capability to
wait until it is set. Latches can be used to reliably wait until a signal
arrives, which is hard otherwise because signals don't interrupt select()
on some platforms, and even when they do, there's race conditions.
On Unix, latches use the so called self-pipe trick under the covers to
implement the sleep until the latch is set, without race conditions. On
Windows, Windows events are used.
Use the new latch abstraction to sleep in walsender, so that as soon as
a transaction finishes, walsender is woken up to immediately send the WAL
to the standby. This reduces the latency between master and standby, which
is good.
Preliminary work by Fujii Masao. The latch implementation is by me, with
helpful comments from many people.
2010-09-11 17:48:04 +02:00
|
|
|
* current process.
|
|
|
|
*
|
2010-09-15 12:06:21 +02:00
|
|
|
* InitSharedLatch needs to be called in postmaster before forking child
|
|
|
|
* processes, usually right after allocating the shared memory block
|
2011-08-09 21:30:45 +02:00
|
|
|
* containing the latch with ShmemInitStruct. (The Unix implementation
|
|
|
|
* doesn't actually require that, but the Windows one does.) Because of
|
|
|
|
* this restriction, we have no concurrency issues to worry about here.
|
Introduce latches. A latch is a boolean variable, with the capability to
wait until it is set. Latches can be used to reliably wait until a signal
arrives, which is hard otherwise because signals don't interrupt select()
on some platforms, and even when they do, there's race conditions.
On Unix, latches use the so called self-pipe trick under the covers to
implement the sleep until the latch is set, without race conditions. On
Windows, Windows events are used.
Use the new latch abstraction to sleep in walsender, so that as soon as
a transaction finishes, walsender is woken up to immediately send the WAL
to the standby. This reduces the latency between master and standby, which
is good.
Preliminary work by Fujii Masao. The latch implementation is by me, with
helpful comments from many people.
2010-09-11 17:48:04 +02:00
|
|
|
*/
|
|
|
|
void
|
|
|
|
InitSharedLatch(volatile Latch *latch)
|
|
|
|
{
|
|
|
|
latch->is_set = false;
|
|
|
|
latch->owner_pid = 0;
|
|
|
|
latch->is_shared = true;
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Associate a shared latch with the current process, allowing it to
|
2011-08-09 21:30:45 +02:00
|
|
|
* wait on the latch.
|
|
|
|
*
|
|
|
|
* Although there is a sanity check for latch-already-owned, we don't do
|
|
|
|
* any sort of locking here, meaning that we could fail to detect the error
|
|
|
|
* if two processes try to own the same latch at about the same time. If
|
|
|
|
* there is any risk of that, caller must provide an interlock to prevent it.
|
Introduce latches. A latch is a boolean variable, with the capability to
wait until it is set. Latches can be used to reliably wait until a signal
arrives, which is hard otherwise because signals don't interrupt select()
on some platforms, and even when they do, there's race conditions.
On Unix, latches use the so called self-pipe trick under the covers to
implement the sleep until the latch is set, without race conditions. On
Windows, Windows events are used.
Use the new latch abstraction to sleep in walsender, so that as soon as
a transaction finishes, walsender is woken up to immediately send the WAL
to the standby. This reduces the latency between master and standby, which
is good.
Preliminary work by Fujii Masao. The latch implementation is by me, with
helpful comments from many people.
2010-09-11 17:48:04 +02:00
|
|
|
*
|
2011-08-09 21:30:45 +02:00
|
|
|
* In any process that calls OwnLatch(), make sure that
|
|
|
|
* latch_sigusr1_handler() is called from the SIGUSR1 signal handler,
|
|
|
|
* as shared latches use SIGUSR1 for inter-process communication.
|
Introduce latches. A latch is a boolean variable, with the capability to
wait until it is set. Latches can be used to reliably wait until a signal
arrives, which is hard otherwise because signals don't interrupt select()
on some platforms, and even when they do, there's race conditions.
On Unix, latches use the so called self-pipe trick under the covers to
implement the sleep until the latch is set, without race conditions. On
Windows, Windows events are used.
Use the new latch abstraction to sleep in walsender, so that as soon as
a transaction finishes, walsender is woken up to immediately send the WAL
to the standby. This reduces the latency between master and standby, which
is good.
Preliminary work by Fujii Masao. The latch implementation is by me, with
helpful comments from many people.
2010-09-11 17:48:04 +02:00
|
|
|
*/
|
|
|
|
void
|
|
|
|
OwnLatch(volatile Latch *latch)
|
|
|
|
{
|
2012-10-15 04:59:56 +02:00
|
|
|
/* Assert InitializeLatchSupport has been called in this process */
|
|
|
|
Assert(selfpipe_readfd >= 0);
|
Introduce latches. A latch is a boolean variable, with the capability to
wait until it is set. Latches can be used to reliably wait until a signal
arrives, which is hard otherwise because signals don't interrupt select()
on some platforms, and even when they do, there's race conditions.
On Unix, latches use the so called self-pipe trick under the covers to
implement the sleep until the latch is set, without race conditions. On
Windows, Windows events are used.
Use the new latch abstraction to sleep in walsender, so that as soon as
a transaction finishes, walsender is woken up to immediately send the WAL
to the standby. This reduces the latency between master and standby, which
is good.
Preliminary work by Fujii Masao. The latch implementation is by me, with
helpful comments from many people.
2010-09-11 17:48:04 +02:00
|
|
|
|
2012-10-15 04:59:56 +02:00
|
|
|
Assert(latch->is_shared);
|
Introduce latches. A latch is a boolean variable, with the capability to
wait until it is set. Latches can be used to reliably wait until a signal
arrives, which is hard otherwise because signals don't interrupt select()
on some platforms, and even when they do, there's race conditions.
On Unix, latches use the so called self-pipe trick under the covers to
implement the sleep until the latch is set, without race conditions. On
Windows, Windows events are used.
Use the new latch abstraction to sleep in walsender, so that as soon as
a transaction finishes, walsender is woken up to immediately send the WAL
to the standby. This reduces the latency between master and standby, which
is good.
Preliminary work by Fujii Masao. The latch implementation is by me, with
helpful comments from many people.
2010-09-11 17:48:04 +02:00
|
|
|
|
2010-09-13 20:01:20 +02:00
|
|
|
/* sanity check */
|
Introduce latches. A latch is a boolean variable, with the capability to
wait until it is set. Latches can be used to reliably wait until a signal
arrives, which is hard otherwise because signals don't interrupt select()
on some platforms, and even when they do, there's race conditions.
On Unix, latches use the so called self-pipe trick under the covers to
implement the sleep until the latch is set, without race conditions. On
Windows, Windows events are used.
Use the new latch abstraction to sleep in walsender, so that as soon as
a transaction finishes, walsender is woken up to immediately send the WAL
to the standby. This reduces the latency between master and standby, which
is good.
Preliminary work by Fujii Masao. The latch implementation is by me, with
helpful comments from many people.
2010-09-11 17:48:04 +02:00
|
|
|
if (latch->owner_pid != 0)
|
|
|
|
elog(ERROR, "latch already owned");
|
2011-08-09 21:30:45 +02:00
|
|
|
|
Introduce latches. A latch is a boolean variable, with the capability to
wait until it is set. Latches can be used to reliably wait until a signal
arrives, which is hard otherwise because signals don't interrupt select()
on some platforms, and even when they do, there's race conditions.
On Unix, latches use the so called self-pipe trick under the covers to
implement the sleep until the latch is set, without race conditions. On
Windows, Windows events are used.
Use the new latch abstraction to sleep in walsender, so that as soon as
a transaction finishes, walsender is woken up to immediately send the WAL
to the standby. This reduces the latency between master and standby, which
is good.
Preliminary work by Fujii Masao. The latch implementation is by me, with
helpful comments from many people.
2010-09-11 17:48:04 +02:00
|
|
|
latch->owner_pid = MyProcPid;
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Disown a shared latch currently owned by the current process.
|
|
|
|
*/
|
|
|
|
void
|
|
|
|
DisownLatch(volatile Latch *latch)
|
|
|
|
{
|
|
|
|
Assert(latch->is_shared);
|
|
|
|
Assert(latch->owner_pid == MyProcPid);
|
2011-08-09 21:30:45 +02:00
|
|
|
|
Introduce latches. A latch is a boolean variable, with the capability to
wait until it is set. Latches can be used to reliably wait until a signal
arrives, which is hard otherwise because signals don't interrupt select()
on some platforms, and even when they do, there's race conditions.
On Unix, latches use the so called self-pipe trick under the covers to
implement the sleep until the latch is set, without race conditions. On
Windows, Windows events are used.
Use the new latch abstraction to sleep in walsender, so that as soon as
a transaction finishes, walsender is woken up to immediately send the WAL
to the standby. This reduces the latency between master and standby, which
is good.
Preliminary work by Fujii Masao. The latch implementation is by me, with
helpful comments from many people.
2010-09-11 17:48:04 +02:00
|
|
|
latch->owner_pid = 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
2011-08-09 21:30:45 +02:00
|
|
|
* Wait for a given latch to be set, or for postmaster death, or until timeout
|
|
|
|
* is exceeded. 'wakeEvents' is a bitmask that specifies which of those events
|
Introduce a pipe between postmaster and each backend, which can be used to
detect postmaster death. Postmaster keeps the write-end of the pipe open,
so when it dies, children get EOF in the read-end. That can conveniently
be waited for in select(), which allows eliminating some of the polling
loops that check for postmaster death. This patch doesn't yet change all
the loops to use the new mechanism, expect a follow-on patch to do that.
This changes the interface to WaitLatch, so that it takes as argument a
bitmask of events that it waits for. Possible events are latch set, timeout,
postmaster death, and socket becoming readable or writeable.
The pipe method behaves slightly differently from the kill() method
previously used in PostmasterIsAlive() in the case that postmaster has died,
but its parent has not yet read its exit code with waitpid(). The pipe
returns EOF as soon as the process dies, but kill() continues to return
true until waitpid() has been called (IOW while the process is a zombie).
Because of that, change PostmasterIsAlive() to use the pipe too, otherwise
WaitLatch() would return immediately with WL_POSTMASTER_DEATH, while
PostmasterIsAlive() would claim it's still alive. That could easily lead to
busy-waiting while postmaster is in zombie state.
Peter Geoghegan with further changes by me, reviewed by Fujii Masao and
Florian Pflug.
2011-07-08 17:27:49 +02:00
|
|
|
* to wait for. If the latch is already set (and WL_LATCH_SET is given), the
|
|
|
|
* function returns immediately.
|
Introduce latches. A latch is a boolean variable, with the capability to
wait until it is set. Latches can be used to reliably wait until a signal
arrives, which is hard otherwise because signals don't interrupt select()
on some platforms, and even when they do, there's race conditions.
On Unix, latches use the so called self-pipe trick under the covers to
implement the sleep until the latch is set, without race conditions. On
Windows, Windows events are used.
Use the new latch abstraction to sleep in walsender, so that as soon as
a transaction finishes, walsender is woken up to immediately send the WAL
to the standby. This reduces the latency between master and standby, which
is good.
Preliminary work by Fujii Masao. The latch implementation is by me, with
helpful comments from many people.
2010-09-11 17:48:04 +02:00
|
|
|
*
|
2012-11-18 21:39:51 +01:00
|
|
|
* The "timeout" is given in milliseconds. It must be >= 0 if WL_TIMEOUT flag
|
|
|
|
* is given. Although it is declared as "long", we don't actually support
|
|
|
|
* timeouts longer than INT_MAX milliseconds. Note that some extra overhead
|
|
|
|
* is incurred when WL_TIMEOUT is given, so avoid using a timeout if possible.
|
Introduce latches. A latch is a boolean variable, with the capability to
wait until it is set. Latches can be used to reliably wait until a signal
arrives, which is hard otherwise because signals don't interrupt select()
on some platforms, and even when they do, there's race conditions.
On Unix, latches use the so called self-pipe trick under the covers to
implement the sleep until the latch is set, without race conditions. On
Windows, Windows events are used.
Use the new latch abstraction to sleep in walsender, so that as soon as
a transaction finishes, walsender is woken up to immediately send the WAL
to the standby. This reduces the latency between master and standby, which
is good.
Preliminary work by Fujii Masao. The latch implementation is by me, with
helpful comments from many people.
2010-09-11 17:48:04 +02:00
|
|
|
*
|
|
|
|
* The latch must be owned by the current process, ie. it must be a
|
|
|
|
* backend-local latch initialized with InitLatch, or a shared latch
|
|
|
|
* associated with the current process by calling OwnLatch.
|
|
|
|
*
|
2011-08-09 21:30:45 +02:00
|
|
|
* Returns bit mask indicating which condition(s) caused the wake-up. Note
|
Introduce a pipe between postmaster and each backend, which can be used to
detect postmaster death. Postmaster keeps the write-end of the pipe open,
so when it dies, children get EOF in the read-end. That can conveniently
be waited for in select(), which allows eliminating some of the polling
loops that check for postmaster death. This patch doesn't yet change all
the loops to use the new mechanism, expect a follow-on patch to do that.
This changes the interface to WaitLatch, so that it takes as argument a
bitmask of events that it waits for. Possible events are latch set, timeout,
postmaster death, and socket becoming readable or writeable.
The pipe method behaves slightly differently from the kill() method
previously used in PostmasterIsAlive() in the case that postmaster has died,
but its parent has not yet read its exit code with waitpid(). The pipe
returns EOF as soon as the process dies, but kill() continues to return
true until waitpid() has been called (IOW while the process is a zombie).
Because of that, change PostmasterIsAlive() to use the pipe too, otherwise
WaitLatch() would return immediately with WL_POSTMASTER_DEATH, while
PostmasterIsAlive() would claim it's still alive. That could easily lead to
busy-waiting while postmaster is in zombie state.
Peter Geoghegan with further changes by me, reviewed by Fujii Masao and
Florian Pflug.
2011-07-08 17:27:49 +02:00
|
|
|
* that if multiple wake-up conditions are true, there is no guarantee that
|
2012-05-10 20:34:22 +02:00
|
|
|
* we return all of them in one call, but we will return at least one.
|
Introduce latches. A latch is a boolean variable, with the capability to
wait until it is set. Latches can be used to reliably wait until a signal
arrives, which is hard otherwise because signals don't interrupt select()
on some platforms, and even when they do, there's race conditions.
On Unix, latches use the so called self-pipe trick under the covers to
implement the sleep until the latch is set, without race conditions. On
Windows, Windows events are used.
Use the new latch abstraction to sleep in walsender, so that as soon as
a transaction finishes, walsender is woken up to immediately send the WAL
to the standby. This reduces the latency between master and standby, which
is good.
Preliminary work by Fujii Masao. The latch implementation is by me, with
helpful comments from many people.
2010-09-11 17:48:04 +02:00
|
|
|
*/
|
Introduce a pipe between postmaster and each backend, which can be used to
detect postmaster death. Postmaster keeps the write-end of the pipe open,
so when it dies, children get EOF in the read-end. That can conveniently
be waited for in select(), which allows eliminating some of the polling
loops that check for postmaster death. This patch doesn't yet change all
the loops to use the new mechanism, expect a follow-on patch to do that.
This changes the interface to WaitLatch, so that it takes as argument a
bitmask of events that it waits for. Possible events are latch set, timeout,
postmaster death, and socket becoming readable or writeable.
The pipe method behaves slightly differently from the kill() method
previously used in PostmasterIsAlive() in the case that postmaster has died,
but its parent has not yet read its exit code with waitpid(). The pipe
returns EOF as soon as the process dies, but kill() continues to return
true until waitpid() has been called (IOW while the process is a zombie).
Because of that, change PostmasterIsAlive() to use the pipe too, otherwise
WaitLatch() would return immediately with WL_POSTMASTER_DEATH, while
PostmasterIsAlive() would claim it's still alive. That could easily lead to
busy-waiting while postmaster is in zombie state.
Peter Geoghegan with further changes by me, reviewed by Fujii Masao and
Florian Pflug.
2011-07-08 17:27:49 +02:00
|
|
|
int
|
|
|
|
WaitLatch(volatile Latch *latch, int wakeEvents, long timeout)
|
Introduce latches. A latch is a boolean variable, with the capability to
wait until it is set. Latches can be used to reliably wait until a signal
arrives, which is hard otherwise because signals don't interrupt select()
on some platforms, and even when they do, there's race conditions.
On Unix, latches use the so called self-pipe trick under the covers to
implement the sleep until the latch is set, without race conditions. On
Windows, Windows events are used.
Use the new latch abstraction to sleep in walsender, so that as soon as
a transaction finishes, walsender is woken up to immediately send the WAL
to the standby. This reduces the latency between master and standby, which
is good.
Preliminary work by Fujii Masao. The latch implementation is by me, with
helpful comments from many people.
2010-09-11 17:48:04 +02:00
|
|
|
{
|
Introduce a pipe between postmaster and each backend, which can be used to
detect postmaster death. Postmaster keeps the write-end of the pipe open,
so when it dies, children get EOF in the read-end. That can conveniently
be waited for in select(), which allows eliminating some of the polling
loops that check for postmaster death. This patch doesn't yet change all
the loops to use the new mechanism, expect a follow-on patch to do that.
This changes the interface to WaitLatch, so that it takes as argument a
bitmask of events that it waits for. Possible events are latch set, timeout,
postmaster death, and socket becoming readable or writeable.
The pipe method behaves slightly differently from the kill() method
previously used in PostmasterIsAlive() in the case that postmaster has died,
but its parent has not yet read its exit code with waitpid(). The pipe
returns EOF as soon as the process dies, but kill() continues to return
true until waitpid() has been called (IOW while the process is a zombie).
Because of that, change PostmasterIsAlive() to use the pipe too, otherwise
WaitLatch() would return immediately with WL_POSTMASTER_DEATH, while
PostmasterIsAlive() would claim it's still alive. That could easily lead to
busy-waiting while postmaster is in zombie state.
Peter Geoghegan with further changes by me, reviewed by Fujii Masao and
Florian Pflug.
2011-07-08 17:27:49 +02:00
|
|
|
return WaitLatchOrSocket(latch, wakeEvents, PGINVALID_SOCKET, timeout);
|
Introduce latches. A latch is a boolean variable, with the capability to
wait until it is set. Latches can be used to reliably wait until a signal
arrives, which is hard otherwise because signals don't interrupt select()
on some platforms, and even when they do, there's race conditions.
On Unix, latches use the so called self-pipe trick under the covers to
implement the sleep until the latch is set, without race conditions. On
Windows, Windows events are used.
Use the new latch abstraction to sleep in walsender, so that as soon as
a transaction finishes, walsender is woken up to immediately send the WAL
to the standby. This reduces the latency between master and standby, which
is good.
Preliminary work by Fujii Masao. The latch implementation is by me, with
helpful comments from many people.
2010-09-11 17:48:04 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
Introduce a pipe between postmaster and each backend, which can be used to
detect postmaster death. Postmaster keeps the write-end of the pipe open,
so when it dies, children get EOF in the read-end. That can conveniently
be waited for in select(), which allows eliminating some of the polling
loops that check for postmaster death. This patch doesn't yet change all
the loops to use the new mechanism, expect a follow-on patch to do that.
This changes the interface to WaitLatch, so that it takes as argument a
bitmask of events that it waits for. Possible events are latch set, timeout,
postmaster death, and socket becoming readable or writeable.
The pipe method behaves slightly differently from the kill() method
previously used in PostmasterIsAlive() in the case that postmaster has died,
but its parent has not yet read its exit code with waitpid(). The pipe
returns EOF as soon as the process dies, but kill() continues to return
true until waitpid() has been called (IOW while the process is a zombie).
Because of that, change PostmasterIsAlive() to use the pipe too, otherwise
WaitLatch() would return immediately with WL_POSTMASTER_DEATH, while
PostmasterIsAlive() would claim it's still alive. That could easily lead to
busy-waiting while postmaster is in zombie state.
Peter Geoghegan with further changes by me, reviewed by Fujii Masao and
Florian Pflug.
2011-07-08 17:27:49 +02:00
|
|
|
* Like WaitLatch, but with an extra socket argument for WL_SOCKET_*
|
|
|
|
* conditions.
|
2012-05-14 22:11:59 +02:00
|
|
|
*
|
2015-01-13 12:58:43 +01:00
|
|
|
* When waiting on a socket, EOF and error conditions are reported by
|
|
|
|
* returning the socket as readable/writable or both, depending on
|
|
|
|
* WL_SOCKET_READABLE/WL_SOCKET_WRITEABLE being specified.
|
Introduce latches. A latch is a boolean variable, with the capability to
wait until it is set. Latches can be used to reliably wait until a signal
arrives, which is hard otherwise because signals don't interrupt select()
on some platforms, and even when they do, there's race conditions.
On Unix, latches use the so called self-pipe trick under the covers to
implement the sleep until the latch is set, without race conditions. On
Windows, Windows events are used.
Use the new latch abstraction to sleep in walsender, so that as soon as
a transaction finishes, walsender is woken up to immediately send the WAL
to the standby. This reduces the latency between master and standby, which
is good.
Preliminary work by Fujii Masao. The latch implementation is by me, with
helpful comments from many people.
2010-09-11 17:48:04 +02:00
|
|
|
*/
|
|
|
|
int
|
Introduce a pipe between postmaster and each backend, which can be used to
detect postmaster death. Postmaster keeps the write-end of the pipe open,
so when it dies, children get EOF in the read-end. That can conveniently
be waited for in select(), which allows eliminating some of the polling
loops that check for postmaster death. This patch doesn't yet change all
the loops to use the new mechanism, expect a follow-on patch to do that.
This changes the interface to WaitLatch, so that it takes as argument a
bitmask of events that it waits for. Possible events are latch set, timeout,
postmaster death, and socket becoming readable or writeable.
The pipe method behaves slightly differently from the kill() method
previously used in PostmasterIsAlive() in the case that postmaster has died,
but its parent has not yet read its exit code with waitpid(). The pipe
returns EOF as soon as the process dies, but kill() continues to return
true until waitpid() has been called (IOW while the process is a zombie).
Because of that, change PostmasterIsAlive() to use the pipe too, otherwise
WaitLatch() would return immediately with WL_POSTMASTER_DEATH, while
PostmasterIsAlive() would claim it's still alive. That could easily lead to
busy-waiting while postmaster is in zombie state.
Peter Geoghegan with further changes by me, reviewed by Fujii Masao and
Florian Pflug.
2011-07-08 17:27:49 +02:00
|
|
|
WaitLatchOrSocket(volatile Latch *latch, int wakeEvents, pgsocket sock,
|
|
|
|
long timeout)
|
Introduce latches. A latch is a boolean variable, with the capability to
wait until it is set. Latches can be used to reliably wait until a signal
arrives, which is hard otherwise because signals don't interrupt select()
on some platforms, and even when they do, there's race conditions.
On Unix, latches use the so called self-pipe trick under the covers to
implement the sleep until the latch is set, without race conditions. On
Windows, Windows events are used.
Use the new latch abstraction to sleep in walsender, so that as soon as
a transaction finishes, walsender is woken up to immediately send the WAL
to the standby. This reduces the latency between master and standby, which
is good.
Preliminary work by Fujii Masao. The latch implementation is by me, with
helpful comments from many people.
2010-09-11 17:48:04 +02:00
|
|
|
{
|
2011-08-11 18:49:45 +02:00
|
|
|
int result = 0;
|
|
|
|
int rc;
|
2012-11-09 02:04:48 +01:00
|
|
|
instr_time start_time,
|
|
|
|
cur_time;
|
|
|
|
long cur_timeout;
|
2012-06-10 21:20:04 +02:00
|
|
|
|
2016-03-18 19:43:59 +01:00
|
|
|
#if defined(LATCH_USE_POLL)
|
2011-08-11 18:49:45 +02:00
|
|
|
struct pollfd pfds[3];
|
|
|
|
int nfds;
|
2016-03-18 19:43:59 +01:00
|
|
|
#elif defined(LATCH_USE_SELECT)
|
2011-04-10 17:42:00 +02:00
|
|
|
struct timeval tv,
|
2012-11-09 02:04:48 +01:00
|
|
|
*tvp;
|
Introduce latches. A latch is a boolean variable, with the capability to
wait until it is set. Latches can be used to reliably wait until a signal
arrives, which is hard otherwise because signals don't interrupt select()
on some platforms, and even when they do, there's race conditions.
On Unix, latches use the so called self-pipe trick under the covers to
implement the sleep until the latch is set, without race conditions. On
Windows, Windows events are used.
Use the new latch abstraction to sleep in walsender, so that as soon as
a transaction finishes, walsender is woken up to immediately send the WAL
to the standby. This reduces the latency between master and standby, which
is good.
Preliminary work by Fujii Masao. The latch implementation is by me, with
helpful comments from many people.
2010-09-11 17:48:04 +02:00
|
|
|
fd_set input_mask;
|
2011-03-30 09:10:32 +02:00
|
|
|
fd_set output_mask;
|
2011-08-11 18:49:45 +02:00
|
|
|
int hifd;
|
|
|
|
#endif
|
Introduce latches. A latch is a boolean variable, with the capability to
wait until it is set. Latches can be used to reliably wait until a signal
arrives, which is hard otherwise because signals don't interrupt select()
on some platforms, and even when they do, there's race conditions.
On Unix, latches use the so called self-pipe trick under the covers to
implement the sleep until the latch is set, without race conditions. On
Windows, Windows events are used.
Use the new latch abstraction to sleep in walsender, so that as soon as
a transaction finishes, walsender is woken up to immediately send the WAL
to the standby. This reduces the latency between master and standby, which
is good.
Preliminary work by Fujii Masao. The latch implementation is by me, with
helpful comments from many people.
2010-09-11 17:48:04 +02:00
|
|
|
|
Introduce a pipe between postmaster and each backend, which can be used to
detect postmaster death. Postmaster keeps the write-end of the pipe open,
so when it dies, children get EOF in the read-end. That can conveniently
be waited for in select(), which allows eliminating some of the polling
loops that check for postmaster death. This patch doesn't yet change all
the loops to use the new mechanism, expect a follow-on patch to do that.
This changes the interface to WaitLatch, so that it takes as argument a
bitmask of events that it waits for. Possible events are latch set, timeout,
postmaster death, and socket becoming readable or writeable.
The pipe method behaves slightly differently from the kill() method
previously used in PostmasterIsAlive() in the case that postmaster has died,
but its parent has not yet read its exit code with waitpid(). The pipe
returns EOF as soon as the process dies, but kill() continues to return
true until waitpid() has been called (IOW while the process is a zombie).
Because of that, change PostmasterIsAlive() to use the pipe too, otherwise
WaitLatch() would return immediately with WL_POSTMASTER_DEATH, while
PostmasterIsAlive() would claim it's still alive. That could easily lead to
busy-waiting while postmaster is in zombie state.
Peter Geoghegan with further changes by me, reviewed by Fujii Masao and
Florian Pflug.
2011-07-08 17:27:49 +02:00
|
|
|
Assert(wakeEvents != 0); /* must have at least one wake event */
|
|
|
|
|
2016-03-18 19:43:59 +01:00
|
|
|
/* waiting for socket readiness without a socket indicates a bug */
|
|
|
|
if (sock == PGINVALID_SOCKET &&
|
|
|
|
(wakeEvents & (WL_SOCKET_READABLE | WL_SOCKET_WRITEABLE)) != 0)
|
|
|
|
elog(ERROR, "cannot wait on socket event without a socket");
|
|
|
|
|
Introduce a pipe between postmaster and each backend, which can be used to
detect postmaster death. Postmaster keeps the write-end of the pipe open,
so when it dies, children get EOF in the read-end. That can conveniently
be waited for in select(), which allows eliminating some of the polling
loops that check for postmaster death. This patch doesn't yet change all
the loops to use the new mechanism, expect a follow-on patch to do that.
This changes the interface to WaitLatch, so that it takes as argument a
bitmask of events that it waits for. Possible events are latch set, timeout,
postmaster death, and socket becoming readable or writeable.
The pipe method behaves slightly differently from the kill() method
previously used in PostmasterIsAlive() in the case that postmaster has died,
but its parent has not yet read its exit code with waitpid(). The pipe
returns EOF as soon as the process dies, but kill() continues to return
true until waitpid() has been called (IOW while the process is a zombie).
Because of that, change PostmasterIsAlive() to use the pipe too, otherwise
WaitLatch() would return immediately with WL_POSTMASTER_DEATH, while
PostmasterIsAlive() would claim it's still alive. That could easily lead to
busy-waiting while postmaster is in zombie state.
Peter Geoghegan with further changes by me, reviewed by Fujii Masao and
Florian Pflug.
2011-07-08 17:27:49 +02:00
|
|
|
if ((wakeEvents & WL_LATCH_SET) && latch->owner_pid != MyProcPid)
|
Introduce latches. A latch is a boolean variable, with the capability to
wait until it is set. Latches can be used to reliably wait until a signal
arrives, which is hard otherwise because signals don't interrupt select()
on some platforms, and even when they do, there's race conditions.
On Unix, latches use the so called self-pipe trick under the covers to
implement the sleep until the latch is set, without race conditions. On
Windows, Windows events are used.
Use the new latch abstraction to sleep in walsender, so that as soon as
a transaction finishes, walsender is woken up to immediately send the WAL
to the standby. This reduces the latency between master and standby, which
is good.
Preliminary work by Fujii Masao. The latch implementation is by me, with
helpful comments from many people.
2010-09-11 17:48:04 +02:00
|
|
|
elog(ERROR, "cannot wait on a latch owned by another process");
|
|
|
|
|
2012-11-09 02:04:48 +01:00
|
|
|
/*
|
|
|
|
* Initialize timeout if requested. We must record the current time so
|
|
|
|
* that we can determine the remaining timeout if the poll() or select()
|
2014-05-06 18:12:18 +02:00
|
|
|
* is interrupted. (On some platforms, select() will update the contents
|
2012-11-09 02:04:48 +01:00
|
|
|
* of "tv" for us, but unfortunately we can't rely on that.)
|
|
|
|
*/
|
Introduce a pipe between postmaster and each backend, which can be used to
detect postmaster death. Postmaster keeps the write-end of the pipe open,
so when it dies, children get EOF in the read-end. That can conveniently
be waited for in select(), which allows eliminating some of the polling
loops that check for postmaster death. This patch doesn't yet change all
the loops to use the new mechanism, expect a follow-on patch to do that.
This changes the interface to WaitLatch, so that it takes as argument a
bitmask of events that it waits for. Possible events are latch set, timeout,
postmaster death, and socket becoming readable or writeable.
The pipe method behaves slightly differently from the kill() method
previously used in PostmasterIsAlive() in the case that postmaster has died,
but its parent has not yet read its exit code with waitpid(). The pipe
returns EOF as soon as the process dies, but kill() continues to return
true until waitpid() has been called (IOW while the process is a zombie).
Because of that, change PostmasterIsAlive() to use the pipe too, otherwise
WaitLatch() would return immediately with WL_POSTMASTER_DEATH, while
PostmasterIsAlive() would claim it's still alive. That could easily lead to
busy-waiting while postmaster is in zombie state.
Peter Geoghegan with further changes by me, reviewed by Fujii Masao and
Florian Pflug.
2011-07-08 17:27:49 +02:00
|
|
|
if (wakeEvents & WL_TIMEOUT)
|
Introduce latches. A latch is a boolean variable, with the capability to
wait until it is set. Latches can be used to reliably wait until a signal
arrives, which is hard otherwise because signals don't interrupt select()
on some platforms, and even when they do, there's race conditions.
On Unix, latches use the so called self-pipe trick under the covers to
implement the sleep until the latch is set, without race conditions. On
Windows, Windows events are used.
Use the new latch abstraction to sleep in walsender, so that as soon as
a transaction finishes, walsender is woken up to immediately send the WAL
to the standby. This reduces the latency between master and standby, which
is good.
Preliminary work by Fujii Masao. The latch implementation is by me, with
helpful comments from many people.
2010-09-11 17:48:04 +02:00
|
|
|
{
|
2012-11-09 02:04:48 +01:00
|
|
|
INSTR_TIME_SET_CURRENT(start_time);
|
2012-11-18 21:39:51 +01:00
|
|
|
Assert(timeout >= 0 && timeout <= INT_MAX);
|
2012-11-09 02:04:48 +01:00
|
|
|
cur_timeout = timeout;
|
|
|
|
|
2016-03-18 19:43:59 +01:00
|
|
|
#ifdef LATCH_USE_SELECT
|
2012-11-09 02:04:48 +01:00
|
|
|
tv.tv_sec = cur_timeout / 1000L;
|
|
|
|
tv.tv_usec = (cur_timeout % 1000L) * 1000L;
|
Introduce latches. A latch is a boolean variable, with the capability to
wait until it is set. Latches can be used to reliably wait until a signal
arrives, which is hard otherwise because signals don't interrupt select()
on some platforms, and even when they do, there's race conditions.
On Unix, latches use the so called self-pipe trick under the covers to
implement the sleep until the latch is set, without race conditions. On
Windows, Windows events are used.
Use the new latch abstraction to sleep in walsender, so that as soon as
a transaction finishes, walsender is woken up to immediately send the WAL
to the standby. This reduces the latency between master and standby, which
is good.
Preliminary work by Fujii Masao. The latch implementation is by me, with
helpful comments from many people.
2010-09-11 17:48:04 +02:00
|
|
|
tvp = &tv;
|
2011-08-11 18:49:45 +02:00
|
|
|
#endif
|
|
|
|
}
|
|
|
|
else
|
|
|
|
{
|
2012-11-09 02:04:48 +01:00
|
|
|
cur_timeout = -1;
|
|
|
|
|
2016-03-18 19:43:59 +01:00
|
|
|
#ifdef LATCH_USE_SELECT
|
2012-11-09 02:04:48 +01:00
|
|
|
tvp = NULL;
|
2011-08-11 18:49:45 +02:00
|
|
|
#endif
|
Introduce latches. A latch is a boolean variable, with the capability to
wait until it is set. Latches can be used to reliably wait until a signal
arrives, which is hard otherwise because signals don't interrupt select()
on some platforms, and even when they do, there's race conditions.
On Unix, latches use the so called self-pipe trick under the covers to
implement the sleep until the latch is set, without race conditions. On
Windows, Windows events are used.
Use the new latch abstraction to sleep in walsender, so that as soon as
a transaction finishes, walsender is woken up to immediately send the WAL
to the standby. This reduces the latency between master and standby, which
is good.
Preliminary work by Fujii Masao. The latch implementation is by me, with
helpful comments from many people.
2010-09-11 17:48:04 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
waiting = true;
|
Introduce a pipe between postmaster and each backend, which can be used to
detect postmaster death. Postmaster keeps the write-end of the pipe open,
so when it dies, children get EOF in the read-end. That can conveniently
be waited for in select(), which allows eliminating some of the polling
loops that check for postmaster death. This patch doesn't yet change all
the loops to use the new mechanism, expect a follow-on patch to do that.
This changes the interface to WaitLatch, so that it takes as argument a
bitmask of events that it waits for. Possible events are latch set, timeout,
postmaster death, and socket becoming readable or writeable.
The pipe method behaves slightly differently from the kill() method
previously used in PostmasterIsAlive() in the case that postmaster has died,
but its parent has not yet read its exit code with waitpid(). The pipe
returns EOF as soon as the process dies, but kill() continues to return
true until waitpid() has been called (IOW while the process is a zombie).
Because of that, change PostmasterIsAlive() to use the pipe too, otherwise
WaitLatch() would return immediately with WL_POSTMASTER_DEATH, while
PostmasterIsAlive() would claim it's still alive. That could easily lead to
busy-waiting while postmaster is in zombie state.
Peter Geoghegan with further changes by me, reviewed by Fujii Masao and
Florian Pflug.
2011-07-08 17:27:49 +02:00
|
|
|
do
|
Introduce latches. A latch is a boolean variable, with the capability to
wait until it is set. Latches can be used to reliably wait until a signal
arrives, which is hard otherwise because signals don't interrupt select()
on some platforms, and even when they do, there's race conditions.
On Unix, latches use the so called self-pipe trick under the covers to
implement the sleep until the latch is set, without race conditions. On
Windows, Windows events are used.
Use the new latch abstraction to sleep in walsender, so that as soon as
a transaction finishes, walsender is woken up to immediately send the WAL
to the standby. This reduces the latency between master and standby, which
is good.
Preliminary work by Fujii Masao. The latch implementation is by me, with
helpful comments from many people.
2010-09-11 17:48:04 +02:00
|
|
|
{
|
|
|
|
/*
|
2016-03-18 19:43:59 +01:00
|
|
|
* Check if the latch is set already. If so, leave loop immediately,
|
|
|
|
* avoid blocking again. We don't attempt to report any other events
|
|
|
|
* that might also be satisfied.
|
|
|
|
*
|
|
|
|
* If someone sets the latch between this and the poll()/select()
|
|
|
|
* below, the setter will write a byte to the pipe (or signal us and
|
|
|
|
* the signal handler will do that), and the poll()/select() will
|
|
|
|
* return immediately.
|
|
|
|
*
|
|
|
|
* If there's a pending byte in the self pipe, we'll notice whenever
|
|
|
|
* blocking. Only clearing the pipe in that case avoids having to
|
|
|
|
* drain it every time WaitLatchOrSocket() is used. Should the
|
|
|
|
* pipe-buffer fill up we're still ok, because the pipe is in
|
|
|
|
* nonblocking mode. It's unlikely for that to happen, because the
|
|
|
|
* self pipe isn't filled unless we're blocking (waiting = true), or
|
|
|
|
* from inside a signal handler in latch_sigusr1_handler().
|
2011-08-09 21:30:45 +02:00
|
|
|
*
|
|
|
|
* Note: we assume that the kernel calls involved in drainSelfPipe()
|
|
|
|
* and SetLatch() will provide adequate synchronization on machines
|
2012-06-10 21:20:04 +02:00
|
|
|
* with weak memory ordering, so that we cannot miss seeing is_set if
|
|
|
|
* the signal byte is already in the pipe when we drain it.
|
Introduce latches. A latch is a boolean variable, with the capability to
wait until it is set. Latches can be used to reliably wait until a signal
arrives, which is hard otherwise because signals don't interrupt select()
on some platforms, and even when they do, there's race conditions.
On Unix, latches use the so called self-pipe trick under the covers to
implement the sleep until the latch is set, without race conditions. On
Windows, Windows events are used.
Use the new latch abstraction to sleep in walsender, so that as soon as
a transaction finishes, walsender is woken up to immediately send the WAL
to the standby. This reduces the latency between master and standby, which
is good.
Preliminary work by Fujii Masao. The latch implementation is by me, with
helpful comments from many people.
2010-09-11 17:48:04 +02:00
|
|
|
*/
|
Introduce a pipe between postmaster and each backend, which can be used to
detect postmaster death. Postmaster keeps the write-end of the pipe open,
so when it dies, children get EOF in the read-end. That can conveniently
be waited for in select(), which allows eliminating some of the polling
loops that check for postmaster death. This patch doesn't yet change all
the loops to use the new mechanism, expect a follow-on patch to do that.
This changes the interface to WaitLatch, so that it takes as argument a
bitmask of events that it waits for. Possible events are latch set, timeout,
postmaster death, and socket becoming readable or writeable.
The pipe method behaves slightly differently from the kill() method
previously used in PostmasterIsAlive() in the case that postmaster has died,
but its parent has not yet read its exit code with waitpid(). The pipe
returns EOF as soon as the process dies, but kill() continues to return
true until waitpid() has been called (IOW while the process is a zombie).
Because of that, change PostmasterIsAlive() to use the pipe too, otherwise
WaitLatch() would return immediately with WL_POSTMASTER_DEATH, while
PostmasterIsAlive() would claim it's still alive. That could easily lead to
busy-waiting while postmaster is in zombie state.
Peter Geoghegan with further changes by me, reviewed by Fujii Masao and
Florian Pflug.
2011-07-08 17:27:49 +02:00
|
|
|
if ((wakeEvents & WL_LATCH_SET) && latch->is_set)
|
Introduce latches. A latch is a boolean variable, with the capability to
wait until it is set. Latches can be used to reliably wait until a signal
arrives, which is hard otherwise because signals don't interrupt select()
on some platforms, and even when they do, there's race conditions.
On Unix, latches use the so called self-pipe trick under the covers to
implement the sleep until the latch is set, without race conditions. On
Windows, Windows events are used.
Use the new latch abstraction to sleep in walsender, so that as soon as
a transaction finishes, walsender is woken up to immediately send the WAL
to the standby. This reduces the latency between master and standby, which
is good.
Preliminary work by Fujii Masao. The latch implementation is by me, with
helpful comments from many people.
2010-09-11 17:48:04 +02:00
|
|
|
{
|
Introduce a pipe between postmaster and each backend, which can be used to
detect postmaster death. Postmaster keeps the write-end of the pipe open,
so when it dies, children get EOF in the read-end. That can conveniently
be waited for in select(), which allows eliminating some of the polling
loops that check for postmaster death. This patch doesn't yet change all
the loops to use the new mechanism, expect a follow-on patch to do that.
This changes the interface to WaitLatch, so that it takes as argument a
bitmask of events that it waits for. Possible events are latch set, timeout,
postmaster death, and socket becoming readable or writeable.
The pipe method behaves slightly differently from the kill() method
previously used in PostmasterIsAlive() in the case that postmaster has died,
but its parent has not yet read its exit code with waitpid(). The pipe
returns EOF as soon as the process dies, but kill() continues to return
true until waitpid() has been called (IOW while the process is a zombie).
Because of that, change PostmasterIsAlive() to use the pipe too, otherwise
WaitLatch() would return immediately with WL_POSTMASTER_DEATH, while
PostmasterIsAlive() would claim it's still alive. That could easily lead to
busy-waiting while postmaster is in zombie state.
Peter Geoghegan with further changes by me, reviewed by Fujii Masao and
Florian Pflug.
2011-07-08 17:27:49 +02:00
|
|
|
result |= WL_LATCH_SET;
|
Introduce latches. A latch is a boolean variable, with the capability to
wait until it is set. Latches can be used to reliably wait until a signal
arrives, which is hard otherwise because signals don't interrupt select()
on some platforms, and even when they do, there's race conditions.
On Unix, latches use the so called self-pipe trick under the covers to
implement the sleep until the latch is set, without race conditions. On
Windows, Windows events are used.
Use the new latch abstraction to sleep in walsender, so that as soon as
a transaction finishes, walsender is woken up to immediately send the WAL
to the standby. This reduces the latency between master and standby, which
is good.
Preliminary work by Fujii Masao. The latch implementation is by me, with
helpful comments from many people.
2010-09-11 17:48:04 +02:00
|
|
|
break;
|
|
|
|
}
|
|
|
|
|
2015-01-13 12:58:43 +01:00
|
|
|
/*
|
2016-03-18 19:43:59 +01:00
|
|
|
* Must wait ... we use the polling interface determined at the top of
|
|
|
|
* this file to do so.
|
2015-01-13 12:58:43 +01:00
|
|
|
*/
|
2016-03-18 19:43:59 +01:00
|
|
|
#if defined(LATCH_USE_POLL)
|
2011-08-11 18:49:45 +02:00
|
|
|
nfds = 0;
|
2016-03-18 19:43:59 +01:00
|
|
|
|
|
|
|
/* selfpipe is always in pfds[0] */
|
|
|
|
pfds[0].fd = selfpipe_readfd;
|
|
|
|
pfds[0].events = POLLIN;
|
|
|
|
pfds[0].revents = 0;
|
|
|
|
nfds++;
|
|
|
|
|
2011-08-11 18:49:45 +02:00
|
|
|
if (wakeEvents & (WL_SOCKET_READABLE | WL_SOCKET_WRITEABLE))
|
|
|
|
{
|
2016-03-18 19:43:59 +01:00
|
|
|
/* socket, if used, is always in pfds[1] */
|
|
|
|
pfds[1].fd = sock;
|
|
|
|
pfds[1].events = 0;
|
2011-08-11 18:49:45 +02:00
|
|
|
if (wakeEvents & WL_SOCKET_READABLE)
|
2016-03-18 19:43:59 +01:00
|
|
|
pfds[1].events |= POLLIN;
|
2011-08-11 18:49:45 +02:00
|
|
|
if (wakeEvents & WL_SOCKET_WRITEABLE)
|
2016-03-18 19:43:59 +01:00
|
|
|
pfds[1].events |= POLLOUT;
|
|
|
|
pfds[1].revents = 0;
|
2011-08-11 18:49:45 +02:00
|
|
|
nfds++;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (wakeEvents & WL_POSTMASTER_DEATH)
|
|
|
|
{
|
|
|
|
/* postmaster fd, if used, is always in pfds[nfds - 1] */
|
|
|
|
pfds[nfds].fd = postmaster_alive_fds[POSTMASTER_FD_WATCH];
|
|
|
|
pfds[nfds].events = POLLIN;
|
|
|
|
pfds[nfds].revents = 0;
|
|
|
|
nfds++;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Sleep */
|
2012-11-09 02:04:48 +01:00
|
|
|
rc = poll(pfds, nfds, (int) cur_timeout);
|
2011-08-11 18:49:45 +02:00
|
|
|
|
|
|
|
/* Check return code */
|
|
|
|
if (rc < 0)
|
|
|
|
{
|
2012-11-09 02:04:48 +01:00
|
|
|
/* EINTR is okay, otherwise complain */
|
|
|
|
if (errno != EINTR)
|
|
|
|
{
|
|
|
|
waiting = false;
|
|
|
|
ereport(ERROR,
|
|
|
|
(errcode_for_socket_access(),
|
|
|
|
errmsg("poll() failed: %m")));
|
|
|
|
}
|
2011-08-11 18:49:45 +02:00
|
|
|
}
|
2012-11-09 02:04:48 +01:00
|
|
|
else if (rc == 0)
|
2011-08-11 18:49:45 +02:00
|
|
|
{
|
|
|
|
/* timeout exceeded */
|
2012-11-09 02:04:48 +01:00
|
|
|
if (wakeEvents & WL_TIMEOUT)
|
|
|
|
result |= WL_TIMEOUT;
|
2011-08-11 18:49:45 +02:00
|
|
|
}
|
2012-11-09 02:04:48 +01:00
|
|
|
else
|
2011-08-11 18:49:45 +02:00
|
|
|
{
|
2012-11-09 02:04:48 +01:00
|
|
|
/* at least one event occurred, so check revents values */
|
2016-03-18 19:43:59 +01:00
|
|
|
|
|
|
|
if (pfds[0].revents & POLLIN)
|
|
|
|
{
|
|
|
|
/* There's data in the self-pipe, clear it. */
|
|
|
|
drainSelfPipe();
|
|
|
|
}
|
|
|
|
|
2012-11-09 02:04:48 +01:00
|
|
|
if ((wakeEvents & WL_SOCKET_READABLE) &&
|
2016-03-18 19:43:59 +01:00
|
|
|
(pfds[1].revents & POLLIN))
|
2012-11-09 02:04:48 +01:00
|
|
|
{
|
|
|
|
/* data available in socket, or EOF/error condition */
|
|
|
|
result |= WL_SOCKET_READABLE;
|
|
|
|
}
|
|
|
|
if ((wakeEvents & WL_SOCKET_WRITEABLE) &&
|
2016-03-18 19:43:59 +01:00
|
|
|
(pfds[1].revents & POLLOUT))
|
2012-11-09 02:04:48 +01:00
|
|
|
{
|
2015-01-13 12:58:43 +01:00
|
|
|
/* socket is writable */
|
2012-11-09 02:04:48 +01:00
|
|
|
result |= WL_SOCKET_WRITEABLE;
|
|
|
|
}
|
2016-03-19 06:35:43 +01:00
|
|
|
if ((wakeEvents & (WL_SOCKET_READABLE | WL_SOCKET_WRITEABLE)) &&
|
2016-03-18 19:43:59 +01:00
|
|
|
(pfds[1].revents & (POLLHUP | POLLERR | POLLNVAL)))
|
2015-01-13 12:58:43 +01:00
|
|
|
{
|
|
|
|
/* EOF/error condition */
|
|
|
|
if (wakeEvents & WL_SOCKET_READABLE)
|
|
|
|
result |= WL_SOCKET_READABLE;
|
|
|
|
if (wakeEvents & WL_SOCKET_WRITEABLE)
|
|
|
|
result |= WL_SOCKET_WRITEABLE;
|
|
|
|
}
|
2012-06-10 21:20:04 +02:00
|
|
|
|
2012-05-10 20:34:22 +02:00
|
|
|
/*
|
2012-11-09 02:04:48 +01:00
|
|
|
* We expect a POLLHUP when the remote end is closed, but because
|
|
|
|
* we don't expect the pipe to become readable or to have any
|
|
|
|
* errors either, treat those cases as postmaster death, too.
|
2012-05-10 20:34:22 +02:00
|
|
|
*/
|
2012-11-09 02:04:48 +01:00
|
|
|
if ((wakeEvents & WL_POSTMASTER_DEATH) &&
|
|
|
|
(pfds[nfds - 1].revents & (POLLHUP | POLLIN | POLLERR | POLLNVAL)))
|
|
|
|
{
|
|
|
|
/*
|
|
|
|
* According to the select(2) man page on Linux, select(2) may
|
|
|
|
* spuriously return and report a file descriptor as readable,
|
|
|
|
* when it's not; and presumably so can poll(2). It's not
|
|
|
|
* clear that the relevant cases would ever apply to the
|
|
|
|
* postmaster pipe, but since the consequences of falsely
|
|
|
|
* returning WL_POSTMASTER_DEATH could be pretty unpleasant,
|
|
|
|
* we take the trouble to positively verify EOF with
|
|
|
|
* PostmasterIsAlive().
|
|
|
|
*/
|
|
|
|
if (!PostmasterIsAlive())
|
|
|
|
result |= WL_POSTMASTER_DEATH;
|
|
|
|
}
|
2011-08-11 18:49:45 +02:00
|
|
|
}
|
2016-03-18 19:43:59 +01:00
|
|
|
#elif defined(LATCH_USE_SELECT)
|
2011-08-11 18:49:45 +02:00
|
|
|
|
2016-03-18 19:43:59 +01:00
|
|
|
/*
|
|
|
|
* On at least older linux kernels select(), in violation of POSIX,
|
|
|
|
* doesn't reliably return a socket as writable if closed - but we
|
|
|
|
* rely on that. So far all the known cases of this problem are on
|
|
|
|
* platforms that also provide a poll() implementation without that
|
|
|
|
* bug. If we find one where that's not the case, we'll need to add a
|
|
|
|
* workaround.
|
|
|
|
*/
|
Introduce latches. A latch is a boolean variable, with the capability to
wait until it is set. Latches can be used to reliably wait until a signal
arrives, which is hard otherwise because signals don't interrupt select()
on some platforms, and even when they do, there's race conditions.
On Unix, latches use the so called self-pipe trick under the covers to
implement the sleep until the latch is set, without race conditions. On
Windows, Windows events are used.
Use the new latch abstraction to sleep in walsender, so that as soon as
a transaction finishes, walsender is woken up to immediately send the WAL
to the standby. This reduces the latency between master and standby, which
is good.
Preliminary work by Fujii Masao. The latch implementation is by me, with
helpful comments from many people.
2010-09-11 17:48:04 +02:00
|
|
|
FD_ZERO(&input_mask);
|
2011-08-09 21:30:45 +02:00
|
|
|
FD_ZERO(&output_mask);
|
|
|
|
|
Introduce latches. A latch is a boolean variable, with the capability to
wait until it is set. Latches can be used to reliably wait until a signal
arrives, which is hard otherwise because signals don't interrupt select()
on some platforms, and even when they do, there's race conditions.
On Unix, latches use the so called self-pipe trick under the covers to
implement the sleep until the latch is set, without race conditions. On
Windows, Windows events are used.
Use the new latch abstraction to sleep in walsender, so that as soon as
a transaction finishes, walsender is woken up to immediately send the WAL
to the standby. This reduces the latency between master and standby, which
is good.
Preliminary work by Fujii Masao. The latch implementation is by me, with
helpful comments from many people.
2010-09-11 17:48:04 +02:00
|
|
|
FD_SET(selfpipe_readfd, &input_mask);
|
|
|
|
hifd = selfpipe_readfd;
|
Introduce a pipe between postmaster and each backend, which can be used to
detect postmaster death. Postmaster keeps the write-end of the pipe open,
so when it dies, children get EOF in the read-end. That can conveniently
be waited for in select(), which allows eliminating some of the polling
loops that check for postmaster death. This patch doesn't yet change all
the loops to use the new mechanism, expect a follow-on patch to do that.
This changes the interface to WaitLatch, so that it takes as argument a
bitmask of events that it waits for. Possible events are latch set, timeout,
postmaster death, and socket becoming readable or writeable.
The pipe method behaves slightly differently from the kill() method
previously used in PostmasterIsAlive() in the case that postmaster has died,
but its parent has not yet read its exit code with waitpid(). The pipe
returns EOF as soon as the process dies, but kill() continues to return
true until waitpid() has been called (IOW while the process is a zombie).
Because of that, change PostmasterIsAlive() to use the pipe too, otherwise
WaitLatch() would return immediately with WL_POSTMASTER_DEATH, while
PostmasterIsAlive() would claim it's still alive. That could easily lead to
busy-waiting while postmaster is in zombie state.
Peter Geoghegan with further changes by me, reviewed by Fujii Masao and
Florian Pflug.
2011-07-08 17:27:49 +02:00
|
|
|
|
|
|
|
if (wakeEvents & WL_POSTMASTER_DEATH)
|
|
|
|
{
|
|
|
|
FD_SET(postmaster_alive_fds[POSTMASTER_FD_WATCH], &input_mask);
|
|
|
|
if (postmaster_alive_fds[POSTMASTER_FD_WATCH] > hifd)
|
|
|
|
hifd = postmaster_alive_fds[POSTMASTER_FD_WATCH];
|
|
|
|
}
|
|
|
|
|
|
|
|
if (wakeEvents & WL_SOCKET_READABLE)
|
Introduce latches. A latch is a boolean variable, with the capability to
wait until it is set. Latches can be used to reliably wait until a signal
arrives, which is hard otherwise because signals don't interrupt select()
on some platforms, and even when they do, there's race conditions.
On Unix, latches use the so called self-pipe trick under the covers to
implement the sleep until the latch is set, without race conditions. On
Windows, Windows events are used.
Use the new latch abstraction to sleep in walsender, so that as soon as
a transaction finishes, walsender is woken up to immediately send the WAL
to the standby. This reduces the latency between master and standby, which
is good.
Preliminary work by Fujii Masao. The latch implementation is by me, with
helpful comments from many people.
2010-09-11 17:48:04 +02:00
|
|
|
{
|
|
|
|
FD_SET(sock, &input_mask);
|
|
|
|
if (sock > hifd)
|
|
|
|
hifd = sock;
|
|
|
|
}
|
|
|
|
|
Introduce a pipe between postmaster and each backend, which can be used to
detect postmaster death. Postmaster keeps the write-end of the pipe open,
so when it dies, children get EOF in the read-end. That can conveniently
be waited for in select(), which allows eliminating some of the polling
loops that check for postmaster death. This patch doesn't yet change all
the loops to use the new mechanism, expect a follow-on patch to do that.
This changes the interface to WaitLatch, so that it takes as argument a
bitmask of events that it waits for. Possible events are latch set, timeout,
postmaster death, and socket becoming readable or writeable.
The pipe method behaves slightly differently from the kill() method
previously used in PostmasterIsAlive() in the case that postmaster has died,
but its parent has not yet read its exit code with waitpid(). The pipe
returns EOF as soon as the process dies, but kill() continues to return
true until waitpid() has been called (IOW while the process is a zombie).
Because of that, change PostmasterIsAlive() to use the pipe too, otherwise
WaitLatch() would return immediately with WL_POSTMASTER_DEATH, while
PostmasterIsAlive() would claim it's still alive. That could easily lead to
busy-waiting while postmaster is in zombie state.
Peter Geoghegan with further changes by me, reviewed by Fujii Masao and
Florian Pflug.
2011-07-08 17:27:49 +02:00
|
|
|
if (wakeEvents & WL_SOCKET_WRITEABLE)
|
2011-03-30 09:10:32 +02:00
|
|
|
{
|
|
|
|
FD_SET(sock, &output_mask);
|
|
|
|
if (sock > hifd)
|
|
|
|
hifd = sock;
|
|
|
|
}
|
|
|
|
|
Introduce a pipe between postmaster and each backend, which can be used to
detect postmaster death. Postmaster keeps the write-end of the pipe open,
so when it dies, children get EOF in the read-end. That can conveniently
be waited for in select(), which allows eliminating some of the polling
loops that check for postmaster death. This patch doesn't yet change all
the loops to use the new mechanism, expect a follow-on patch to do that.
This changes the interface to WaitLatch, so that it takes as argument a
bitmask of events that it waits for. Possible events are latch set, timeout,
postmaster death, and socket becoming readable or writeable.
The pipe method behaves slightly differently from the kill() method
previously used in PostmasterIsAlive() in the case that postmaster has died,
but its parent has not yet read its exit code with waitpid(). The pipe
returns EOF as soon as the process dies, but kill() continues to return
true until waitpid() has been called (IOW while the process is a zombie).
Because of that, change PostmasterIsAlive() to use the pipe too, otherwise
WaitLatch() would return immediately with WL_POSTMASTER_DEATH, while
PostmasterIsAlive() would claim it's still alive. That could easily lead to
busy-waiting while postmaster is in zombie state.
Peter Geoghegan with further changes by me, reviewed by Fujii Masao and
Florian Pflug.
2011-07-08 17:27:49 +02:00
|
|
|
/* Sleep */
|
2011-03-30 09:10:32 +02:00
|
|
|
rc = select(hifd + 1, &input_mask, &output_mask, NULL, tvp);
|
Introduce a pipe between postmaster and each backend, which can be used to
detect postmaster death. Postmaster keeps the write-end of the pipe open,
so when it dies, children get EOF in the read-end. That can conveniently
be waited for in select(), which allows eliminating some of the polling
loops that check for postmaster death. This patch doesn't yet change all
the loops to use the new mechanism, expect a follow-on patch to do that.
This changes the interface to WaitLatch, so that it takes as argument a
bitmask of events that it waits for. Possible events are latch set, timeout,
postmaster death, and socket becoming readable or writeable.
The pipe method behaves slightly differently from the kill() method
previously used in PostmasterIsAlive() in the case that postmaster has died,
but its parent has not yet read its exit code with waitpid(). The pipe
returns EOF as soon as the process dies, but kill() continues to return
true until waitpid() has been called (IOW while the process is a zombie).
Because of that, change PostmasterIsAlive() to use the pipe too, otherwise
WaitLatch() would return immediately with WL_POSTMASTER_DEATH, while
PostmasterIsAlive() would claim it's still alive. That could easily lead to
busy-waiting while postmaster is in zombie state.
Peter Geoghegan with further changes by me, reviewed by Fujii Masao and
Florian Pflug.
2011-07-08 17:27:49 +02:00
|
|
|
|
|
|
|
/* Check return code */
|
Introduce latches. A latch is a boolean variable, with the capability to
wait until it is set. Latches can be used to reliably wait until a signal
arrives, which is hard otherwise because signals don't interrupt select()
on some platforms, and even when they do, there's race conditions.
On Unix, latches use the so called self-pipe trick under the covers to
implement the sleep until the latch is set, without race conditions. On
Windows, Windows events are used.
Use the new latch abstraction to sleep in walsender, so that as soon as
a transaction finishes, walsender is woken up to immediately send the WAL
to the standby. This reduces the latency between master and standby, which
is good.
Preliminary work by Fujii Masao. The latch implementation is by me, with
helpful comments from many people.
2010-09-11 17:48:04 +02:00
|
|
|
if (rc < 0)
|
|
|
|
{
|
2012-11-09 02:04:48 +01:00
|
|
|
/* EINTR is okay, otherwise complain */
|
|
|
|
if (errno != EINTR)
|
|
|
|
{
|
|
|
|
waiting = false;
|
|
|
|
ereport(ERROR,
|
|
|
|
(errcode_for_socket_access(),
|
|
|
|
errmsg("select() failed: %m")));
|
|
|
|
}
|
Introduce latches. A latch is a boolean variable, with the capability to
wait until it is set. Latches can be used to reliably wait until a signal
arrives, which is hard otherwise because signals don't interrupt select()
on some platforms, and even when they do, there's race conditions.
On Unix, latches use the so called self-pipe trick under the covers to
implement the sleep until the latch is set, without race conditions. On
Windows, Windows events are used.
Use the new latch abstraction to sleep in walsender, so that as soon as
a transaction finishes, walsender is woken up to immediately send the WAL
to the standby. This reduces the latency between master and standby, which
is good.
Preliminary work by Fujii Masao. The latch implementation is by me, with
helpful comments from many people.
2010-09-11 17:48:04 +02:00
|
|
|
}
|
2012-11-09 02:04:48 +01:00
|
|
|
else if (rc == 0)
|
Introduce latches. A latch is a boolean variable, with the capability to
wait until it is set. Latches can be used to reliably wait until a signal
arrives, which is hard otherwise because signals don't interrupt select()
on some platforms, and even when they do, there's race conditions.
On Unix, latches use the so called self-pipe trick under the covers to
implement the sleep until the latch is set, without race conditions. On
Windows, Windows events are used.
Use the new latch abstraction to sleep in walsender, so that as soon as
a transaction finishes, walsender is woken up to immediately send the WAL
to the standby. This reduces the latency between master and standby, which
is good.
Preliminary work by Fujii Masao. The latch implementation is by me, with
helpful comments from many people.
2010-09-11 17:48:04 +02:00
|
|
|
{
|
|
|
|
/* timeout exceeded */
|
2012-11-09 02:04:48 +01:00
|
|
|
if (wakeEvents & WL_TIMEOUT)
|
|
|
|
result |= WL_TIMEOUT;
|
Introduce latches. A latch is a boolean variable, with the capability to
wait until it is set. Latches can be used to reliably wait until a signal
arrives, which is hard otherwise because signals don't interrupt select()
on some platforms, and even when they do, there's race conditions.
On Unix, latches use the so called self-pipe trick under the covers to
implement the sleep until the latch is set, without race conditions. On
Windows, Windows events are used.
Use the new latch abstraction to sleep in walsender, so that as soon as
a transaction finishes, walsender is woken up to immediately send the WAL
to the standby. This reduces the latency between master and standby, which
is good.
Preliminary work by Fujii Masao. The latch implementation is by me, with
helpful comments from many people.
2010-09-11 17:48:04 +02:00
|
|
|
}
|
2012-11-09 02:04:48 +01:00
|
|
|
else
|
Introduce latches. A latch is a boolean variable, with the capability to
wait until it is set. Latches can be used to reliably wait until a signal
arrives, which is hard otherwise because signals don't interrupt select()
on some platforms, and even when they do, there's race conditions.
On Unix, latches use the so called self-pipe trick under the covers to
implement the sleep until the latch is set, without race conditions. On
Windows, Windows events are used.
Use the new latch abstraction to sleep in walsender, so that as soon as
a transaction finishes, walsender is woken up to immediately send the WAL
to the standby. This reduces the latency between master and standby, which
is good.
Preliminary work by Fujii Masao. The latch implementation is by me, with
helpful comments from many people.
2010-09-11 17:48:04 +02:00
|
|
|
{
|
2012-11-09 02:04:48 +01:00
|
|
|
/* at least one event occurred, so check masks */
|
2016-03-18 19:43:59 +01:00
|
|
|
if (FD_ISSET(selfpipe_readfd, &input_mask))
|
|
|
|
{
|
|
|
|
/* There's data in the self-pipe, clear it. */
|
|
|
|
drainSelfPipe();
|
|
|
|
}
|
2012-11-09 02:04:48 +01:00
|
|
|
if ((wakeEvents & WL_SOCKET_READABLE) && FD_ISSET(sock, &input_mask))
|
|
|
|
{
|
|
|
|
/* data available in socket, or EOF */
|
|
|
|
result |= WL_SOCKET_READABLE;
|
|
|
|
}
|
|
|
|
if ((wakeEvents & WL_SOCKET_WRITEABLE) && FD_ISSET(sock, &output_mask))
|
|
|
|
{
|
2015-01-13 12:58:43 +01:00
|
|
|
/* socket is writable, or EOF */
|
2012-11-09 02:04:48 +01:00
|
|
|
result |= WL_SOCKET_WRITEABLE;
|
|
|
|
}
|
|
|
|
if ((wakeEvents & WL_POSTMASTER_DEATH) &&
|
Make WaitLatchOrSocket's timeout detection more robust.
In the previous coding, timeout would be noticed and reported only when
poll() or socket() returned zero (or the equivalent behavior on Windows).
Ordinarily that should work well enough, but it seems conceivable that we
could get into a state where poll() always returns a nonzero value --- for
example, if it is noticing a condition on one of the file descriptors that
we do not think is reason to exit the loop. If that happened, we'd be in a
busy-wait loop that would fail to terminate even when the timeout expires.
We can make this more robust at essentially no cost, by deciding to exit
of our own accord if we compute a zero or negative time-remaining-to-wait.
Previously the code noted this but just clamped the time-remaining to zero,
expecting that we'd detect timeout on the next loop iteration.
Back-patch to 9.2. While 9.1 had a version of WaitLatchOrSocket, it was
primitive compared to later versions, and did not guarantee reliable
detection of timeouts anyway. (Essentially, this is a refinement of
commit 3e7fdcffd6f77187, which was back-patched only as far as 9.2.)
2015-07-18 17:47:13 +02:00
|
|
|
FD_ISSET(postmaster_alive_fds[POSTMASTER_FD_WATCH],
|
|
|
|
&input_mask))
|
2012-11-09 02:04:48 +01:00
|
|
|
{
|
|
|
|
/*
|
|
|
|
* According to the select(2) man page on Linux, select(2) may
|
|
|
|
* spuriously return and report a file descriptor as readable,
|
|
|
|
* when it's not; and presumably so can poll(2). It's not
|
|
|
|
* clear that the relevant cases would ever apply to the
|
|
|
|
* postmaster pipe, but since the consequences of falsely
|
|
|
|
* returning WL_POSTMASTER_DEATH could be pretty unpleasant,
|
|
|
|
* we take the trouble to positively verify EOF with
|
|
|
|
* PostmasterIsAlive().
|
|
|
|
*/
|
|
|
|
if (!PostmasterIsAlive())
|
|
|
|
result |= WL_POSTMASTER_DEATH;
|
|
|
|
}
|
Introduce a pipe between postmaster and each backend, which can be used to
detect postmaster death. Postmaster keeps the write-end of the pipe open,
so when it dies, children get EOF in the read-end. That can conveniently
be waited for in select(), which allows eliminating some of the polling
loops that check for postmaster death. This patch doesn't yet change all
the loops to use the new mechanism, expect a follow-on patch to do that.
This changes the interface to WaitLatch, so that it takes as argument a
bitmask of events that it waits for. Possible events are latch set, timeout,
postmaster death, and socket becoming readable or writeable.
The pipe method behaves slightly differently from the kill() method
previously used in PostmasterIsAlive() in the case that postmaster has died,
but its parent has not yet read its exit code with waitpid(). The pipe
returns EOF as soon as the process dies, but kill() continues to return
true until waitpid() has been called (IOW while the process is a zombie).
Because of that, change PostmasterIsAlive() to use the pipe too, otherwise
WaitLatch() would return immediately with WL_POSTMASTER_DEATH, while
PostmasterIsAlive() would claim it's still alive. That could easily lead to
busy-waiting while postmaster is in zombie state.
Peter Geoghegan with further changes by me, reviewed by Fujii Masao and
Florian Pflug.
2011-07-08 17:27:49 +02:00
|
|
|
}
|
2016-03-18 19:43:59 +01:00
|
|
|
#endif /* LATCH_USE_SELECT */
|
2012-11-09 02:04:48 +01:00
|
|
|
|
2016-03-18 19:43:59 +01:00
|
|
|
/*
|
|
|
|
* Check again whether latch is set, the arrival of a signal/self-byte
|
|
|
|
* might be what stopped our sleep. It's not required for correctness
|
|
|
|
* to signal the latch as being set (we'd just loop if there's no
|
|
|
|
* other event), but it seems good to report an arrived latch asap.
|
|
|
|
* This way we also don't have to compute the current timestamp again.
|
|
|
|
*/
|
|
|
|
if ((wakeEvents & WL_LATCH_SET) && latch->is_set)
|
|
|
|
result |= WL_LATCH_SET;
|
|
|
|
|
2012-11-09 02:04:48 +01:00
|
|
|
/* If we're not done, update cur_timeout for next iteration */
|
Make WaitLatchOrSocket's timeout detection more robust.
In the previous coding, timeout would be noticed and reported only when
poll() or socket() returned zero (or the equivalent behavior on Windows).
Ordinarily that should work well enough, but it seems conceivable that we
could get into a state where poll() always returns a nonzero value --- for
example, if it is noticing a condition on one of the file descriptors that
we do not think is reason to exit the loop. If that happened, we'd be in a
busy-wait loop that would fail to terminate even when the timeout expires.
We can make this more robust at essentially no cost, by deciding to exit
of our own accord if we compute a zero or negative time-remaining-to-wait.
Previously the code noted this but just clamped the time-remaining to zero,
expecting that we'd detect timeout on the next loop iteration.
Back-patch to 9.2. While 9.1 had a version of WaitLatchOrSocket, it was
primitive compared to later versions, and did not guarantee reliable
detection of timeouts anyway. (Essentially, this is a refinement of
commit 3e7fdcffd6f77187, which was back-patched only as far as 9.2.)
2015-07-18 17:47:13 +02:00
|
|
|
if (result == 0 && (wakeEvents & WL_TIMEOUT))
|
2012-11-09 02:04:48 +01:00
|
|
|
{
|
|
|
|
INSTR_TIME_SET_CURRENT(cur_time);
|
|
|
|
INSTR_TIME_SUBTRACT(cur_time, start_time);
|
|
|
|
cur_timeout = timeout - (long) INSTR_TIME_GET_MILLISEC(cur_time);
|
Make WaitLatchOrSocket's timeout detection more robust.
In the previous coding, timeout would be noticed and reported only when
poll() or socket() returned zero (or the equivalent behavior on Windows).
Ordinarily that should work well enough, but it seems conceivable that we
could get into a state where poll() always returns a nonzero value --- for
example, if it is noticing a condition on one of the file descriptors that
we do not think is reason to exit the loop. If that happened, we'd be in a
busy-wait loop that would fail to terminate even when the timeout expires.
We can make this more robust at essentially no cost, by deciding to exit
of our own accord if we compute a zero or negative time-remaining-to-wait.
Previously the code noted this but just clamped the time-remaining to zero,
expecting that we'd detect timeout on the next loop iteration.
Back-patch to 9.2. While 9.1 had a version of WaitLatchOrSocket, it was
primitive compared to later versions, and did not guarantee reliable
detection of timeouts anyway. (Essentially, this is a refinement of
commit 3e7fdcffd6f77187, which was back-patched only as far as 9.2.)
2015-07-18 17:47:13 +02:00
|
|
|
if (cur_timeout <= 0)
|
|
|
|
{
|
|
|
|
/* Timeout has expired, no need to continue looping */
|
|
|
|
result |= WL_TIMEOUT;
|
|
|
|
}
|
2016-03-18 19:43:59 +01:00
|
|
|
#ifdef LATCH_USE_SELECT
|
Make WaitLatchOrSocket's timeout detection more robust.
In the previous coding, timeout would be noticed and reported only when
poll() or socket() returned zero (or the equivalent behavior on Windows).
Ordinarily that should work well enough, but it seems conceivable that we
could get into a state where poll() always returns a nonzero value --- for
example, if it is noticing a condition on one of the file descriptors that
we do not think is reason to exit the loop. If that happened, we'd be in a
busy-wait loop that would fail to terminate even when the timeout expires.
We can make this more robust at essentially no cost, by deciding to exit
of our own accord if we compute a zero or negative time-remaining-to-wait.
Previously the code noted this but just clamped the time-remaining to zero,
expecting that we'd detect timeout on the next loop iteration.
Back-patch to 9.2. While 9.1 had a version of WaitLatchOrSocket, it was
primitive compared to later versions, and did not guarantee reliable
detection of timeouts anyway. (Essentially, this is a refinement of
commit 3e7fdcffd6f77187, which was back-patched only as far as 9.2.)
2015-07-18 17:47:13 +02:00
|
|
|
else
|
|
|
|
{
|
|
|
|
tv.tv_sec = cur_timeout / 1000L;
|
|
|
|
tv.tv_usec = (cur_timeout % 1000L) * 1000L;
|
|
|
|
}
|
2012-11-09 02:04:48 +01:00
|
|
|
#endif
|
|
|
|
}
|
2011-08-09 21:30:45 +02:00
|
|
|
} while (result == 0);
|
Introduce latches. A latch is a boolean variable, with the capability to
wait until it is set. Latches can be used to reliably wait until a signal
arrives, which is hard otherwise because signals don't interrupt select()
on some platforms, and even when they do, there's race conditions.
On Unix, latches use the so called self-pipe trick under the covers to
implement the sleep until the latch is set, without race conditions. On
Windows, Windows events are used.
Use the new latch abstraction to sleep in walsender, so that as soon as
a transaction finishes, walsender is woken up to immediately send the WAL
to the standby. This reduces the latency between master and standby, which
is good.
Preliminary work by Fujii Masao. The latch implementation is by me, with
helpful comments from many people.
2010-09-11 17:48:04 +02:00
|
|
|
waiting = false;
|
|
|
|
|
|
|
|
return result;
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
2011-08-09 21:30:45 +02:00
|
|
|
* Sets a latch and wakes up anyone waiting on it.
|
|
|
|
*
|
|
|
|
* This is cheap if the latch is already set, otherwise not so much.
|
2011-08-10 18:20:30 +02:00
|
|
|
*
|
|
|
|
* NB: when calling this in a signal handler, be sure to save and restore
|
|
|
|
* errno around it. (That's standard practice in most signal handlers, of
|
|
|
|
* course, but we used to omit it in handlers that only set a flag.)
|
2012-07-02 15:36:34 +02:00
|
|
|
*
|
|
|
|
* NB: this function is called from critical sections and signal handlers so
|
|
|
|
* throwing an error is not a good idea.
|
Introduce latches. A latch is a boolean variable, with the capability to
wait until it is set. Latches can be used to reliably wait until a signal
arrives, which is hard otherwise because signals don't interrupt select()
on some platforms, and even when they do, there's race conditions.
On Unix, latches use the so called self-pipe trick under the covers to
implement the sleep until the latch is set, without race conditions. On
Windows, Windows events are used.
Use the new latch abstraction to sleep in walsender, so that as soon as
a transaction finishes, walsender is woken up to immediately send the WAL
to the standby. This reduces the latency between master and standby, which
is good.
Preliminary work by Fujii Masao. The latch implementation is by me, with
helpful comments from many people.
2010-09-11 17:48:04 +02:00
|
|
|
*/
|
|
|
|
void
|
|
|
|
SetLatch(volatile Latch *latch)
|
|
|
|
{
|
2011-04-10 17:42:00 +02:00
|
|
|
pid_t owner_pid;
|
Introduce latches. A latch is a boolean variable, with the capability to
wait until it is set. Latches can be used to reliably wait until a signal
arrives, which is hard otherwise because signals don't interrupt select()
on some platforms, and even when they do, there's race conditions.
On Unix, latches use the so called self-pipe trick under the covers to
implement the sleep until the latch is set, without race conditions. On
Windows, Windows events are used.
Use the new latch abstraction to sleep in walsender, so that as soon as
a transaction finishes, walsender is woken up to immediately send the WAL
to the standby. This reduces the latency between master and standby, which
is good.
Preliminary work by Fujii Masao. The latch implementation is by me, with
helpful comments from many people.
2010-09-11 17:48:04 +02:00
|
|
|
|
2011-08-09 21:30:45 +02:00
|
|
|
/*
|
2015-01-13 12:58:43 +01:00
|
|
|
* The memory barrier has be to be placed here to ensure that any flag
|
|
|
|
* variables possibly changed by this process have been flushed to main
|
|
|
|
* memory, before we check/set is_set.
|
2011-08-09 21:30:45 +02:00
|
|
|
*/
|
2015-01-13 12:58:43 +01:00
|
|
|
pg_memory_barrier();
|
2011-08-09 21:30:45 +02:00
|
|
|
|
Introduce latches. A latch is a boolean variable, with the capability to
wait until it is set. Latches can be used to reliably wait until a signal
arrives, which is hard otherwise because signals don't interrupt select()
on some platforms, and even when they do, there's race conditions.
On Unix, latches use the so called self-pipe trick under the covers to
implement the sleep until the latch is set, without race conditions. On
Windows, Windows events are used.
Use the new latch abstraction to sleep in walsender, so that as soon as
a transaction finishes, walsender is woken up to immediately send the WAL
to the standby. This reduces the latency between master and standby, which
is good.
Preliminary work by Fujii Masao. The latch implementation is by me, with
helpful comments from many people.
2010-09-11 17:48:04 +02:00
|
|
|
/* Quick exit if already set */
|
|
|
|
if (latch->is_set)
|
|
|
|
return;
|
|
|
|
|
|
|
|
latch->is_set = true;
|
|
|
|
|
|
|
|
/*
|
2011-04-10 17:42:00 +02:00
|
|
|
* See if anyone's waiting for the latch. It can be the current process if
|
|
|
|
* we're in a signal handler. We use the self-pipe to wake up the select()
|
|
|
|
* in that case. If it's another process, send a signal.
|
Introduce latches. A latch is a boolean variable, with the capability to
wait until it is set. Latches can be used to reliably wait until a signal
arrives, which is hard otherwise because signals don't interrupt select()
on some platforms, and even when they do, there's race conditions.
On Unix, latches use the so called self-pipe trick under the covers to
implement the sleep until the latch is set, without race conditions. On
Windows, Windows events are used.
Use the new latch abstraction to sleep in walsender, so that as soon as
a transaction finishes, walsender is woken up to immediately send the WAL
to the standby. This reduces the latency between master and standby, which
is good.
Preliminary work by Fujii Masao. The latch implementation is by me, with
helpful comments from many people.
2010-09-11 17:48:04 +02:00
|
|
|
*
|
2011-08-09 21:30:45 +02:00
|
|
|
* Fetch owner_pid only once, in case the latch is concurrently getting
|
|
|
|
* owned or disowned. XXX: This assumes that pid_t is atomic, which isn't
|
|
|
|
* guaranteed to be true! In practice, the effective range of pid_t fits
|
|
|
|
* in a 32 bit integer, and so should be atomic. In the worst case, we
|
|
|
|
* might end up signaling the wrong process. Even then, you're very
|
|
|
|
* unlucky if a process with that bogus pid exists and belongs to
|
|
|
|
* Postgres; and PG database processes should handle excess SIGUSR1
|
|
|
|
* interrupts without a problem anyhow.
|
|
|
|
*
|
2012-06-10 21:20:04 +02:00
|
|
|
* Another sort of race condition that's possible here is for a new
|
|
|
|
* process to own the latch immediately after we look, so we don't signal
|
|
|
|
* it. This is okay so long as all callers of ResetLatch/WaitLatch follow
|
|
|
|
* the standard coding convention of waiting at the bottom of their loops,
|
|
|
|
* not the top, so that they'll correctly process latch-setting events
|
|
|
|
* that happen before they enter the loop.
|
Introduce latches. A latch is a boolean variable, with the capability to
wait until it is set. Latches can be used to reliably wait until a signal
arrives, which is hard otherwise because signals don't interrupt select()
on some platforms, and even when they do, there's race conditions.
On Unix, latches use the so called self-pipe trick under the covers to
implement the sleep until the latch is set, without race conditions. On
Windows, Windows events are used.
Use the new latch abstraction to sleep in walsender, so that as soon as
a transaction finishes, walsender is woken up to immediately send the WAL
to the standby. This reduces the latency between master and standby, which
is good.
Preliminary work by Fujii Masao. The latch implementation is by me, with
helpful comments from many people.
2010-09-11 17:48:04 +02:00
|
|
|
*/
|
|
|
|
owner_pid = latch->owner_pid;
|
|
|
|
if (owner_pid == 0)
|
|
|
|
return;
|
|
|
|
else if (owner_pid == MyProcPid)
|
2011-08-10 18:20:30 +02:00
|
|
|
{
|
|
|
|
if (waiting)
|
|
|
|
sendSelfPipeByte();
|
|
|
|
}
|
Introduce latches. A latch is a boolean variable, with the capability to
wait until it is set. Latches can be used to reliably wait until a signal
arrives, which is hard otherwise because signals don't interrupt select()
on some platforms, and even when they do, there's race conditions.
On Unix, latches use the so called self-pipe trick under the covers to
implement the sleep until the latch is set, without race conditions. On
Windows, Windows events are used.
Use the new latch abstraction to sleep in walsender, so that as soon as
a transaction finishes, walsender is woken up to immediately send the WAL
to the standby. This reduces the latency between master and standby, which
is good.
Preliminary work by Fujii Masao. The latch implementation is by me, with
helpful comments from many people.
2010-09-11 17:48:04 +02:00
|
|
|
else
|
|
|
|
kill(owner_pid, SIGUSR1);
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Clear the latch. Calling WaitLatch after this will sleep, unless
|
|
|
|
* the latch is set again before the WaitLatch call.
|
|
|
|
*/
|
|
|
|
void
|
|
|
|
ResetLatch(volatile Latch *latch)
|
|
|
|
{
|
|
|
|
/* Only the owner should reset the latch */
|
|
|
|
Assert(latch->owner_pid == MyProcPid);
|
|
|
|
|
|
|
|
latch->is_set = false;
|
2011-08-09 21:30:45 +02:00
|
|
|
|
|
|
|
/*
|
2015-01-13 12:58:43 +01:00
|
|
|
* Ensure that the write to is_set gets flushed to main memory before we
|
2014-05-06 18:12:18 +02:00
|
|
|
* examine any flag variables. Otherwise a concurrent SetLatch might
|
2011-08-09 21:30:45 +02:00
|
|
|
* falsely conclude that it needn't signal us, even though we have missed
|
|
|
|
* seeing some flag updates that SetLatch was supposed to inform us of.
|
|
|
|
*/
|
2015-01-13 12:58:43 +01:00
|
|
|
pg_memory_barrier();
|
Introduce latches. A latch is a boolean variable, with the capability to
wait until it is set. Latches can be used to reliably wait until a signal
arrives, which is hard otherwise because signals don't interrupt select()
on some platforms, and even when they do, there's race conditions.
On Unix, latches use the so called self-pipe trick under the covers to
implement the sleep until the latch is set, without race conditions. On
Windows, Windows events are used.
Use the new latch abstraction to sleep in walsender, so that as soon as
a transaction finishes, walsender is woken up to immediately send the WAL
to the standby. This reduces the latency between master and standby, which
is good.
Preliminary work by Fujii Masao. The latch implementation is by me, with
helpful comments from many people.
2010-09-11 17:48:04 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
2011-08-09 21:30:45 +02:00
|
|
|
* SetLatch uses SIGUSR1 to wake up the process waiting on the latch.
|
|
|
|
*
|
|
|
|
* Wake up WaitLatch, if we're waiting. (We might not be, since SIGUSR1 is
|
2011-08-10 18:20:30 +02:00
|
|
|
* overloaded for multiple purposes; or we might not have reached WaitLatch
|
|
|
|
* yet, in which case we don't need to fill the pipe either.)
|
|
|
|
*
|
|
|
|
* NB: when calling this in a signal handler, be sure to save and restore
|
|
|
|
* errno around it.
|
Introduce latches. A latch is a boolean variable, with the capability to
wait until it is set. Latches can be used to reliably wait until a signal
arrives, which is hard otherwise because signals don't interrupt select()
on some platforms, and even when they do, there's race conditions.
On Unix, latches use the so called self-pipe trick under the covers to
implement the sleep until the latch is set, without race conditions. On
Windows, Windows events are used.
Use the new latch abstraction to sleep in walsender, so that as soon as
a transaction finishes, walsender is woken up to immediately send the WAL
to the standby. This reduces the latency between master and standby, which
is good.
Preliminary work by Fujii Masao. The latch implementation is by me, with
helpful comments from many people.
2010-09-11 17:48:04 +02:00
|
|
|
*/
|
|
|
|
void
|
|
|
|
latch_sigusr1_handler(void)
|
|
|
|
{
|
|
|
|
if (waiting)
|
|
|
|
sendSelfPipeByte();
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Send one byte to the self-pipe, to wake up WaitLatch */
|
|
|
|
static void
|
|
|
|
sendSelfPipeByte(void)
|
|
|
|
{
|
2011-04-10 17:42:00 +02:00
|
|
|
int rc;
|
|
|
|
char dummy = 0;
|
Introduce latches. A latch is a boolean variable, with the capability to
wait until it is set. Latches can be used to reliably wait until a signal
arrives, which is hard otherwise because signals don't interrupt select()
on some platforms, and even when they do, there's race conditions.
On Unix, latches use the so called self-pipe trick under the covers to
implement the sleep until the latch is set, without race conditions. On
Windows, Windows events are used.
Use the new latch abstraction to sleep in walsender, so that as soon as
a transaction finishes, walsender is woken up to immediately send the WAL
to the standby. This reduces the latency between master and standby, which
is good.
Preliminary work by Fujii Masao. The latch implementation is by me, with
helpful comments from many people.
2010-09-11 17:48:04 +02:00
|
|
|
|
|
|
|
retry:
|
|
|
|
rc = write(selfpipe_writefd, &dummy, 1);
|
|
|
|
if (rc < 0)
|
|
|
|
{
|
|
|
|
/* If interrupted by signal, just retry */
|
|
|
|
if (errno == EINTR)
|
|
|
|
goto retry;
|
|
|
|
|
|
|
|
/*
|
2011-04-10 17:42:00 +02:00
|
|
|
* If the pipe is full, we don't need to retry, the data that's there
|
|
|
|
* already is enough to wake up WaitLatch.
|
Introduce latches. A latch is a boolean variable, with the capability to
wait until it is set. Latches can be used to reliably wait until a signal
arrives, which is hard otherwise because signals don't interrupt select()
on some platforms, and even when they do, there's race conditions.
On Unix, latches use the so called self-pipe trick under the covers to
implement the sleep until the latch is set, without race conditions. On
Windows, Windows events are used.
Use the new latch abstraction to sleep in walsender, so that as soon as
a transaction finishes, walsender is woken up to immediately send the WAL
to the standby. This reduces the latency between master and standby, which
is good.
Preliminary work by Fujii Masao. The latch implementation is by me, with
helpful comments from many people.
2010-09-11 17:48:04 +02:00
|
|
|
*/
|
|
|
|
if (errno == EAGAIN || errno == EWOULDBLOCK)
|
|
|
|
return;
|
|
|
|
|
|
|
|
/*
|
2011-04-10 17:42:00 +02:00
|
|
|
* Oops, the write() failed for some other reason. We might be in a
|
|
|
|
* signal handler, so it's not safe to elog(). We have no choice but
|
|
|
|
* silently ignore the error.
|
Introduce latches. A latch is a boolean variable, with the capability to
wait until it is set. Latches can be used to reliably wait until a signal
arrives, which is hard otherwise because signals don't interrupt select()
on some platforms, and even when they do, there's race conditions.
On Unix, latches use the so called self-pipe trick under the covers to
implement the sleep until the latch is set, without race conditions. On
Windows, Windows events are used.
Use the new latch abstraction to sleep in walsender, so that as soon as
a transaction finishes, walsender is woken up to immediately send the WAL
to the standby. This reduces the latency between master and standby, which
is good.
Preliminary work by Fujii Masao. The latch implementation is by me, with
helpful comments from many people.
2010-09-11 17:48:04 +02:00
|
|
|
*/
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2011-08-10 18:20:30 +02:00
|
|
|
/*
|
|
|
|
* Read all available data from the self-pipe
|
|
|
|
*
|
|
|
|
* Note: this is only called when waiting = true. If it fails and doesn't
|
|
|
|
* return, it must reset that flag first (though ideally, this will never
|
|
|
|
* happen).
|
|
|
|
*/
|
Introduce latches. A latch is a boolean variable, with the capability to
wait until it is set. Latches can be used to reliably wait until a signal
arrives, which is hard otherwise because signals don't interrupt select()
on some platforms, and even when they do, there's race conditions.
On Unix, latches use the so called self-pipe trick under the covers to
implement the sleep until the latch is set, without race conditions. On
Windows, Windows events are used.
Use the new latch abstraction to sleep in walsender, so that as soon as
a transaction finishes, walsender is woken up to immediately send the WAL
to the standby. This reduces the latency between master and standby, which
is good.
Preliminary work by Fujii Masao. The latch implementation is by me, with
helpful comments from many people.
2010-09-11 17:48:04 +02:00
|
|
|
static void
|
|
|
|
drainSelfPipe(void)
|
|
|
|
{
|
|
|
|
/*
|
2011-04-10 17:42:00 +02:00
|
|
|
* There shouldn't normally be more than one byte in the pipe, or maybe a
|
2011-08-10 18:20:30 +02:00
|
|
|
* few bytes if multiple processes run SetLatch at the same instant.
|
Introduce latches. A latch is a boolean variable, with the capability to
wait until it is set. Latches can be used to reliably wait until a signal
arrives, which is hard otherwise because signals don't interrupt select()
on some platforms, and even when they do, there's race conditions.
On Unix, latches use the so called self-pipe trick under the covers to
implement the sleep until the latch is set, without race conditions. On
Windows, Windows events are used.
Use the new latch abstraction to sleep in walsender, so that as soon as
a transaction finishes, walsender is woken up to immediately send the WAL
to the standby. This reduces the latency between master and standby, which
is good.
Preliminary work by Fujii Masao. The latch implementation is by me, with
helpful comments from many people.
2010-09-11 17:48:04 +02:00
|
|
|
*/
|
2011-04-10 17:42:00 +02:00
|
|
|
char buf[16];
|
|
|
|
int rc;
|
Introduce latches. A latch is a boolean variable, with the capability to
wait until it is set. Latches can be used to reliably wait until a signal
arrives, which is hard otherwise because signals don't interrupt select()
on some platforms, and even when they do, there's race conditions.
On Unix, latches use the so called self-pipe trick under the covers to
implement the sleep until the latch is set, without race conditions. On
Windows, Windows events are used.
Use the new latch abstraction to sleep in walsender, so that as soon as
a transaction finishes, walsender is woken up to immediately send the WAL
to the standby. This reduces the latency between master and standby, which
is good.
Preliminary work by Fujii Masao. The latch implementation is by me, with
helpful comments from many people.
2010-09-11 17:48:04 +02:00
|
|
|
|
|
|
|
for (;;)
|
|
|
|
{
|
|
|
|
rc = read(selfpipe_readfd, buf, sizeof(buf));
|
|
|
|
if (rc < 0)
|
|
|
|
{
|
|
|
|
if (errno == EAGAIN || errno == EWOULDBLOCK)
|
2011-04-10 17:42:00 +02:00
|
|
|
break; /* the pipe is empty */
|
Introduce latches. A latch is a boolean variable, with the capability to
wait until it is set. Latches can be used to reliably wait until a signal
arrives, which is hard otherwise because signals don't interrupt select()
on some platforms, and even when they do, there's race conditions.
On Unix, latches use the so called self-pipe trick under the covers to
implement the sleep until the latch is set, without race conditions. On
Windows, Windows events are used.
Use the new latch abstraction to sleep in walsender, so that as soon as
a transaction finishes, walsender is woken up to immediately send the WAL
to the standby. This reduces the latency between master and standby, which
is good.
Preliminary work by Fujii Masao. The latch implementation is by me, with
helpful comments from many people.
2010-09-11 17:48:04 +02:00
|
|
|
else if (errno == EINTR)
|
2011-04-10 17:42:00 +02:00
|
|
|
continue; /* retry */
|
Introduce latches. A latch is a boolean variable, with the capability to
wait until it is set. Latches can be used to reliably wait until a signal
arrives, which is hard otherwise because signals don't interrupt select()
on some platforms, and even when they do, there's race conditions.
On Unix, latches use the so called self-pipe trick under the covers to
implement the sleep until the latch is set, without race conditions. On
Windows, Windows events are used.
Use the new latch abstraction to sleep in walsender, so that as soon as
a transaction finishes, walsender is woken up to immediately send the WAL
to the standby. This reduces the latency between master and standby, which
is good.
Preliminary work by Fujii Masao. The latch implementation is by me, with
helpful comments from many people.
2010-09-11 17:48:04 +02:00
|
|
|
else
|
2011-08-10 18:20:30 +02:00
|
|
|
{
|
|
|
|
waiting = false;
|
Introduce latches. A latch is a boolean variable, with the capability to
wait until it is set. Latches can be used to reliably wait until a signal
arrives, which is hard otherwise because signals don't interrupt select()
on some platforms, and even when they do, there's race conditions.
On Unix, latches use the so called self-pipe trick under the covers to
implement the sleep until the latch is set, without race conditions. On
Windows, Windows events are used.
Use the new latch abstraction to sleep in walsender, so that as soon as
a transaction finishes, walsender is woken up to immediately send the WAL
to the standby. This reduces the latency between master and standby, which
is good.
Preliminary work by Fujii Masao. The latch implementation is by me, with
helpful comments from many people.
2010-09-11 17:48:04 +02:00
|
|
|
elog(ERROR, "read() on self-pipe failed: %m");
|
2011-08-10 18:20:30 +02:00
|
|
|
}
|
Introduce latches. A latch is a boolean variable, with the capability to
wait until it is set. Latches can be used to reliably wait until a signal
arrives, which is hard otherwise because signals don't interrupt select()
on some platforms, and even when they do, there's race conditions.
On Unix, latches use the so called self-pipe trick under the covers to
implement the sleep until the latch is set, without race conditions. On
Windows, Windows events are used.
Use the new latch abstraction to sleep in walsender, so that as soon as
a transaction finishes, walsender is woken up to immediately send the WAL
to the standby. This reduces the latency between master and standby, which
is good.
Preliminary work by Fujii Masao. The latch implementation is by me, with
helpful comments from many people.
2010-09-11 17:48:04 +02:00
|
|
|
}
|
|
|
|
else if (rc == 0)
|
2011-08-10 18:20:30 +02:00
|
|
|
{
|
|
|
|
waiting = false;
|
Introduce latches. A latch is a boolean variable, with the capability to
wait until it is set. Latches can be used to reliably wait until a signal
arrives, which is hard otherwise because signals don't interrupt select()
on some platforms, and even when they do, there's race conditions.
On Unix, latches use the so called self-pipe trick under the covers to
implement the sleep until the latch is set, without race conditions. On
Windows, Windows events are used.
Use the new latch abstraction to sleep in walsender, so that as soon as
a transaction finishes, walsender is woken up to immediately send the WAL
to the standby. This reduces the latency between master and standby, which
is good.
Preliminary work by Fujii Masao. The latch implementation is by me, with
helpful comments from many people.
2010-09-11 17:48:04 +02:00
|
|
|
elog(ERROR, "unexpected EOF on self-pipe");
|
2011-08-10 18:20:30 +02:00
|
|
|
}
|
|
|
|
else if (rc < sizeof(buf))
|
|
|
|
{
|
|
|
|
/* we successfully drained the pipe; no need to read() again */
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
/* else buffer wasn't big enough, so read again */
|
Introduce latches. A latch is a boolean variable, with the capability to
wait until it is set. Latches can be used to reliably wait until a signal
arrives, which is hard otherwise because signals don't interrupt select()
on some platforms, and even when they do, there's race conditions.
On Unix, latches use the so called self-pipe trick under the covers to
implement the sleep until the latch is set, without race conditions. On
Windows, Windows events are used.
Use the new latch abstraction to sleep in walsender, so that as soon as
a transaction finishes, walsender is woken up to immediately send the WAL
to the standby. This reduces the latency between master and standby, which
is good.
Preliminary work by Fujii Masao. The latch implementation is by me, with
helpful comments from many people.
2010-09-11 17:48:04 +02:00
|
|
|
}
|
|
|
|
}
|