Re: Advice on MyXactMade* flags, MyLastRecPtr, pendingDeletes and lazy XID assignment
От | Florian G. Pflug |
---|---|
Тема | Re: Advice on MyXactMade* flags, MyLastRecPtr, pendingDeletes and lazy XID assignment |
Дата | |
Msg-id | 46D6B86C.1040203@phlo.org обсуждение исходный текст |
Ответ на | Re: Advice on MyXactMade* flags, MyLastRecPtr, pendingDeletes and lazy XID assignment (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: Advice on MyXactMade* flags, MyLastRecPtr, pendingDeletes and lazy XID assignment
Re: Advice on MyXactMade* flags, MyLastRecPtr, pendingDeletes and lazy XID assignment |
Список | pgsql-hackers |
Tom Lane wrote: > "Florian G. Pflug" <fgp@phlo.org> writes: >> And I'm quite tempted to not flush the XLOG at all during ABORT, and to >> only force synchronous commits if one of the to-be-deleted files is >> non-temporary. > > +1 on the first, but -1 on the second, because we'd have to track > whether deleted files are temp or not ... it's very unclear that it'd > be worth the trouble. I'm confused. smgrcreate already tracks if it created a file for a temp relation or not (at least it has an isTemp parameter, which it also stores in the delete list). I'd have thought the second suggestion would amount to a few lines of code in smgrGetPendingDeletes to let it report if all pending deletes carried the isTemp flag or not. >>> The only way we could make this more robust is if we could have >>> WAL-before-data rule for file *creation*, but I think that's not >>> possible given that we don't know what relfilenode number we will use >>> until we've successfully created a file. > >> It seems doable, but it's not pretty. One possible scheme would be to >> emit a record *after* chosing a name but *before* creating the file, > > No, because the way you know the name is good is a successful > open(O_CREAT). The idea was to log *twice*. Once the we're about to create a file, and the second time that we succeeded. That way, the filename shows up in the log, even if we crash immediatly after physically creating the file, which gives recovery at least a chance to clean up the mess. greetings, Florian Pflug
В списке pgsql-hackers по дате отправления: