Re: ANALYZE locks pg_listener in EXCLUSIVE for long
От | Philip Warner |
---|---|
Тема | Re: ANALYZE locks pg_listener in EXCLUSIVE for long |
Дата | |
Msg-id | 6.1.0.6.0.20040503230304.049713f0@203.8.195.10 обсуждение исходный текст |
Ответ на | Re: ANALYZE locks pg_listener in EXCLUSIVE for long (Philip Warner <pjw@rhyme.com.au>) |
Список | pgsql-hackers |
At 07:33 PM 3/05/2004, Philip Warner wrote: >I'll try not to send any more emails until someone responds ;-) I also noticed this in SIInsertDataEntry sinvaladt.c: /* * Try to prevent table overflow. When the table is 70% full send a * WAKEN_CHILDREN request tothe postmaster. The postmaster will send * a SIGUSR2 signal (ordinarily a NOTIFY signal) to all the backends. * This will force idle backends to execute a transaction to look * through pg_listener for NOTIFYmessages, and as a byproduct of the * transaction start they will read SI entries. * * Thisshould never happen if all the backends are actively executing * queries, but if a backend is sitting idle thenit won't be starting * transactions and so won't be reading SI entries. * * dz - 27 Jan 1998 */ Would a long-running ANALYZE (or other activity on a busy database) cause the shared buffers to get to the 70% threshold while doing a long-running ANALYZE? ---------------------------------------------------------------- Philip Warner | __---_____ Albatross Consulting Pty. Ltd. |----/ - \ (A.B.N. 75 008 659 498) | /(@) ______---_ Tel: (+61) 0500 83 82 81 | _________ \ Fax: (+61) 03 5330 3172 | ___________ | Http://www.rhyme.com.au | / \| | --________-- PGP key available upon request, | / and from pgp.mit.edu:11371 |/
В списке pgsql-hackers по дате отправления: