Simon Riggs wrote:
On Sun, 2009-12-06 at 17:26 -0500, Robert Haas wrote:
For what it's worth, this doesn't seem particularly unlikely or
unusual to me.
I don't know many people who shutdown both nodes of a highly available
application at the same time. If they did, I wouldn't expect them
On Mon, 2009-12-07 at 10:02 +0200, Heikki Linnakangas wrote:
Simon Riggs wrote:
On Sun, 2009-12-06 at 17:26 -0500, Robert Haas wrote:
For what it's worth, this doesn't seem particularly unlikely or
unusual to me.
I don't know many people who shutdown both nodes of a highly available
1. The XLogFlush() call you added to dbase_redo doesn't help where it
is. You need to call XLogFlush() after the *commit* record of the DROP
DATABASE. The idea is minimize the window where the files have already
been deleted but the entry in pg_database is still visible, if someone
kills the
On Sun, 2009-12-06 at 12:32 +0200, Heikki Linnakangas wrote:
2. Allow RULEs ON INSERT, ON UPDATE and ON DELETE iff they generate
only SELECT statements that act INSTEAD OF the actual event. This
affects any read-only transaction, not just hot standby, so I think this
should be discussed and
On Sun, 2009-12-06 at 12:32 +0200, Heikki Linnakangas wrote:
1. The XLogFlush() call you added to dbase_redo doesn't help where it
is. You need to call XLogFlush() after the *commit* record of the DROP
DATABASE. The idea is minimize the window where the files have already
been deleted but the
On Sun, 2009-12-06 at 12:32 +0200, Heikki Linnakangas wrote:
3. The Out of lock mem killer in StandbyAcquireAccessExclusiveLock is
quite harsh. It aborts all read-only transactions. It should be enough
to kill just one random one, or maybe the one that's holding most locks.
Also, if there
On Sun, 2009-12-06 at 11:20 +, Simon Riggs wrote:
On Sun, 2009-12-06 at 12:32 +0200, Heikki Linnakangas wrote:
3. The Out of lock mem killer in StandbyAcquireAccessExclusiveLock is
quite harsh. It aborts all read-only transactions. It should be enough
to kill just one random one, or
On Sun, 2009-12-06 at 10:51 +, Simon Riggs wrote:
5. You removed this comment from KnownAssignedXidsAdd:
- /*
-* XXX: We should check that we don't exceed maxKnownAssignedXids.
-* Even though the hash table might hold a few more entries than that,
-* we use
Simon Riggs wrote:
On Sun, 2009-12-06 at 12:32 +0200, Heikki Linnakangas wrote:
4. Need to handle the case where master is started up with
wal_standby_info=true, shut down, and restarted with
wal_standby_info=false, while the standby server runs continuously. And
the code in StartupXLog() to
On Sun, 2009-12-06 at 20:32 +0200, Heikki Linnakangas wrote:
Simon Riggs wrote:
On Sun, 2009-12-06 at 12:32 +0200, Heikki Linnakangas wrote:
4. Need to handle the case where master is started up with
wal_standby_info=true, shut down, and restarted with
wal_standby_info=false, while the
On Sun, Dec 6, 2009 at 3:06 PM, Simon Riggs si...@2ndquadrant.com wrote:
On Sun, 2009-12-06 at 20:32 +0200, Heikki Linnakangas wrote:
Simon Riggs wrote:
On Sun, 2009-12-06 at 12:32 +0200, Heikki Linnakangas wrote:
4. Need to handle the case where master is started up with
Le 6 déc. 2009 à 23:26, Robert Haas a écrit :
Consider this scenario:
0. You have a master and a standby configured properly, and up and running.
1. You shut down master for some reason.
2. You restart standby. For some reason. Maybe by accident, or you want
to upgrade minor version or
On Sun, 2009-12-06 at 17:26 -0500, Robert Haas wrote:
For what it's worth, this doesn't seem particularly unlikely or
unusual to me.
I don't know many people who shutdown both nodes of a highly available
application at the same time. If they did, I wouldn't expect them to
complain they
13 matches
Mail list logo
