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 16:54:59
Message-ID: 1181148899.7660.135.camel@dogma.v10.wvs
Views: Raw Message | Whole Thread | Download mbox
Thread:
Lists: pgsql-hackers

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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Florian G. Pflug 2007-06-06 17:18:45 Re: [RFC] GSoC Work on readonly queries done so far
Previous Message Tom Lane 2007-06-06 16:47:13 Re: elog.c logic bug?