On Wed, September 15, 2010 11:58, Fujii Masao wrote:
On Wed, Sep 15, 2010 at 6:38 AM, David Fetter da...@fetter.org wrote:
Now that the latch patch is in, when do you think you'll be able to use it
instead of the poll loop?
Here is the updated version, which uses a latch in communication from
nevermind... I see standbys.conf is now used.
sorry for the noise...
Erik Rijkers
On Thu, September 16, 2010 01:12, Erik Rijkers wrote:
On Wed, September 15, 2010 11:58, Fujii Masao wrote:
On Wed, Sep 15, 2010 at 6:38 AM, David Fetter da...@fetter.org wrote:
Now that the latch patch is in,
On Fri, Sep 10, 2010 at 11:52:20AM +0900, Fujii Masao wrote:
On Fri, Sep 3, 2010 at 3:42 PM, Fujii Masao masao.fu...@gmail.com wrote:
Here is the proposed detailed design:
standbys.conf
=
# This is not initialized by initdb, so users need to create it under
$PGDATA.
On Fri, Sep 10, 2010 at 11:52 AM, Fujii Masao masao.fu...@gmail.com wrote:
The attached patch implements the above and simple synchronous replication
feature, which doesn't include quorum commit capability. The replication
mode (async, recv, fsync, replay) can be specified on a per-standby
On 06/09/10 17:14, Simon Riggs wrote:
On Mon, 2010-09-06 at 16:14 +0300, Heikki Linnakangas wrote:
The standby is sending a stream of messages to the master with current
LSN positions at the time the message is sent. Given a synchronous
transaction, the master would wait until the feedback
On Tue, 2010-09-07 at 09:27 +0300, Heikki Linnakangas wrote:
On 06/09/10 17:14, Simon Riggs wrote:
On Mon, 2010-09-06 at 16:14 +0300, Heikki Linnakangas wrote:
The standby is sending a stream of messages to the master with current
LSN positions at the time the message is sent. Given a
On 07/09/10 12:47, Simon Riggs wrote:
The WAL is sent from master to standby in 8192 byte chunks, frequently
including multiple commits. From standby, one reply per chunk. If we
need to wait for apply while nothing else is received, we do.
Ok, thank you. The obvious performance problem is that
On Tue, 2010-09-07 at 13:11 +0300, Heikki Linnakangas wrote:
The obvious performance problem
Is not obvious at all, and you misunderstand again. This emphasises the
need for me to show code.
--
Simon Riggs www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Training and
Simon Riggs si...@2ndquadrant.com writes:
On Tue, 2010-09-07 at 09:27 +0300, Heikki Linnakangas wrote:
For the sake of argument, yes that's what I was thinking. Now please
explain how *you're* thinking it should work.
The WAL is sent from master to standby in 8192 byte chunks, frequently
On Tue, 2010-09-07 at 10:47 -0400, Tom Lane wrote:
Simon Riggs si...@2ndquadrant.com writes:
On Tue, 2010-09-07 at 09:27 +0300, Heikki Linnakangas wrote:
For the sake of argument, yes that's what I was thinking. Now please
explain how *you're* thinking it should work.
The WAL is sent
Simon Riggs si...@2ndquadrant.com writes:
On Tue, 2010-09-07 at 10:47 -0400, Tom Lane wrote:
Simon Riggs si...@2ndquadrant.com writes:
The WAL is sent from master to standby in 8192 byte chunks, frequently
including multiple commits. From standby, one reply per chunk. If we
need to wait for
On Tue, Sep 7, 2010 at 11:41 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Oh, well you certainly didn't explain it well then.
What I *think* you're saying is that the slave doesn't send per-commit
messages, but instead processes the WAL as it's received and then sends
a heres-where-I-am status
On Tue, 2010-09-07 at 11:41 -0400, Tom Lane wrote:
Simon Riggs si...@2ndquadrant.com writes:
On Tue, 2010-09-07 at 10:47 -0400, Tom Lane wrote:
Simon Riggs si...@2ndquadrant.com writes:
The WAL is sent from master to standby in 8192 byte chunks, frequently
including multiple commits. From
On Tue, Sep 7, 2010 at 11:59 AM, Simon Riggs si...@2ndquadrant.com wrote:
What I *think* you're saying is that the slave doesn't send per-commit
messages, but instead processes the WAL as it's received and then sends
a heres-where-I-am status message back upstream immediately before going
to
On Tue, 2010-09-07 at 12:07 -0400, Robert Haas wrote:
On Tue, Sep 7, 2010 at 11:59 AM, Simon Riggs si...@2ndquadrant.com wrote:
What I *think* you're saying is that the slave doesn't send per-commit
messages, but instead processes the WAL as it's received and then sends
a heres-where-I-am
On Tue, Sep 7, 2010 at 2:15 PM, Simon Riggs si...@2ndquadrant.com wrote:
Every time I explain anything, I get someone run around shouting but
that can't work!. I'm sorry, but again your logic is poor and the bias
against properly considering viable alternatives is the only thing
perfectly
Robert Haas wrote:
On Tue, Sep 7, 2010 at 11:59 AM, Simon Riggs si...@2ndquadrant.com wrote:
What I *think* you're saying is that the slave doesn't send per-commit
messages, but instead processes the WAL as it's received and then sends
a heres-where-I-am status message back upstream
Disclaimer : I have understood things in a way that allows me to answer
here, I don't know at all if that's the way it's meant to be understood.
Heikki Linnakangas heikki.linnakan...@enterprisedb.com writes:
(scratches head..) What's the point of differentiating
received/fsynced/replayed, if
On 06/09/10 16:03, Dimitri Fontaine wrote:
Heikki Linnakangasheikki.linnakan...@enterprisedb.com writes:
(scratches head..) What's the point of differentiating
received/fsynced/replayed, if the master receives the ack for all of them at
the same time?
It wouldn't the way I understand Simon's
On Mon, 2010-09-06 at 16:14 +0300, Heikki Linnakangas wrote:
The standby is sending a stream of messages to the master with current
LSN positions at the time the message is sent. Given a synchronous
transaction, the master would wait until the feedback stream reports
that the current
On Mon, Sep 6, 2010 at 10:14 AM, Simon Riggs si...@2ndquadrant.com wrote:
That doesn't really answer the question: *when* does standby send back
the acknowledgment?
I think you should explain when you think this happens in your proposal.
Are you saying that you think the standby should send
On Fri, 2010-09-03 at 12:50 +0900, Fujii Masao wrote:
On Thu, Sep 2, 2010 at 11:32 PM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
I understand what you're after, the idea of being able to set
synchronization level on a per-transaction basis is cool. But I haven't seen
a
On Thu, Sep 2, 2010 at 7:24 PM, Fujii Masao masao.fu...@gmail.com wrote:
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,
On 03/09/10 09:36, Simon Riggs wrote:
On Fri, 2010-09-03 at 12:50 +0900, Fujii Masao wrote:
That design would affect what the standby should reply. If we choose
async/recv/fsync/replay on a per-transaction basis, the standby
should send multiple LSNs and the master needs to decide when
On Fri, Sep 3, 2010 at 3:36 PM, Simon Riggs si...@2ndquadrant.com wrote:
The former seems to be more useful, but triples the number of ACK
from the standby. I'm not sure whether its overhead is ignorable,
especially when the distance between the master and the standby is
very long.
No, it
On Fri, 2010-09-03 at 09:55 +0300, Heikki Linnakangas wrote:
On 03/09/10 09:36, Simon Riggs wrote:
On Fri, 2010-09-03 at 12:50 +0900, Fujii Masao wrote:
That design would affect what the standby should reply. If we choose
async/recv/fsync/replay on a per-transaction basis, the standby
On 03/09/10 10:45, Simon Riggs wrote:
On Fri, 2010-09-03 at 09:55 +0300, Heikki Linnakangas wrote:
On 03/09/10 09:36, Simon Riggs wrote:
On Fri, 2010-09-03 at 12:50 +0900, Fujii Masao wrote:
That design would affect what the standby should reply. If we choose
async/recv/fsync/replay on a
On Fri, 2010-09-03 at 12:33 +0300, Heikki Linnakangas wrote:
On 03/09/10 10:45, Simon Riggs wrote:
On Fri, 2010-09-03 at 09:55 +0300, Heikki Linnakangas wrote:
On 03/09/10 09:36, Simon Riggs wrote:
On Fri, 2010-09-03 at 12:50 +0900, Fujii Masao wrote:
That design would affect what the
On 03/09/10 13:20, Simon Riggs wrote:
On Fri, 2010-09-03 at 12:33 +0300, Heikki Linnakangas wrote:
On 03/09/10 10:45, Simon Riggs wrote:
On Fri, 2010-09-03 at 09:55 +0300, Heikki Linnakangas wrote:
On 03/09/10 09:36, Simon Riggs wrote:
On Fri, 2010-09-03 at 12:50 +0900, Fujii Masao wrote:
On Wed, Sep 1, 2010 at 7:23 PM, Heikki Linnakangas
heikki.linnakan...@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
On Thu, 2010-09-02 at 19:24 +0900, Fujii Masao wrote:
On Wed, Sep 1, 2010 at 7:23 PM, Heikki Linnakangas
heikki.linnakan...@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
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.linnakan...@enterprisedb.com wrote:
That requirement falls out from the handling of disconnected standbys. If a
standby is not connected, what
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.linnakan...@enterprisedb.com wrote:
That requirement falls out from the
On Thu, Sep 2, 2010 at 8:44 AM, Simon Riggs si...@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
Robert Haas robertmh...@gmail.com writes:
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.
Well as a DBA I think I'd much prefer to attribute votes to each
standby so that each ack is weighted. Let me
On Thu, 2010-09-02 at 08:59 -0400, Robert Haas wrote:
On Thu, Sep 2, 2010 at 8:44 AM, Simon Riggs si...@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
On Thu, Sep 2, 2010 at 10:06 AM, Simon Riggs si...@2ndquadrant.com wrote:
On Thu, 2010-09-02 at 08:59 -0400, Robert Haas wrote:
On Thu, Sep 2, 2010 at 8:44 AM, Simon Riggs si...@2ndquadrant.com wrote:
All standbys has no meaning without registration. It is not a question
that needs an
On 02/09/10 17:06, Simon Riggs wrote:
On Thu, 2010-09-02 at 08:59 -0400, Robert Haas wrote:
On Thu, Sep 2, 2010 at 8:44 AM, Simon Riggssi...@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
On Wed, Sep 01, 2010 at 04:53:38PM +0900, Fujii Masao wrote:
- 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.
Oracle
On Thu, Sep 2, 2010 at 11:32 PM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
I understand what you're after, the idea of being able to set
synchronization level on a per-transaction basis is cool. But I haven't seen
a satisfactory design for it. I don't understand how it would
On Wed, Sep 1, 2010 at 2:33 PM, Heikki Linnakangas
heikki.linnakan...@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
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
On Wed, Sep 1, 2010 at 6:23 AM, Heikki Linnakangas
heikki.linnakan...@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,
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
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
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
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
On Tue, Aug 31, 2010 at 6:24 PM, David Fetter da...@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
On Tue, Aug 31, 2010 at 6:24 PM, David Fetter da...@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
On Tue, Aug 31, 2010 at 08:34:31PM -0400, Robert Haas wrote:
On Tue, Aug 31, 2010 at 6:24 PM, David Fetter da...@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,
On Tue, Aug 31, 2010 at 8:45 PM, David Fetter da...@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
On Wed, Sep 1, 2010 at 9:34 AM, Robert Haas robertmh...@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.
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.fu...@gmail.com wrote:
On Wed, Sep 1, 2010 at 9:34 AM, Robert Haas robertmh...@gmail.com wrote:
There are patches, and the latest from Fujii Masao
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
54 matches
Mail list logo
