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. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
