Bruce Momjian wrote:
Well, having seen no replies, I am going to apply the version of the
patch in a few days that keeps the old vacuum-disable behavior for older
releases, and uses the -b flag for newer ones by testing the catalog
version, e.g.:
snprintf(cmd, sizeof(cmd),
Bruce Momjian wrote:
Bruce Momjian wrote:
Tom Lane wrote:
Bruce Momjian br...@momjian.us writes:
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
Robert Haas wrote:
On Apr 21, 2011, at 6:22 PM, Bruce Momjian br...@momjian.us wrote:
Tom Lane wrote:
Bruce Momjian br...@momjian.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
Bruce Momjian br...@momjian.us writes:
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
Bruce Momjian wrote:
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
Tom Lane wrote:
Bruce Momjian br...@momjian.us writes:
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
On Fri, 2011-04-22 at 17:34 -0400, Bruce Momjian wrote:
Tom Lane wrote:
Bruce Momjian br...@momjian.us writes:
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
Jeff Davis wrote:
On Fri, 2011-04-22 at 17:34 -0400, Bruce Momjian wrote:
Tom Lane wrote:
Bruce Momjian br...@momjian.us writes:
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
Bruce Momjian wrote:
Tom Lane wrote:
Bruce Momjian br...@momjian.us writes:
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
Bruce Momjian wrote:
Robert Haas wrote:
On Thu, Mar 31, 2011 at 12:11 PM, Bruce Momjian br...@momjian.us wrote:
Robert Haas wrote:
On Thu, Mar 31, 2011 at 11:32 AM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
?I think the maintenance
overhead of an invisible
Bruce Momjian wrote:
Bruce Momjian wrote:
Robert Haas wrote:
On Thu, Mar 31, 2011 at 12:11 PM, Bruce Momjian br...@momjian.us wrote:
Robert Haas wrote:
On Thu, Mar 31, 2011 at 11:32 AM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
?I think the maintenance
Bruce Momjian br...@momjian.us writes:
The attached patch adds a new postmaster/postgres binary upgrade mode
(-b) which disables autovacuum, allows only super-user connections, and
prevents pg_upgrade_support oid assignment when not in upgrade mode.
It also modifies pg_upgrade to use this new
Tom Lane wrote:
Bruce Momjian br...@momjian.us writes:
The attached patch adds a new postmaster/postgres binary upgrade mode
(-b) which disables autovacuum, allows only super-user connections, and
prevents pg_upgrade_support oid assignment when not in upgrade mode.
It also modifies
Bruce Momjian br...@momjian.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
Tom Lane wrote:
Bruce Momjian br...@momjian.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
On Thu, 2011-04-21 at 18:22 -0400, Bruce Momjian wrote:
I can also control the
behavior based on the catalog version number, which seems the most
logical.
It seems like we want a simple use -b if available; else don't. Is
that right?
If so, switching based on the version seems reasonable.
On Apr 21, 2011, at 6:22 PM, Bruce Momjian br...@momjian.us wrote:
Tom Lane wrote:
Bruce Momjian br...@momjian.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
17 matches
Mail list logo
