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

From: Heikki Linnakangas <heikki(at)enterprisedb(dot)com>
To: "Florian G(dot) Pflug" <fgp(at)phlo(dot)org>
Cc: Jeff Davis <pgsql(at)j-davis(dot)com>, Postgresql-Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: [RFC] GSoC Work on readonly queries done so far
Date: 2007-06-07 10:29:52
Message-ID: 4667DE20.7020101@enterprisedb.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Florian G. Pflug wrote:
> Jeff Davis wrote:
>> 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.

You could store the value of max_connections in the checkpoint xlog
record, and read it from there in the slave. Though one could still
change it on the master and restart without restarting the slave as well.

--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Magnus Hagander 2007-06-07 10:44:04 Re: How do we create the releases?
Previous Message Hannu Krosing 2007-06-07 09:28:03 Re: Controlling Load Distributed Checkpoints