Re: pgsql-server: Add: > > * Allow buffered WAL writes
От | Tom Lane |
---|---|
Тема | Re: pgsql-server: Add: > > * Allow buffered WAL writes |
Дата | |
Msg-id | 7633.1092521110@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: pgsql-server: Add: > > * Allow buffered WAL writes ("Marc G. Fournier" <scrappy@postgresql.org>) |
Ответы |
Re: pgsql-server: Add: > > * Allow buffered WAL writes
|
Список | pgsql-committers |
"Marc G. Fournier" <scrappy@postgresql.org> writes: > One question, more directed to Tom here ... since they are seperate right > now, if WAL is fsync, and "regular writing" is no-fsync, doesn't that > potentially open us up to some *serious* problems? WAL sees the > transaction as complete, but the write for the rest of the system hasn't > happened yet? No, that's pretty much the whole point of WAL: once you've fsynced the transaction's log entries to WAL, it's committed. You don't have to fsync the data-file writes, or even write the changes out at all. (In most cases the pages stay in shared buffer cache, dirty, until the background writer gets to them.) If you crash then the data-file changes will get redone by replaying the WAL entries. You do have to fsync data-file writes when trying to complete a checkpoint, but that's outside the critical path for normal transactions. One of the reasons I dislike Bruce's proposal is that I don't think it pays any attention to this basic duality between normal operations (fsync WAL) and checkpoints (fsync data). We just finished finding a long-standing bug in this area, so I'm pretty hesitant to whack it around on the basis of unproven ideas about performance improvements. regards, tom lane
В списке pgsql-committers по дате отправления: