From: | Alvaro Herrera <alvherre(at)2ndquadrant(dot)com> |
---|---|
To: | Jim Nasby <Jim(dot)Nasby(at)BlueTreble(dot)com> |
Cc: | Pg Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Freezing without cleanup lock |
Date: | 2015-10-21 20:14:30 |
Message-ID: | 20151021201429.GZ3391@alvherre.pgsql |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Jim Nasby wrote:
> While warning a client that just did a Slony-based version upgrade to make
> sure to freeze the new database, it occurred to me that it should be safe to
> freeze without the cleanup lock. This is interesting because it would allow
> a scan_all vacuum to do it's job without blocking on the cleanup lock.
>
> Does anyone have a feel for whether scan_all vacuums blocking on the cleanup
> lock is an actual problem?
Yeah, I remember we discussed this and some other possible improvements
related to freezing. I think other ideas proposed were that (1) during
an emergency (uncancellable) autovacuum run, we process only the tables
that are past the age limit, and (2) we remove the cost-based sleep so
that it finishes as quickly as possible. (Yours is (3) only freeze and
not do any actual pruning -- did I get that right?)
--
Álvaro Herrera http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
From | Date | Subject | |
---|---|---|---|
Next Message | Alvaro Herrera | 2015-10-21 20:21:25 | Re: Duplicated assignment of slot_name in walsender.c |
Previous Message | Joe Conway | 2015-10-21 20:06:11 | Re: [BUGS] BUG #13694: Row Level Security by-passed with CREATEUSER permission |