Re: Fixing flat user/group files at database startup

From: Alvaro Herrera <alvherre(at)dcc(dot)uchile(dot)cl>
To: pgsql-hackers(at)postgresql(dot)org
Subject: Re: Fixing flat user/group files at database startup
Date: 2005-02-05 01:40:51
Message-ID: 20050205014051.GB11973@dcc.uchile.cl
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Sorry, hit the wrong key.

----- Forwarded message from Alvaro Herrera <alvherre(at)dcc(dot)uchile(dot)cl> -----

Date: Fri, 4 Feb 2005 22:39:11 -0300
From: Alvaro Herrera <alvherre(at)dcc(dot)uchile(dot)cl>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Subject: Re: [HACKERS] Fixing flat user/group files at database startup

On Fri, Feb 04, 2005 at 03:16:33PM -0500, Tom Lane wrote:
> 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 thought that maybe we could reconstruct the file using the previous
file and the WAL entry, but then I noticed that we don't emit a special
WAL entry for user create/delete/update, so this would also require a
lot of new code.

> 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.

If you make something similar to GetRawDatabaseInfo, then you don't need
the plain files at all, do you? By doing that, a lot of code could go
away.

> But going in this direction would require writing a fair amount of new
> code, probably too much to consider backpatching into 8.0.*.

If you don't backport this into 8.0, then 8.0 will be broken forever?
The special-backend solution does not really seem a lot better, and it
doesn't seem less code either.

--
Alvaro Herrera (<alvherre[(at)]dcc(dot)uchile(dot)cl>)
"Para tener más hay que desear menos"

----- End forwarded message -----
--
Alvaro Herrera (<alvherre[(at)]dcc(dot)uchile(dot)cl>)
La web junta la gente porque no importa que clase de mutante sexual seas,
tienes millones de posibles parejas. Pon "buscar gente que tengan sexo con
ciervos incendiándose", y el computador dirá "especifique el tipo de ciervo"
(Jason Alexander)

Browse pgsql-hackers by date

  From Date Subject
Next Message Bruce Momjian 2005-02-05 02:12:35 Re: Patch Count?
Previous Message Josh Berkus 2005-02-05 01:38:23 Re: Patch Count?