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.
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?
Regards,
Jeff Davis
---------------------------(end of broadcast)---------------------------
TIP 2: Don't 'kill -9' the postmaster
