| 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: | Whole Thread | Raw Message | 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 |