Re: WAL logging problem in 9.4.3?

Andres Freund <andres@anarazel.de>

From: Andres Freund <andres@anarazel.de>
To: Fujii Masao <masao.fujii@gmail.com>
Cc: Tom Lane <tgl@sss.pgh.pa.us>, Martijn van Oosterhout <kleptog@svana.org>, PostgreSQL-development <pgsql-hackers@postgresql.org>
Date: 2015-07-03T17:26:05Z
Lists: 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 repeatedly truncated.  Per a performance
    gripe a couple weeks ago from Todd Cook.

to me the reasoning here looks flawed.


Commits

  1. Add perl2host call missing from a new test file.

  2. Skip WAL for new relfilenodes, under wal_level=minimal.

  3. Revert "Skip WAL for new relfilenodes, under wal_level=minimal."

  4. Back-patch log_newpage_range().

  5. During heap rebuild, lock any TOAST index until end of transaction.

  6. In log_newpage_range(), heed forkNum and page_std arguments.

  7. Back-patch src/test/recovery and PostgresNode from 9.6 to 9.5.

  8. Reduce pg_ctl's reaction time when waiting for postmaster start/stop.

  9. Accelerate end-of-transaction dropping of relations

  10. Redesign the planner's handling of index-descent cost estimation.

  11. Make TRUNCATE do truncate-in-place when processing a relation that was created