Simon Riggs wrote:
On Mon, 2010-04-05 at 19:29 +0100, Simon Riggs wrote:
Looking through the code some more I note that their are two timing
related parameters that are hardcoded into XLogPageRead(). At the very
least such things should be #defines, though one of them was previously
Fujii Masao wrote:
On Tue, Apr 6, 2010 at 3:29 AM, Simon Riggs si...@2ndquadrant.com wrote:
I was also surprised to note that the Startup process is not signaled by
WALReceiver when new WAL is received, so it will continue sleeping even
though it has work to do.
I don't think this is so
On Tue, 2010-04-06 at 10:19 +0300, Heikki Linnakangas wrote:
Fujii Masao wrote:
On Tue, Apr 6, 2010 at 3:29 AM, Simon Riggs si...@2ndquadrant.com wrote:
I was also surprised to note that the Startup process is not signaled by
WALReceiver when new WAL is received, so it will continue
Simon Riggs wrote:
On Tue, 2010-04-06 at 10:19 +0300, Heikki Linnakangas wrote:
Fujii Masao wrote:
On Tue, Apr 6, 2010 at 3:29 AM, Simon Riggs si...@2ndquadrant.com wrote:
I was also surprised to note that the Startup process is not signaled by
WALReceiver when new WAL is received, so it will
On Tue, 2010-04-06 at 12:38 +0300, Heikki Linnakangas wrote:
Simon Riggs wrote:
On Tue, 2010-04-06 at 10:19 +0300, Heikki Linnakangas wrote:
Fujii Masao wrote:
On Tue, Apr 6, 2010 at 3:29 AM, Simon Riggs si...@2ndquadrant.com wrote:
I was also surprised to note that the Startup process is
Simon Riggs wrote:
I am surprised at your arguments for simplicity. With Hot Standby you
have insisted that everything should be in place. With SR you seem to
have just stopped at a barely working, poorly documented implementation.
That's opposite to my recollection of the hot standby
Heikki Linnakangas heikki.linnakan...@enterprisedb.com writes:
Well, it would still be useful, as it would shorten the delay. But yeah,
there's a delay in asynchronous replication anyway, so we decided to
keep it simple and just poll. It's not ideal and definitely needs to be
revisited for
On Tue, Apr 6, 2010 at 8:06 PM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
If you insist, I'll work out a patch to send a signal to startup process
after every fsync(), but it really doesn't seem very important given
that there's always a delay there anyway.
Agreed. Even if
Dimitri Fontaine wrote:
Heikki Linnakangas heikki.linnakan...@enterprisedb.com writes:
Well, it would still be useful, as it would shorten the delay. But yeah,
there's a delay in asynchronous replication anyway, so we decided to
keep it simple and just poll. It's not ideal and definitely needs
On Tue, 2010-04-06 at 14:06 +0300, Heikki Linnakangas wrote:
If you insist, I'll work out a patch to send a signal to startup process
after every fsync(), but it really doesn't seem very important given
that there's always a delay there anyway.
We both know you can fix these things easily
On Tue, Apr 6, 2010 at 7:06 AM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
Simon Riggs wrote:
I am surprised at your arguments for simplicity. With Hot Standby you
have insisted that everything should be in place. With SR you seem to
have just stopped at a barely working,
On Tue, 2010-04-06 at 07:47 -0400, Robert Haas wrote:
I've been thinking that the reason we weren't going to beta was
because of the SR open items, but I'm starting to think there's not
much left that really needs to be dealt with. The ones from that list
I think we should fix yet are:
-
On Tue, Apr 6, 2010 at 8:01 AM, Simon Riggs si...@2ndquadrant.com wrote:
On Tue, 2010-04-06 at 07:47 -0400, Robert Haas wrote:
I've been thinking that the reason we weren't going to beta was
because of the SR open items, but I'm starting to think there's not
much left that really needs to be
Heikki Linnakangas heikki.linnakan...@enterprisedb.com writes:
When the startup process wakes up after sleep to replay WAL, it does
replay all the WAL streamed that far. And if more WAL if streamed during
the replay, it's replayed too before the next sleep. But when it does
reach the end of
Simon Riggs wrote:
On Tue, 2010-04-06 at 12:38 +0300, Heikki Linnakangas wrote:
Simon Riggs wrote:
On Tue, 2010-04-06 at 10:19 +0300, Heikki Linnakangas wrote:
Fujii Masao wrote:
On Tue, Apr 6, 2010 at 3:29 AM, Simon Riggs si...@2ndquadrant.com wrote:
I was also surprised to note that the
On Tue, 2010-04-06 at 16:01 +0300, Heikki Linnakangas wrote:
Having the Startup process wait does not buy us anything at all.
Currently if the Startup process finishes more quickly than the
WALreceiver it will wait for 100ms.
Ok, here's a patch to add signaling between walreceiver and
Heikki Linnakangas heikki.linnakan...@enterprisedb.com writes:
Ok, here's a patch to add signaling between walreceiver and startup
process. It indeed isn't much code, and seems pretty safe, so if no-one
objects strongly, I'll commit.
I object --- this seems like a large change to be sticking
Heikki Linnakangas heikki.linnakan...@enterprisedb.com writes:
Ok, here's a patch to add signaling between walreceiver and startup
process. It indeed isn't much code, and seems pretty safe
Great news! Thanks,
--
dim
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To
On Sat, Apr 3, 2010 at 6:50 AM, Simon Riggs sri...@postgresql.org wrote:
Log Message:
---
Check compulsory parameters in recovery.conf in standby_mode, per docs.
On the recent discussion (*1), some people argued that specifying neither
primary_conninfo nor restore_command in the
On Mon, 2010-04-05 at 17:08 +0900, Fujii Masao wrote:
On Sat, Apr 3, 2010 at 6:50 AM, Simon Riggs sri...@postgresql.org wrote:
Log Message:
---
Check compulsory parameters in recovery.conf in standby_mode, per docs.
On the recent discussion (*1), some people argued that
Simon Riggs wrote:
I am very disconcerted that there are still no docs whatsoever to
describe how the server works in these new modes.
I did add a few paragraphs last week, see
http://developer.postgresql.org/pgdocs/postgres/warm-standby.html#STANDBY-SERVER-OPERATION.
It doesn't explicitly talk
On Mon, 2010-04-05 at 19:01 +0300, Heikki Linnakangas wrote:
Simon Riggs wrote:
I am very disconcerted that there are still no docs whatsoever to
describe how the server works in these new modes.
I did add a few paragraphs last week, see
On Mon, 2010-04-05 at 17:08 +0900, Fujii Masao wrote:
On Sat, Apr 3, 2010 at 6:50 AM, Simon Riggs sri...@postgresql.org wrote:
Log Message:
---
Check compulsory parameters in recovery.conf in standby_mode, per docs.
On the recent discussion (*1), some people argued that
On Mon, 2010-04-05 at 19:29 +0100, Simon Riggs wrote:
Looking through the code some more I note that their are two timing
related parameters that are hardcoded into XLogPageRead(). At the very
least such things should be #defines, though one of them was previously
configurable using
Simon Riggs escribió:
On Mon, 2010-04-05 at 17:08 +0900, Fujii Masao wrote:
On Sat, Apr 3, 2010 at 6:50 AM, Simon Riggs sri...@postgresql.org wrote:
Log Message:
---
Check compulsory parameters in recovery.conf in standby_mode, per docs.
On the recent discussion (*1), some
On Mon, 2010-04-05 at 15:02 -0400, Alvaro Herrera wrote:
Simon Riggs escribió:
On Mon, 2010-04-05 at 17:08 +0900, Fujii Masao wrote:
On Sat, Apr 3, 2010 at 6:50 AM, Simon Riggs sri...@postgresql.org wrote:
Log Message:
---
Check compulsory parameters in recovery.conf in
On Mon, Apr 5, 2010 at 3:42 PM, Simon Riggs si...@2ndquadrant.com wrote:
On Mon, 2010-04-05 at 15:02 -0400, Alvaro Herrera wrote:
Simon Riggs escribió:
On Mon, 2010-04-05 at 17:08 +0900, Fujii Masao wrote:
On Sat, Apr 3, 2010 at 6:50 AM, Simon Riggs sri...@postgresql.org
wrote:
Log
Simon Riggs si...@2ndquadrant.com writes:
(errmsg(recovery command file \%s\
specified neither primary_conninfo nor restore_command,
-
RECOVERY_COMMAND_FILE)));
+
On Mon, 2010-04-05 at 15:58 -0400, Tom Lane wrote:
Simon Riggs si...@2ndquadrant.com writes:
(errmsg(recovery command file \%s\
specified neither primary_conninfo nor restore_command,
-
On Mon, Apr 5, 2010 at 4:18 PM, Simon Riggs si...@2ndquadrant.com wrote:
On Mon, 2010-04-05 at 15:58 -0400, Tom Lane wrote:
Simon Riggs si...@2ndquadrant.com writes:
(errmsg(recovery command file \%s\
specified neither primary_conninfo nor
On Tue, Apr 6, 2010 at 3:29 AM, Simon Riggs si...@2ndquadrant.com wrote:
I was also surprised to note that the Startup process is not signaled by
WALReceiver when new WAL is received, so it will continue sleeping even
though it has work to do.
I don't think this is so useful in 9.0 since
31 matches
Mail list logo
