Re: [RFC] GSoC Work on readonly queries done so far

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