From: | Andres Freund <andres(at)anarazel(dot)de> |
---|---|
To: | Martijn van Oosterhout <kleptog(at)svana(dot)org> |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Fujii Masao <masao(dot)fujii(at)gmail(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: WAL logging problem in 9.4.3? |
Date: | 2015-07-03 17:21:21 |
Message-ID: | 20150703172121.GL3291@awork2.anarazel.de |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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.
From | Date | Subject | |
---|---|---|---|
Next Message | Andres Freund | 2015-07-03 17:26:05 | Re: WAL logging problem in 9.4.3? |
Previous Message | Andres Freund | 2015-07-03 17:16:03 | Re: Reducing the size of BufferTag & remodeling forks |