Re: WAL logging problem in 9.4.3?
От | Andres Freund |
---|---|
Тема | Re: WAL logging problem in 9.4.3? |
Дата | |
Msg-id | 20150703172121.GL3291@awork2.anarazel.de обсуждение исходный текст |
Ответ на | Re: WAL logging problem in 9.4.3? (Martijn van Oosterhout <kleptog@svana.org>) |
Ответы |
Re: WAL logging problem in 9.4.3?
|
Список | pgsql-hackers |
On 2015-07-03 19:14:26 +0200, Martijn van Oosterhout wrote: > Am I missing something. ISTM that if the truncate record was simply not > logged at all everything would work fine. The whole point is that the > table was created in this transaction and so if it exists the table on > disk must be the correct representation. That'd not work either. Consider: BEGIN; CREATE TABLE ... INSERT; TRUNCATE; INSERT; COMMIT; If you replay that without a truncation wal record the second INSERT will try to add stuff to already occupied space. And they can have different lengths and stuff, so you cannot just ignore that fact. > The broken index is just one symptom. Agreed. I think the problem is something else though. Namely that we reuse the relfilenode for heap_truncate_one_rel(). That's just entirely broken afaics. We need to allocate a new relfilenode and write stuff into that. Then we can forgo WAL logging the truncation record. > If you insert a row before commit then after replay the tuple should be there still. The insert would be WAL logged. COPY skips wal logging tho.
В списке pgsql-hackers по дате отправления: