| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | "Zeugswetter Andreas SB SD" <ZeugswetterA(at)spardat(dot)at> |
| Cc: | "Philip Warner" <pjw(at)rhyme(dot)com(dot)au>, "PostgreSQL-development" <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: ANALYZE locks pg_listener in EXCLUSIVE for long time? |
| Date: | 2004-05-03 15:19:57 |
| Message-ID: | 13569.1083597597@sss.pgh.pa.us |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
"Zeugswetter Andreas SB SD" <ZeugswetterA(at)spardat(dot)at> writes:
>> * 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 don't recall that that was part of the discussion. IIRC all we were
after was to let someone invoke ANALYZE from inside a BEGIN/COMMIT block.
A possible compromise is to hack ANALYZE so that if it is invoked when
*not* within a BEGIN block, it runs a separate transaction for each
table. This seems pretty crufty but might satisfy all the requirements.
> I guess that could later be accomplished with
> "begin work; analyze; commit work;" (with subtransactions) though.
AFAICS, locks taken by a (committed) subtransaction can't be released
until top-level commit anyhow. Otherwise they fail to perform one of
the essential functions of locking in an MVCC environment: to delay
another process until the changes you've made are visible to him.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2004-05-03 15:30:06 | Re: ANALYZE locks pg_listener in EXCLUSIVE for long time? |
| Previous Message | Zeugswetter Andreas SB SD | 2004-05-03 15:15:08 | Re: ANALYZE locks pg_listener in EXCLUSIVE for long time? |