Some 8.4 changes needed according to pg_migrator testing - Mailing list pgsql-hackers

From Tom Lane
Subject Some 8.4 changes needed according to pg_migrator testing
Date
Msg-id 19614.1241712344@sss.pgh.pa.us
Whole thread Raw
Responses Re: Some 8.4 changes needed according to pg_migrator testing  (Alvaro Herrera <alvherre@commandprompt.com>)
Re: Some 8.4 changes needed according to pg_migrator testing  (Tom Lane <tgl@sss.pgh.pa.us>)
Re: Some 8.4 changes needed according to pg_migrator testing  (Bruce Momjian <bruce@momjian.us>)
List pgsql-hackers
I was just talking to Bruce about his results from testing pg_migrator,
and we realized there are a couple of changes that we need to slip into
the core code before 8.4 goes final.

1. pg_dumpall dumps CREATE DATABASE commands that include the source
database's encoding, lc_collate, and lc_ctype settings ... but if
dumping from a pre-8.4 server it just omits the lc_ settings.  This
is flat-out wrong (independently of pg_migrator).  The correct behavior
when dumping from pre-8.4 is to get the server-wide locale settings
and include those in the CREATE DATABASE commands.  Otherwise you're
not restoring the full state of the database correctly.  This is
critical in view of the 8.4 changes to make CREATE DATABASE enforce
encoding-vs-locale match --- if you try to load the dump into a server
with a different default locale, it'll probably fail, and there's
absolutely no reason why it should.

2. There seem to be some corner cases where creating a table in the new
database will not create a toast table even though there was one in the
previous instance.  (I'm not 100% convinced that this can happen if we
create and then drop dropped columns, for instance ... but I'm not
convinced it can't happen, either.)  If there is a toast table in the
old database then pg_migrator must bring it over because it might
possibly contain live data.  However, as toasting.c is presently coded
there is no way to force it to create a toast table.  I think we should
change AlterTableCreateToastTable to add a "bool force" parameter.
Alternatively we could add a separate entry point, but the option seems
a bit cleaner.

Barring objections I'll commit changes for both of these before beta2.
        regards, tom lane


pgsql-hackers by date:

Previous
From: Heikki Linnakangas
Date:
Subject: Re: Re: [BUGS] BUG #4796: Recovery followed by backup creates unrecoverable WAL-file
Next
From: "Kevin Grittner"
Date:
Subject: Re: Serializable Isolation without blocking