Re: [RFC] GSoC Work on readonly queries done so far
От | Jeff Davis |
---|---|
Тема | Re: [RFC] GSoC Work on readonly queries done so far |
Дата | |
Msg-id | 1181148899.7660.135.camel@dogma.v10.wvs обсуждение исходный текст |
Ответ на | [RFC] GSoC Work on readonly queries done so far ("Florian G. Pflug" <fgp@phlo.org>) |
Ответы |
Re: [RFC] GSoC Work on readonly queries done so far
|
Список | 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
В списке pgsql-hackers по дате отправления: