Jeff Davis wrote:
On Wed, 2007-06-06 at 16:11 +0200, Florian G. Pflug wrote:
.) Since the slaves needs to track an Snapshot in shared memory, it cannot
resize that snapshot to accomodate however many concurrent transactions
might have been running on the master. My current plan is to detect if
that global snapshot overflows, and to lock out readonly queries on the
slave (and therefore remove the need of keeping the snapshot current)
until the number of active xids on the master has dropped below
max_connections on the slave. A warning will be written to the postgres
log that suggest that the DBA increases the max_connections value on
the slave.
If we did lock the slave while waiting for transactions to complete on
the master, we'd need to document some stronger warnings against idle
transactions so that administrators could notice and correct the
problem.
It's not exactly locking until it complete on the master, it's locking
the slave until we reach a position in the wal on the slave with less
than max_connections concurrent transactions. But yes, I agree, this
will need to be documented.
Are you referring to the size of the xip array being a problem? Would it
help to tie the size of the xip array to max_connections? I understand
that max_connections might be greater on the master, but maybe something
similar?
Thats what I currently do - the xip array on the slave is sized to
hold max_connections entries (Actually, it's max_connections +
max_prepared_xacts I think). The problem occurs exactly if those
values are set too small on the slave - and since shared mem
objects are not resizeable, I don't see how the slave can handle
an xip overflow gracefully other than by not publishing the
information in shared memory as long as it doesn't fit there.
On a further thinking - maybe locking out transactions isn't even
necessary - they would just continue to see the old global snapshot,
so time wouldn't advance for them until the number of concurrent
transactions decreases again.
greetings, Florian Pflug
---------------------------(end of broadcast)---------------------------
TIP 7: You can help support the PostgreSQL project by donating at
http://www.postgresql.org/about/donate
