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?
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
Hello everyone,
I am designing a heartbeat system between replicas to know when a replica
goes down so that necessary measures can be taken. As I see, there are two
ways of doing it:
1) Creating a separate heartbeat process on replicas.
2) Creating a heartbeat message, and sending it over the
Apologies. I'm new to Postgres and I didn't see that feature. It satisfies
what I want to do.
Thanks.
On Thu, Sep 16, 2010 at 7:34 PM, Fujii Masao masao.fu...@gmail.com wrote:
On Fri, Sep 17, 2010 at 6:49 AM, fazool mein fazoolm...@gmail.com wrote:
I am designing a heartbeat system between
Hi,
I want to shut down the server under certain conditions that can be checked
inside a backend process. For instance, while running symmetric replication,
if the primary dies, I want the the walreceiver to detect that and shutdown
the standby. The reason for shutdown is that I want to execute
On Mon, Sep 20, 2010 at 9:44 PM, Fujii Masao masao.fu...@gmail.com wrote:
On Tue, Sep 21, 2010 at 9:48 AM, fazool mein fazoolm...@gmail.com wrote:
Hi,
I want to shut down the server under certain conditions that can be
checked
inside a backend process. For instance, while running
On Tue, Sep 21, 2010 at 8:32 AM, David Fetter da...@fetter.org wrote:
On Mon, Sep 20, 2010 at 05:48:40PM -0700, fazool mein wrote:
Hi,
I want to shut down the server under certain conditions that can be
checked inside a backend process. For instance, while running
symmetric
Thanks for the tips.
In our case, SIGINT makes more sense. I'll use that.
Regards
On Tue, Sep 21, 2010 at 7:50 PM, Fujii Masao masao.fu...@gmail.com wrote:
On Wed, Sep 22, 2010 at 2:50 AM, fazool mein fazoolm...@gmail.com wrote:
Yes, I'll be modifying the code. In the walreceiver, I used
or some bug?
Thanks.
On Fri, Sep 17, 2010 at 7:05 PM, fazool mein fazoolm...@gmail.com wrote:
Apologies. I'm new to Postgres and I didn't see that feature. It satisfies
what I want to do.
Thanks.
On Thu, Sep 16, 2010 at 7:34 PM, Fujii Masao masao.fu...@gmail.comwrote:
On Fri, Sep 17
Ah, great. I missed looking there.
Thanks.
On Sun, Sep 26, 2010 at 4:19 PM, Fujii Masao masao.fu...@gmail.com wrote:
On Mon, Sep 27, 2010 at 7:46 AM, fazool mein fazoolm...@gmail.com wrote:
I checked the code for the keepalive feature. It seems that the socket
options are only set
Hello guys,
The concept of time line makes sense to me in the case of asynchronous
replication. But in case of synchronous replication, I am not so sure.
When a standby connects to the primary, it checks if both have the same time
line. If not, it doesn't start.
Now, consider the following
I believe we should come up with a universal solution that will solve
potential future problems as well (for example, if in sync replication, we
decide to send writes to standbys in parallel to writing on local disk).
The ideal thing would be to have an id that is incremented on every failure,
Hello guys,
I'm writing a function that will read data from the buffer in xlog (i.e.
from XLogCtl-pages and XLogCtl-xlblocks). I want to make sure that I am
doing it correctly.
For reading from the buffer, do I need to lock WALInsertLock or
WALWriteLock? Also, can you explain a bit the usage of
Might I suggest adopting the same technique walsender does, ie just read
the data back from disk? There's a reason why we gave up trying to have
walsender read directly from the buffers.
That is exactly what I do not want to do, i.e. read from disk, as long as
the piece of WAL is available
On Tue, Oct 26, 2010 at 11:23 AM, Robert Haas robertmh...@gmail.com wrote:
On Tue, Oct 26, 2010 at 2:13 PM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
Can you please describe why
walsender reading directly from the buffers was given up? To avoid a lot
of
locking?
15 matches
Mail list logo
