Re: WAL logging problem in 9.4.3?
От | Andres Freund |
---|---|
Тема | Re: WAL logging problem in 9.4.3? |
Дата | |
Msg-id | 20150703172605.GM3291@awork2.anarazel.de обсуждение исходный текст |
Ответ на | Re: WAL logging problem in 9.4.3? (Andres Freund <andres@anarazel.de>) |
Ответы |
Re: WAL logging problem in 9.4.3?
Re: WAL logging problem in 9.4.3? |
Список | pgsql-hackers |
On 2015-07-03 19:02:29 +0200, Andres Freund wrote: > Maybe I'm just daft right now (35C outside, 32 inside, so ...), but I'm > right now missing how the whole "skip wal logging if relation has just > been truncated" optimization can ever actually be crashsafe unless we > use a new relfilenode (which we don't!). We actually used to use a different relfilenode, but optimized that away: cab9a0656c36739f59277b34fea8ab9438395869 commit cab9a0656c36739f59277b34fea8ab9438395869 Author: Tom Lane <tgl@sss.pgh.pa.us> Date: Sun Aug 23 19:23:41 2009 +0000 Make TRUNCATE do truncate-in-place when processing a relation that was created or previously truncated in the current(sub)transaction. This is safe since if the (sub)transaction later rolls back, we'd just discard the rel's current physical file anyway. This avoids unreasonable growth in the number of transient files when a relation is repeatedlytruncated. Per a performance gripe a couple weeks ago from Todd Cook. to me the reasoning here looks flawed.
В списке pgsql-hackers по дате отправления: