Обсуждение: pgsql: Introduce latches.

Log Message:
-----------
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.

Modified Files:
--------------
    pgsql:
        configure (r1.685 -> r1.686)
        (http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/configure?r1=1.685&r2=1.686)
        configure.in (r1.633 -> r1.634)
        (http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/configure.in?r1=1.633&r2=1.634)
    pgsql/src/backend/access/transam:
        twophase.c (r1.63 -> r1.64)
        (http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/backend/access/transam/twophase.c?r1=1.63&r2=1.64)
        xact.c (r1.298 -> r1.299)
        (http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/backend/access/transam/xact.c?r1=1.298&r2=1.299)
    pgsql/src/backend/port:
        Makefile (r1.28 -> r1.29)
        (http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/backend/port/Makefile?r1=1.28&r2=1.29)
    pgsql/src/backend/replication:
        walsender.c (r1.29 -> r1.30)
        (http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/backend/replication/walsender.c?r1=1.29&r2=1.30)
    pgsql/src/backend/storage/ipc:
        ipci.c (r1.104 -> r1.105)
        (http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/backend/storage/ipc/ipci.c?r1=1.104&r2=1.105)
        procsignal.c (r1.7 -> r1.8)
        (http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/backend/storage/ipc/procsignal.c?r1=1.7&r2=1.8)
    pgsql/src/include/replication:
        walsender.h (r1.4 -> r1.5)
        (http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/include/replication/walsender.h?r1=1.4&r2=1.5)
    pgsql/src/tools/msvc:
        Mkvcbuild.pm (r1.59 -> r1.60)
        (http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/tools/msvc/Mkvcbuild.pm?r1=1.59&r2=1.60)

Added Files:
-----------
    pgsql/src/backend/port:
        unix_latch.c (r1.1)

(http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/backend/port/unix_latch.c?rev=1.1&content-type=text/x-cvsweb-markup)
        win32_latch.c (r1.1)

(http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/backend/port/win32_latch.c?rev=1.1&content-type=text/x-cvsweb-markup)
    pgsql/src/include/storage:
        latch.h (r1.1)

(http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/include/storage/latch.h?rev=1.1&content-type=text/x-cvsweb-markup)

Gurjeet Singh <singh.gurjeet@gmail.com> writes:
>> Portions Copyright (c) 1994, Regents of the University of California

> Is that line needed for new files introduced by the Community?

If you can show clearly that no part of a new file has any connection
to the historical Postgres code base, then no you wouldn't need to
include such a credit.  But that seems like an improbable assumption
for most new code added to Postgres.  By and large, I think we should
acknowledge our connections to the work that's gone before, not try
to deny that there's any.

            regards, tom lane