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

From: Jeff Davis <pgsql(at)j-davis(dot)com>
To: "Florian G(dot) Pflug" <fgp(at)phlo(dot)org>
Cc: Postgresql-Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: [RFC] GSoC Work on readonly queries done so far
Date: 2007-06-06 18:24:41
Message-ID: 1181154281.7660.147.camel@dogma.v10.wvs
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Greg Smith 2007-06-06 18:26:11 Re: Controlling Load Distributed Checkpoints
Previous Message Greg Smith 2007-06-06 18:05:35 Re: Controlling Load Distributed Checkpoints