From: | Philip Warner <pjw(at)rhyme(dot)com(dot)au> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: ANALYZE locks pg_listener in EXCLUSIVE for long |
Date: | 2004-05-03 13:06:38 |
Message-ID: | 6.1.0.6.0.20040503230304.049713f0@203.8.195.10 |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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 to the 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 NOTIFY messages, and as a byproduct of the
* transaction start they will read SI entries.
*
* This should never happen if all the backends are actively executing
* queries, but if a backend is sitting idle then it 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 |/
From | Date | Subject | |
---|---|---|---|
Next Message | Philip Warner | 2004-05-03 13:23:18 | Re: ANALYZE locks pg_listener in EXCLUSIVE for long |
Previous Message | Tom Lane | 2004-05-03 13:04:48 | Re: ANALYZE locks pg_listener in EXCLUSIVE for long time? |