| From: | Andres Freund <andres(at)anarazel(dot)de> |
|---|---|
| To: | Fujii Masao <masao(dot)fujii(at)gmail(dot)com> |
| Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Martijn van Oosterhout <kleptog(at)svana(dot)org>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: WAL logging problem in 9.4.3? |
| Date: | 2015-07-03 17:02:29 |
| Message-ID: | 20150703170229.GJ3291@awork2.anarazel.de |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On 2015-07-03 18:49:31 +0200, Andres Freund wrote:
> But the more interesting question is why that's not hhappening
> today. RelationTruncateIndexes() does call the index_build() which
> should end up WAL logging the index creation.
So that's because there's an XLogIsNeeded() preventing it.
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!).
Sure, we do an heap_sync() at the the end of the transaction. That's
nice and all. But it doesn't help if we crash and re-start WAL apply
from a checkpoint before the table was created. Because that'll replay
the truncation.
That's much worse than just the indexes - the rows added by a COPY
without WAL logging will also be truncated away, no?
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Noah Misch | 2015-07-03 17:03:08 | Re: more RLS oversights |
| Previous Message | Alvaro Herrera | 2015-07-03 16:59:07 | Re: Reducing the size of BufferTag & remodeling forks |