Re: [RFC] GSoC Work on readonly queries done so far - Mailing list pgsql-hackers

From Florian G. Pflug
Subject Re: [RFC] GSoC Work on readonly queries done so far
Date
Msg-id 46687121.9000603@phlo.org
Whole thread Raw
In response to Re: [RFC] GSoC Work on readonly queries done so far  (Heikki Linnakangas <heikki@enterprisedb.com>)
List 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



pgsql-hackers by date:

Previous
From: "Simon Riggs"
Date:
Subject: Re: Minor changes to Recovery related code
Next
From: Gregory Stark
Date:
Subject: Re: [COMMITTERS] pgsql: Avoid losing track of data for shared tables in pgstats.