| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Jeff Davis <pgsql(at)j-davis(dot)com> |
| Cc: | Robert Haas <robertmhaas(at)gmail(dot)com>, Simon Riggs <simon(at)2ndquadrant(dot)com>, Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>, Josh Berkus <josh(at)agliodbs(dot)com>, pgsql-hackers(at)postgresql(dot)org |
| Subject: | Re: Feedback on getting rid of VACUUM FULL |
| Date: | 2009-09-17 03:12:46 |
| Message-ID: | 5317.1253157166@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Jeff Davis <pgsql(at)j-davis(dot)com> writes:
> On Wed, 2009-09-16 at 21:48 -0400, Tom Lane wrote:
>> Yeah, I was just wondering about that myself. Seems like there would
>> be lots of situations where short exclusive-lock intervals could be
>> tolerated, even though not long ones.
> But a short-lived exclusive lock can turn into a long-lived exclusive
> lock if there are long-lived transactions ahead of it in the queue. We
> probably don't want to automate anything by default that acquires
> exclusive locks, even for a short time. However, I agree that it's fine
> in many situations if the administrator is choosing it.
Right, which is why autovacuum can't have anything to do with this.
But as an emergency recovery tool it seems reasonable enough.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Emmanuel Cecchet | 2009-09-17 03:19:58 | Re: generic copy options |
| Previous Message | Jeff Davis | 2009-09-17 03:07:28 | Re: Feedback on getting rid of VACUUM FULL |