From: | Bruce Momjian <bruce(at)momjian(dot)us> |
---|---|
To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>, Alvaro Herrera <alvherre(at)commandprompt(dot)com>, Jeff Davis <pgsql(at)j-davis(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Patch for pg_upgrade to turn off autovacuum |
Date: | 2011-04-22 21:13:14 |
Message-ID: | 201104222113.p3MLDEx15853@momjian.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Robert Haas wrote:
> On Apr 21, 2011, at 6:22 PM, Bruce Momjian <bruce(at)momjian(dot)us> wrote:
> > Tom Lane wrote:
> >> Bruce Momjian <bruce(at)momjian(dot)us> writes:
> >>> Tom Lane wrote:
> >>>> Huh? Why would that be? Seems like you've done something in the wrong
> >>>> place if that's an issue.
> >>
> >>> Yeah, it is complicated. I don't really care if autovacuum runs on the
> >>> old cluster (we only move the files while the server is down). We only
> >>> want autovacuum not to mess with the relfrozenxids we set on the new
> >>> cluster while the table file is empty.
> >>
> >>> The other issue is that the old alpha binary will not know about the -b
> >>> flag and hence will not start.
> >>
> >> Well, once again, why are you trying to do that? It's not the source
> >> postmaster that needs this flag.
> >
> > Well, consider that this also locks out non-super users so I figured it
> > would be good to run the old and new in the same binary upgrade mode.
> > Again, we can do just the new cluster for 9.1. I can also control the
> > behavior based on the catalog version number, which seems the most
> > logical.
>
> I think you are over-engineering this. Just use it for the new cluster
> only, full stop, and you'll be right as rain.
I thought some more about this and I don't want autovacuum to run on the
old server. This is because pg_dumpall --binary-upgrade --schema-only
grabs the datfrozenxid for all the databases at the start, then connects
to each database to gets the relfrozenxids. I don't want to risk any
advancement of either of those during the pg_dumpall run.
FYI, the existing code already doesn't allow autovacuum to run on the old
or new cluster by setting autovacuum off and autovacuum_freeze_max_age
very high, so this is not a behavior change --- just a more formalized
way of turning off autovacuum.
The attached patch uses catalog version to test; we use catalog version
checking already for tablespace subdirectories.
--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ It's impossible for everything to be true. +
Attachment | Content-Type | Size |
---|---|---|
/rtmp/pg_upgrade | text/x-diff | 17.5 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2011-04-22 21:22:54 | Re: Patch for pg_upgrade to turn off autovacuum |
Previous Message | Greg Smith | 2011-04-22 20:55:30 | Re: fsync reliability |