On Wed, 2007-06-06 at 19:25 +0200, Florian G. Pflug wrote:
> 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.
>
That seems like a very minor issue then. It's not unreasonable to expect
that the PITR slave is configured very similarly to the master. You may
even want to require it (if there are other reasons, too).
> 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.
That sounds better than locking out all reads. Perhaps still a warning
in the logs though. If the situation you describe happens, the
administrator probably needs to know about it.
Regards,Jeff Davis