Re: Fixing flat user/group files at database startup

Поиск
Список
Период
Сортировка
От Alvaro Herrera
Тема Re: Fixing flat user/group files at database startup
Дата
Msg-id 20050205014051.GB11973@dcc.uchile.cl
обсуждение исходный текст
Ответ на Fixing flat user/group files at database startup  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
Sorry, hit the wrong key.

----- Forwarded message from Alvaro Herrera <alvherre@dcc.uchile.cl> -----

Date: Fri, 4 Feb 2005 22:39:11 -0300
From: Alvaro Herrera <alvherre@dcc.uchile.cl>
To: Tom Lane <tgl@sss.pgh.pa.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[@]dcc.uchile.cl>)
"Para tener más hay que desear menos"

----- End forwarded message -----
-- 
Alvaro Herrera (<alvherre[@]dcc.uchile.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)


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Josh Berkus
Дата:
Сообщение: Re: Patch Count?
Следующее
От: Bruce Momjian
Дата:
Сообщение: Re: Patch Count?