Thread: Re: ANALYZE locks pg_listener in EXCLUSIVE for long

Re: ANALYZE locks pg_listener in EXCLUSIVE for long

From
Philip Warner
Date:
At 06:21 PM 3/05/2004, Philip Warner wrote:
>'tuple concurrently updated'

I lied. The database DO NOT logs show the same error in each case where a 
long delay has occurred. It happens sometimes; recent process logs do show 
the 'async_notify waiting' status, however.

I'll try not to send any more emails until someone responds ;-)



----------------------------------------------------------------
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       |/  



Re: ANALYZE locks pg_listener in EXCLUSIVE for long

From
Philip Warner
Date:
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       |/