From: | "Florian G(dot) Pflug" <fgp(at)phlo(dot)org> |
---|---|
To: | Heikki Linnakangas <heikki(at)enterprisedb(dot)com> |
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 20:57:05 |
Message-ID: | 46687121.9000603@phlo.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Heikki Linnakangas wrote:
> 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.
But AFAIK shmem allocation happens before recovery starts... Even if this
was solved, it would only be a partial solution since as you note, the
master might be restarted while the slave keeps running. So I think it's
better not too add too much complexity, and just tell the DBA to increase
max_connections on the slave, together with a comment in the documentation
never to sex max_connections smaller on the slave than on the master.
greetings, Florian Pflug
From | Date | Subject | |
---|---|---|---|
Next Message | Gregory Stark | 2007-06-07 21:07:03 | Re: [COMMITTERS] pgsql: Avoid losing track of data for shared tables in pgstats. |
Previous Message | Joshua D. Drake | 2007-06-07 20:56:14 | Re: Controlling Load Distributed Checkpoints |