Regarding this item from the wiki page:
The standby delay is measured as current timestamp - timestamp of last
replayed commit record. If there's little activity in the master, that can
lead to surprising results. For example, imagine that max_standby_delay is
set to 8 hours. The standby is
On Fri, 2009-12-04 at 10:37 +0200, Heikki Linnakangas wrote:
Regarding this item from the wiki page:
The standby delay is measured as current timestamp - timestamp of last
replayed commit record. If there's little activity in the master, that can
lead to surprising results. For example,
Simon Riggs wrote:
On Fri, 2009-12-04 at 10:37 +0200, Heikki Linnakangas wrote:
Regarding this item from the wiki page:
The standby delay is measured as current timestamp - timestamp of last
replayed commit record. If there's little activity in the master, that can
lead to surprising
Heikki Linnakangas heikki.linnakan...@enterprisedb.com wrote:
If the system is completely idle, and no WAL is written, we skip
xlog switches too, even if archive_timeout is set . It would be
pointless to create a stream of WAL files with no content except
for the XLOG_SWITCH records.
It's
Heikki Linnakangas wrote:
Simon Riggs wrote:
@@ -654,10 +656,13 @@ LockAcquire(const LOCKTAG *locktag,
elog(PANIC, lock table corrupted);
}
LWLockRelease(partitionLock);
-ereport(ERROR,
-
On Wed, 2009-12-02 at 12:49 +0200, Heikki Linnakangas wrote:
If a read-only transaction holds a lot of locks, consuming so much
lock space that there's none left for the startup process to hold the
lock it wants, it will abort and bring down postmaster. The patch
attempts to kill any
Simon Riggs wrote:
On Wed, 2009-12-02 at 12:49 +0200, Heikki Linnakangas wrote:
If a read-only transaction holds a lot of locks, consuming so much
lock space that there's none left for the startup process to hold the
lock it wants, it will abort and bring down postmaster. The patch
attempts
On Wed, 2009-12-02 at 16:41 +, Simon Riggs wrote:
On Tue, 2009-12-01 at 20:26 +0200, Heikki Linnakangas wrote:
Simon Riggs wrote:
commit 02c3eadb766201db084b668daa271db4a900adc9
Author: Simon Riggs sri...@ebony.(none)
Date: Sat Nov 28 06:23:33 2009 +
Added
Simon Riggs wrote:
Hmm, what happens if someone enables wal_standby_info in postgresql.conf
while the server is shutdown. It would still be a valid starting point
in that case.
Yeah, true.
I'll just make a note, I think.
Yeah, a manual (or automatic, if you just wait) checkpoint will
Simon Riggs wrote:
commit 02c3eadb766201db084b668daa271db4a900adc9
Author: Simon Riggs sri...@ebony.(none)
Date: Sat Nov 28 06:23:33 2009 +
Added wal_standby_info GUC to turn RM_STANDBY_ID messages on/off.
Various comments added also.
This patch makes it unsafe to start hot
Simon Riggs wrote:
@@ -654,10 +656,13 @@ LockAcquire(const LOCKTAG *locktag,
elog(PANIC, lock table corrupted);
}
LWLockRelease(partitionLock);
- ereport(ERROR,
-
On Wed, 2009-11-25 at 13:00 +0200, Heikki Linnakangas wrote:
I've put up a wiki page with the issues I see with the patch as it
stands. They're roughly categorized by seriousness.
http://wiki.postgresql.org/wiki/Hot_Standby_TODO
New issues can and probably will still pop up, let's add them
I've put up a wiki page with the issues I see with the patch as it
stands. They're roughly categorized by seriousness.
http://wiki.postgresql.org/wiki/Hot_Standby_TODO
New issues can and probably will still pop up, let's add them to the
list as they're found so that we know what still needs to
On Wed, 2009-11-25 at 13:00 +0200, Heikki Linnakangas wrote:
I've put up a wiki page with the issues I see with the patch as it
stands. They're roughly categorized by seriousness.
http://wiki.postgresql.org/wiki/Hot_Standby_TODO
New issues can and probably will still pop up, let's add them
14 matches
Mail list logo
