Re: Fundamental error in "no WAL log" index/file creation stuff
От | Tom Lane |
---|---|
Тема | Re: Fundamental error in "no WAL log" index/file creation stuff |
Дата | |
Msg-id | 2297.1119740319@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Fundamental error in "no WAL log" index/file creation stuff (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: Fundamental error in "no WAL log" index/file creation stuff
Re: Fundamental error in "no WAL log" index/file creation Re: Fundamental error in "no WAL log" index/file creation stuff |
Список | pgsql-hackers |
I wrote: > It seems our choices are (a) somehow fix things so CREATE DATABASE > replay doesn't have to zap the whole directory, (b) force a checkpoint > immediately after any CREATE DATABASE, so that we never have to replay > one except in a PITR situation, or (c) abandon non-WAL-logged index > and table builds. Having overcome my initial dismay at missing such a fundamental problem, I've thought harder about it and concluded that (b) is clearly the thing to do. I think it would take a wholesale redesign of the CREATE DATABASE mechanism to do (a). While there are a number of ugly things about CREATE DATABASE that could perhaps be fixed with a redesign, I don't currently have any good idea about how to do it right. In any case this path wouldn't be an acceptable backpatch for the 8.0 branch. (c) is clearly not the direction we really wish to take, either. Also, I realized that there is an entirely independent problem that (b) will protect us against. Consider this scenario: create database acopy;\c template1create table bozo(f1 int);-- now system crashes and replays WAL After this sequence it is possible for "acopy" to contain the table "bozo", because the replay of the CREATE DATABASE will copy whatever is on disk in template1. (You can actually duplicate this in 8.0 and HEAD, if you wait long enough for the bgwriter to write the catalog changes, but not long enough for a checkpoint to happen.) Accordingly, I've committed (b) into 8.0 and HEAD. (Earlier branches are not at risk because they didn't WAL-log CREATE DATABASE at all.) This might be sufficient reason to release an 8.0.4 pretty soon. regards, tom lane
В списке pgsql-hackers по дате отправления: