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 по дате отправления: