Synchronous replication - patch status inquiry

fazool mein wrote:

Hello everyone,

I'm interested in benchmarking synchronous replication, to see how
performance degrades compared to asynchronous streaming replication.

I browsed through the archive of emails, but things still seem unclear. Do
we have a final agreed upon patch that I can use? Any links for that?

No.

--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ It's impossible for everything to be true. +

On Tue, Aug 31, 2010 at 05:44:15PM -0400, Bruce Momjian wrote:

fazool mein wrote:

Hello everyone,

I'm interested in benchmarking synchronous replication, to see how
performance degrades compared to asynchronous streaming replication.

I browsed through the archive of emails, but things still seem unclear. Do
we have a final agreed upon patch that I can use? Any links for that?

No.

That was a mite brusque and not super informative.

There are patches, and the latest from Fujii Masao is probably worth
looking at :)

Cheers,
David.
--
David Fetter <david@fetter.org> http://fetter.org/
Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter
Skype: davidfetter XMPP: david.fetter@gmail.com
iCal: webcal://www.tripit.com/feed/ical/people/david74/tripit.ics

Remember to vote!
Consider donating to Postgres: http://www.postgresql.org/about/donate

On Tue, Aug 31, 2010 at 6:24 PM, David Fetter <david@fetter.org> wrote:

On Tue, Aug 31, 2010 at 05:44:15PM -0400, Bruce Momjian wrote:

fazool mein wrote:

Hello everyone,

I'm interested in benchmarking synchronous replication, to see how
performance degrades compared to asynchronous streaming replication.

I browsed through the archive of emails, but things still seem unclear. Do
we have a final agreed upon patch that I can use? Any links for that?

No.

That was a mite brusque and not super informative.

There are patches, and the latest from Fujii Masao is probably worth
looking at :)

I am pretty sure, however, that the performance will be terrible at
this point. Heikki is working on fixing that, but it ain't done yet.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise Postgres Company

On Tue, Aug 31, 2010 at 6:24 PM, David Fetter <david@fetter.org> wrote:

On Tue, Aug 31, 2010 at 05:44:15PM -0400, Bruce Momjian wrote:

fazool mein wrote:

Hello everyone,

I'm interested in benchmarking synchronous replication, to see how
performance degrades compared to asynchronous streaming replication.

I browsed through the archive of emails, but things still seem unclear. Do
we have a final agreed upon patch that I can use? Any links for that?

No.

That was a mite brusque and not super informative.

There are patches, and the latest from Fujii Masao is probably worth
looking at :)

I am pretty sure, however, that the performance will be terrible at
this point. Heikki is working on fixing that, but it ain't done yet.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise Postgres Company

On Tue, Aug 31, 2010 at 08:34:31PM -0400, Robert Haas wrote:

On Tue, Aug 31, 2010 at 6:24 PM, David Fetter <david@fetter.org> wrote:

On Tue, Aug 31, 2010 at 05:44:15PM -0400, Bruce Momjian wrote:

fazool mein wrote:

Hello everyone,

I'm interested in benchmarking synchronous replication, to see
how performance degrades compared to asynchronous streaming
replication.

I browsed through the archive of emails, but things still seem
unclear. Do we have a final agreed upon patch that I can use?
Any links for that?

No.

That was a mite brusque and not super informative.

There are patches, and the latest from Fujii Masao is probably
worth looking at :)

I am pretty sure, however, that the performance will be terrible at
this point. Heikki is working on fixing that, but it ain't done
yet.

Is this something for an eDB feature, or for community PostgreSQL,
or...?

Cheers,
David.
--
David Fetter <david@fetter.org> http://fetter.org/
Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter
Skype: davidfetter XMPP: david.fetter@gmail.com
iCal: webcal://www.tripit.com/feed/ical/people/david74/tripit.ics

Remember to vote!
Consider donating to Postgres: http://www.postgresql.org/about/donate

On Tue, Aug 31, 2010 at 8:45 PM, David Fetter <david@fetter.org> wrote:

I am pretty sure, however, that the performance will be terrible at
this point.  Heikki is working on fixing that, but it ain't done
yet.

Is this something for an eDB feature, or for community PostgreSQL,
or...?

It's an EDB feature in the sense that Heikki is developing it as part
of his employment with EDB, but it will be committed to community
PostgreSQL. See the thread on interruptible sleeps. The problem
right now is that there are some polling loops that act to throttle
the maximum rate at which a node doing sync rep can make forward
progress, independent of the capabilities of the hardware. Those need
to be replaced with a system that doesn't inject unnecessary delays
into the process, which is what Heikki is working on.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise Postgres Company

On Wed, Sep 1, 2010 at 9:34 AM, Robert Haas <robertmhaas@gmail.com> wrote:

There are patches, and the latest from Fujii Masao is probably worth
looking at :)

I am pretty sure, however, that the performance will be terrible at
this point.  Heikki is working on fixing that, but it ain't done yet.

Yep. The latest WIP code is available in my git repository, but it's
not worth benchmarking yet. I'll need to merge Heikki's effort and
the synchronous replication patch.

git://git.postgresql.org/git/users/fujii/postgres.git
branch: synchrep

Regards,

--
Fujii Masao
NIPPON TELEGRAPH AND TELEPHONE CORPORATION
NTT Open Source Software Center

Thanks!

I'll wait for the merging then; there is no point in benchmarking otherwise.

Regards

On Tue, Aug 31, 2010 at 6:06 PM, Fujii Masao <masao.fujii@gmail.com> wrote:

On 01/09/10 04:02, Robert Haas wrote:

See the thread on interruptible sleeps. The problem
right now is that there are some polling loops that act to throttle
the maximum rate at which a node doing sync rep can make forward
progress, independent of the capabilities of the hardware.

To be precise, the polling doesn't affect the "bandwidth" the
replication can handle, but it introduces a delay wh

Those need
to be replaced with a system that doesn't inject unnecessary delays
into the process, which is what Heikki is working on.

Right.

Once we're done with that, all the big questions are still left. How to
configure it? What does synchronous replication mean, when is a
transaction acknowledged as committed? What to do if a standby server
dies and never acknowledges a commit? All these issues have been
discussed, but there is no consensus yet.

--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com

On Wed, Sep 1, 2010 at 2:33 PM, Heikki Linnakangas
<heikki.linnakangas@enterprisedb.com> wrote:

Once we're done with that, all the big questions are still left.

Yeah, let's discuss about those topics :)

How to configure it?

Before discussing about that, we should determine whether registering
standbys in master is really required. It affects configuration a lot.
Heikki thinks that it's required, but I'm still unclear about why and
how.

Why do standbys need to be registered in master? What information
should be registered?

What does synchronous replication mean, when is a transaction
acknowledged as committed?

I proposed four synchronization levels:

1. async
doesn't make transaction commit wait for replication, i.e.,
asynchronous replication. This mode has been already supported in
9.0.

2. recv
makes transaction commit wait until the standby has received WAL
records.

3. fsync
makes transaction commit wait until the standby has received and
flushed WAL records to disk

4. replay
makes transaction commit wait until the standby has replayed WAL
records after receiving and flushing them to disk

OTOH, Simon proposed the quorum commit feature. I think that both
is required for various our use cases. Thought?

What to do if a standby server dies and never
acknowledges a commit?

The master's reaction to that situation should be configurable. So
I'd propose new configuration parameter specifying the reaction.
Valid values are:

- standalone
When the master has waited for the ACK much longer than the timeout
(or detected the failure of the standby), it closes the connection
to the standby and restarts transactions.

- down
When that situation occurs, the master shuts down immediately.
Though this is unsafe for the system requiring high availability,
as far as I recall, some people wanted this mode in the previous
discussion.

Regards,

--
Fujii Masao
NIPPON TELEGRAPH AND TELEPHONE CORPORATION
NTT Open Source Software Center

On 01/09/10 10:53, Fujii Masao wrote:

Before discussing about that, we should determine whether registering
standbys in master is really required. It affects configuration a lot.
Heikki thinks that it's required, but I'm still unclear about why and
how.

Why do standbys need to be registered in master? What information
should be registered?

That requirement falls out from the handling of disconnected standbys.
If a standby is not connected, what does the master do with commits? If
the answer is anything else than acknowledge them to the client
immediately, as if the standby never existed, the master needs to know
what standby servers exist. Otherwise it can't know if all the standbys
are connected or not.

What does synchronous replication mean, when is a transaction
acknowledged as committed?

I proposed four synchronization levels:

1. async
doesn't make transaction commit wait for replication, i.e.,
asynchronous replication. This mode has been already supported in
9.0.

2. recv
makes transaction commit wait until the standby has received WAL
records.

3. fsync
makes transaction commit wait until the standby has received and
flushed WAL records to disk

4. replay
makes transaction commit wait until the standby has replayed WAL
records after receiving and flushing them to disk

OTOH, Simon proposed the quorum commit feature. I think that both
is required for various our use cases. Thought?

I'd like to keep this as simple as possible, yet flexible so that with
enough scripting and extensions, you can get all sorts of behavior. I
think quorum commit falls into the "extension" category; if you're setup
is complex enough, it's going to be impossible to represent that in our
config files no matter what. But if you write a little proxy, you can
implement arbitrary rules there.

I think recv/fsync/replay should be specified in the standby. It has no
direct effect on the master, the master would just relay the setting to
the standby when it connects, or the standby would send multiple
XLogRecPtrs and let the master decide when the WAL is persistent enough.
And what if you write a proxy that has some other meaning of "persistent
enough"? Like when it has been written to the OS buffers but not yet
fsync'd, or when it has been fsync'd to at least one standby and
received by at least three others. recv/fsync/replay is not going to
represent that behavior well.

"sync vs async" on the other hand should be specified in the master,
because it has a direct impact on the behavior of commits in the master.

I propose a configuration file standbys.conf, in the master:

# STANDBY NAME SYNCHRONOUS TIMEOUT
importantreplica yes 100ms
tempcopy no 10s

Or perhaps this should be stored in a system catalog.

What to do if a standby server dies and never
acknowledges a commit?

The master's reaction to that situation should be configurable. So
I'd propose new configuration parameter specifying the reaction.
Valid values are:

- standalone
When the master has waited for the ACK much longer than the timeout
(or detected the failure of the standby), it closes the connection
to the standby and restarts transactions.

- down
When that situation occurs, the master shuts down immediately.
Though this is unsafe for the system requiring high availability,
as far as I recall, some people wanted this mode in the previous
discussion.

Yeah, though of course you might want to set that per-standby too..

Let's step back a bit and ask what would be the simplest thing that you
could call "synchronous replication" in good conscience, and also be
useful at least to some people. Let's leave out the "down" mode, because
that requires registration. We'll probably have to do registration at
some point, but let's take as small steps as possible.

Without the "down" mode in the master, frankly I don't see the point of
the "recv" and "fsync" levels in the standby. Either way, when the
master acknowledges a commit to the client, you don't know if it has
made it to the standby yet because the replication connection might be
down for some reason.

That leaves us the 'replay' mode, which *is* useful, because it gives
you the guarantee that when the master acknowledges a commit, it will
appear committed in all hot standby servers that are currently
connected. With that guarantee you can build a reliable cluster with
something pgpool-II where all writes go to one node, and reads are
distributed to multiple nodes.

I'm not sure what we should aim for in the first phase. But if you want
as little code as possible yet have something useful, I think 'replay'
mode with no standby registration is the way to go.

--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com

On Wed, 2010-09-01 at 08:33 +0300, Heikki Linnakangas wrote:

On 01/09/10 04:02, Robert Haas wrote:

See the thread on interruptible sleeps. The problem
right now is that there are some polling loops that act to throttle
the maximum rate at which a node doing sync rep can make forward
progress, independent of the capabilities of the hardware.

To be precise, the polling doesn't affect the "bandwidth" the
replication can handle, but it introduces a delay wh

We're sending the WAL data in batches. We can't really escape from the
fact that we're effectively using group commit when we use synch rep.
That will necessarily increase delay and require more sessions to get
same throughput.

Those need
to be replaced with a system that doesn't inject unnecessary delays
into the process, which is what Heikki is working on.

Right.

Once we're done with that, all the big questions are still left. How to
configure it? What does synchronous replication mean, when is a
transaction acknowledged as committed? What to do if a standby server
dies and never acknowledges a commit? All these issues have been
discussed, but there is no consensus yet.

That sounds an awful lot like performance tuning first and the feature
additions last.

And if you're in the middle of performance tuning, surely some objective
performance tests would help us, no?

IMHO we should be concentrating on how to add the next features because
its clear to me that if you do things in the wrong order you'll be
wasting time. And we don't have much of that, ever.

--
Simon Riggs www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Training and Services

On Wed, Sep 1, 2010 at 6:23 AM, Heikki Linnakangas
<heikki.linnakangas@enterprisedb.com> wrote:

I'm not sure what we should aim for in the first phase. But if you want as
little code as possible yet have something useful, I think 'replay' mode
with no standby registration is the way to go.

IMHO, less is more. Trying to do too much at once can cause us to
miss the release window (and can also create more bugs). We just need
to leave the door open to adding later whatever we leave out now.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise Postgres Company

On Wed, 2010-09-01 at 13:23 +0300, Heikki Linnakangas wrote:

On 01/09/10 10:53, Fujii Masao wrote:

Before discussing about that, we should determine whether registering
standbys in master is really required. It affects configuration a lot.
Heikki thinks that it's required, but I'm still unclear about why and
how.

Why do standbys need to be registered in master? What information
should be registered?

That requirement falls out from the handling of disconnected standbys.
If a standby is not connected, what does the master do with commits? If
the answer is anything else than acknowledge them to the client
immediately, as if the standby never existed, the master needs to know
what standby servers exist. Otherwise it can't know if all the standbys
are connected or not.

"All the standbys" presupposes that we know what they are, i.e. we have
registered them, so I see that argument as circular. Quorum commit does
not need registration, so quorum commit is the "easy to implement"
option and registration is the more complex later feature. I don't have
a problem with adding registration later and believe it can be done
later without issues.

What does synchronous replication mean, when is a transaction
acknowledged as committed?

I proposed four synchronization levels:

1. async
doesn't make transaction commit wait for replication, i.e.,
asynchronous replication. This mode has been already supported in
9.0.

2. recv
makes transaction commit wait until the standby has received WAL
records.

3. fsync
makes transaction commit wait until the standby has received and
flushed WAL records to disk

4. replay
makes transaction commit wait until the standby has replayed WAL
records after receiving and flushing them to disk

OTOH, Simon proposed the quorum commit feature. I think that both
is required for various our use cases. Thought?

I'd like to keep this as simple as possible, yet flexible so that with
enough scripting and extensions, you can get all sorts of behavior. I
think quorum commit falls into the "extension" category; if you're setup
is complex enough, it's going to be impossible to represent that in our
config files no matter what. But if you write a little proxy, you can
implement arbitrary rules there.

I think recv/fsync/replay should be specified in the standby.

I think the wait mode (i.e. recv/fsync/replay or others) should be
specified in the master. This allows the application to specify whatever
level of protection it requires, and also allows the behaviour to be
different for user-specifiable parts of the application. As soon as you
set this on the standby then you have the one-size fits all approach to
synchronisation.

We already know performance of synchronous rep is poor, which is exactly
why I want to be able to control it at the application level. Fine
grained control is important, otherwise we may as well just use DRBD and
skip this project completely, since we already have that. It will also
be a feature that no other database has, taking us truly beyond what has
gone before.

The master/standby decision is not something that is easily changed.
Whichever we decide now will be the thing we stick with.

It has no
direct effect on the master, the master would just relay the setting to
the standby when it connects, or the standby would send multiple
XLogRecPtrs and let the master decide when the WAL is persistent enough.
And what if you write a proxy that has some other meaning of "persistent
enough"? Like when it has been written to the OS buffers but not yet
fsync'd, or when it has been fsync'd to at least one standby and
received by at least three others. recv/fsync/replay is not going to
represent that behavior well.

"sync vs async" on the other hand should be specified in the master,
because it has a direct impact on the behavior of commits in the master.

I propose a configuration file standbys.conf, in the master:

# STANDBY NAME SYNCHRONOUS TIMEOUT
importantreplica yes 100ms
tempcopy no 10s

Or perhaps this should be stored in a system catalog.

That part sounds like complexity that can wait until later. I would not
object if you really want this, but would prefer it to look like this:

# STANDBY NAME DEFAULT_WAIT_MODE TIMEOUT
importantreplica sync 100ms
tempcopy async 10s

You don't *have* to use the application level control if you don't want
it. But its an important capability for real world apps, since the
alternative is deliberately splitting an application across two database
servers each with different wait modes.

What to do if a standby server dies and never
acknowledges a commit?

The master's reaction to that situation should be configurable. So
I'd propose new configuration parameter specifying the reaction.
Valid values are:

- standalone
When the master has waited for the ACK much longer than the timeout
(or detected the failure of the standby), it closes the connection
to the standby and restarts transactions.

- down
When that situation occurs, the master shuts down immediately.
Though this is unsafe for the system requiring high availability,
as far as I recall, some people wanted this mode in the previous
discussion.

Yeah, though of course you might want to set that per-standby too..

Let's step back a bit and ask what would be the simplest thing that you
could call "synchronous replication" in good conscience, and also be
useful at least to some people. Let's leave out the "down" mode, because
that requires registration. We'll probably have to do registration at
some point, but let's take as small steps as possible.

Without the "down" mode in the master, frankly I don't see the point of
the "recv" and "fsync" levels in the standby. Either way, when the
master acknowledges a commit to the client, you don't know if it has
made it to the standby yet because the replication connection might be
down for some reason.

That leaves us the 'replay' mode, which *is* useful, because it gives
you the guarantee that when the master acknowledges a commit, it will
appear committed in all hot standby servers that are currently
connected. With that guarantee you can build a reliable cluster with
something pgpool-II where all writes go to one node, and reads are
distributed to multiple nodes.

I'm not sure what we should aim for in the first phase. But if you want
as little code as possible yet have something useful, I think 'replay'
mode with no standby registration is the way to go.

I don't see it as any more code to implement.

When the standby replies, it can return
* latest LSN received
* latest LSN fsynced
* latest LSN replayed
etc

We then release waiting committers on the master according to which of
the above they said they want to wait for. The standby does *not* need
to know the wishes of transactions on the master.

Note that means that receiving, fsyncing and replaying can all progress
as an asynchronous pipeline, giving great overall throughput.

Once you accept that there are multiple modes, then the actual number of
wait modes is unimportant. It's just an array of [NUM_WAIT_MODES], so
the project need not be delayed just because we have 2, 3 or 4 wait
modes.

--
Simon Riggs www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Training and Services

On Wed, Sep 1, 2010 at 7:23 PM, Heikki Linnakangas
<heikki.linnakangas@enterprisedb.com> wrote:

That requirement falls out from the handling of disconnected standbys. If a
standby is not connected, what does the master do with commits? If the
answer is anything else than acknowledge them to the client immediately, as
if the standby never existed, the master needs to know what standby servers
exist. Otherwise it can't know if all the standbys are connected or not.

Thanks. I understood why the registration is required.

I'd like to keep this as simple as possible, yet flexible so that with
enough scripting and extensions, you can get all sorts of behavior. I think
quorum commit falls into the "extension" category; if you're setup is
complex enough, it's going to be impossible to represent that in our config
files no matter what. But if you write a little proxy, you can implement
arbitrary rules there.

Agreed.

I think recv/fsync/replay should be specified in the standby. It has no
direct effect on the master, the master would just relay the setting to the
standby when it connects, or the standby would send multiple XLogRecPtrs and
let the master decide when the WAL is persistent enough.

The latter seems wasteful since the master uses only one XLogRecPtr even if
the standby sends multiple ones. So I prefer the former design. Which also
makes the code and design very simple, and we can easily write the proxy.

"sync vs async" on the other hand should be specified in the master, because
it has a direct impact on the behavior of commits in the master.

I propose a configuration file standbys.conf, in the master:

# STANDBY NAME    SYNCHRONOUS   TIMEOUT
importantreplica  yes           100ms
tempcopy          no            10s

Seems good. In fact, instead of yes/no, async/recv/fsync/replay is specified
in SYNCHRONOUS field?

OTOH, something like standby_name parameter should be introduced in
recovery.conf.

We should allow multiple standbys with the same name? Probably yes.
We might need to add NUMBER field into the standbys.conf, in the future.

Yeah, though of course you might want to set that per-standby too..

Yep.

Let's step back a bit and ask what would be the simplest thing that you
could call "synchronous replication" in good conscience, and also be useful
at least to some people. Let's leave out the "down" mode, because that
requires registration. We'll probably have to do registration at some point,
but let's take as small steps as possible.

Agreed.

Without the "down" mode in the master, frankly I don't see the point of the
"recv" and "fsync" levels in the standby. Either way, when the master
acknowledges a commit to the client, you don't know if it has made it to the
standby yet because the replication connection might be down for some
reason.

True. We cannot know whether the standby can be brought up to the master
without any data loss when the master crashes, because the standby might
be disconnected before for some reasons and not have some latest data.

But the situation would be the same even when 'replay' mode is chosen.
Though we might be able to check whether the latest transaction has
replicated to the standby by running read only query to the standby,
it's actually difficult to do that. How can we know the content of the
latest transaction?

Also even when 'recv' or 'fsync' is chosen, we might be able to check
that by doing pg_last_xlog_receive_location() on the standby. But the
similar question occurs to me: How can we know the LSN of the latest
transaction?

I'm thinking to introduce new parameter specifying the command which
is executed when the standby is disconnected. This command is executed
by walsender before resuming the transaction processings which have
been suspended by the disconnection. For example, if STONISH against
the standby is supplied as the command, we can prevent the standby not
having the latest data from becoming the master by forcibly shutting
such a delayed standby down. Thought?

That leaves us the 'replay' mode, which *is* useful, because it gives you
the guarantee that when the master acknowledges a commit, it will appear
committed in all hot standby servers that are currently connected. With that
guarantee you can build a reliable cluster with something pgpool-II where
all writes go to one node, and reads are distributed to multiple nodes.

I'm concerned that the conflict by read-only query and recovery might
harm the performance on the master in 'replay' mode. If the conflict
occurs, all running transactions on the master have to wait for it to
disappear, and which can take very long. Of course, wihtout the conflict,
waiting until the standby has received, fsync'd, read and replayed WAL
would take long. So I'd like to support also 'recv' and 'fsync'.
I believe that it's not complicated and difficult to implement those
two modes.

I'm not sure what we should aim for in the first phase. But if you want as
little code as possible yet have something useful, I think 'replay' mode
with no standby registration is the way to go.

What about recv/fsync/replay mode with no standby registration?

Regards,

--
Fujii Masao
NIPPON TELEGRAPH AND TELEPHONE CORPORATION
NTT Open Source Software Center

On Thu, 2010-09-02 at 19:24 +0900, Fujii Masao wrote:

On Wed, Sep 1, 2010 at 7:23 PM, Heikki Linnakangas
<heikki.linnakangas@enterprisedb.com> wrote:

That requirement falls out from the handling of disconnected standbys. If a
standby is not connected, what does the master do with commits? If the
answer is anything else than acknowledge them to the client immediately, as
if the standby never existed, the master needs to know what standby servers
exist. Otherwise it can't know if all the standbys are connected or not.

Thanks. I understood why the registration is required.

I don't. There is a simpler design that does not require registration.

Please explain why we need registration, with an explanation that does
not presume it as a requirement.

--
Simon Riggs www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Training and Services

On 02/09/10 15:03, Simon Riggs wrote:

On Thu, 2010-09-02 at 19:24 +0900, Fujii Masao wrote:

On Wed, Sep 1, 2010 at 7:23 PM, Heikki Linnakangas
<heikki.linnakangas@enterprisedb.com> wrote:

That requirement falls out from the handling of disconnected standbys. If a
standby is not connected, what does the master do with commits? If the
answer is anything else than acknowledge them to the client immediately, as
if the standby never existed, the master needs to know what standby servers
exist. Otherwise it can't know if all the standbys are connected or not.

Thanks. I understood why the registration is required.

I don't. There is a simpler design that does not require registration.

Please explain why we need registration, with an explanation that does
not presume it as a requirement.

Please explain how you would implement "don't acknowledge commits until
they're replicated to all standbys" without standby registration.

--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com

On Thu, 2010-09-02 at 15:15 +0300, Heikki Linnakangas wrote:

On 02/09/10 15:03, Simon Riggs wrote:

On Thu, 2010-09-02 at 19:24 +0900, Fujii Masao wrote:

On Wed, Sep 1, 2010 at 7:23 PM, Heikki Linnakangas
<heikki.linnakangas@enterprisedb.com> wrote:

That requirement falls out from the handling of disconnected standbys. If a
standby is not connected, what does the master do with commits? If the
answer is anything else than acknowledge them to the client immediately, as
if the standby never existed, the master needs to know what standby servers
exist. Otherwise it can't know if all the standbys are connected or not.

Thanks. I understood why the registration is required.

I don't. There is a simpler design that does not require registration.

Please explain why we need registration, with an explanation that does
not presume it as a requirement.

Please explain how you would implement "don't acknowledge commits until
they're replicated to all standbys" without standby registration.

"All standbys" has no meaning without registration. It is not a question
that needs an answer.

--
Simon Riggs www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Training and Services

On Thu, Sep 2, 2010 at 8:44 AM, Simon Riggs <simon@2ndquadrant.com> wrote:

"All standbys" has no meaning without registration. It is not a question
that needs an answer.

Tell that to the DBA. I bet s/he knows what "all standbys" means.
The fact that the system doesn't know something doesn't make it
unimportant.

I agree that we don't absolutely need standby registration for some
really basic version of synchronous replication. But I think we'd be
better off biting the bullet and adding it. I think that without it
we're going to resort to a series of increasingly grotty and
user-unfriendly hacks to make this work.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise Postgres Company