Re: ANALYZE locks pg_listener in EXCLUSIVE for long time? - Mailing list pgsql-hackers

From Zeugswetter Andreas SB SD
Subject Re: ANALYZE locks pg_listener in EXCLUSIVE for long time?
Date
Msg-id 46C15C39FEB2C44BA555E356FBCD6FA40184D0B2@m0114.s-mxs.net
Whole thread Raw
In response to ANALYZE locks pg_listener in EXCLUSIVE for long time?  (Philip Warner <pjw@rhyme.com.au>)
Responses Re: ANALYZE locks pg_listener in EXCLUSIVE for long time?  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
> * Is it really a good idea for database-wide ANALYZE to run as a single
> transaction?  Holding all those locks is a recipe for deadlocks, even
> if they're as inoffensive as AccessShareLocks normally are.

Wasn't one idea behind that change also to not make the planner create a plan
from mixed old and new statistics ? I guess that could later be accomplished with
"begin work; analyze; commit work;" (with subtransactions) though.

Andreas


pgsql-hackers by date:

Previous
From: Andrew Hammond
Date:
Subject: Re: Is there any method to keep table in memory at startup
Next
From: Tom Lane
Date:
Subject: Re: ANALYZE locks pg_listener in EXCLUSIVE for long time?