Michael Klatt reported here:
http://archives.postgresql.org/pgsql-admin/2005-02/msg00031.php
that we have problems because the flat files global/pg_pwd
and global/pg_group aren't rebuilt following WAL recovery.
This has in fact been a bug since we created WAL, although it's
certainly far worse in the context of PITR because the window in
which the files can get out of sync is far wider.
I've been investigating fixing this and it seems like a bit of a mess,
because reading pg_shadow and pg_group in the normal way pretty much
requires having the full backend environment, which is most definitely
not available in the bootstrap-like context that WAL recovery runs in.
Short of writing another kluge like GetRawDatabaseInfo(), it seems like
the only clean solution is to have the postmaster launch a special
backend just after the startup process completes. Even that isn't super
clean, because of the problem of choosing what database the special
backend should attach to. I don't much like the idea that the database
will fail to start up if template1 isn't there :-( Maybe we could hack
it to connect to template0 instead, but that's only marginally better.
(Yes, Virginia, you can drop template0 too.)
One idea I'm toying with is to try to make something like
GetRawDatabaseInfo but not as klugy. The principal reason that
GetRawDatabaseInfo is an intolerable hack is that it can't verify the
commit states of transactions. Now that limitation was written into it
back when pg_log was an ordinary relation and we didn't have any special
infrastructure for getting at it (so you needed most of the backend up
before you could look at pg_log). I think that the clog/subtrans/slru
mechanisms might work well enough in the startup environment to be used
to examine transaction commit results. But going in this direction
would require writing a fair amount of new code, probably too much to
consider backpatching into 8.0.*.
Anybody see a cleaner solution? Or at least other ideas to consider?
regards, tom lane
