Re: WAL logging problem in 9.4.3?

From: Kyotaro HORIGUCHI <horiguchi(dot)kyotaro(at)lab(dot)ntt(dot)co(dot)jp>
To: michael(dot)paquier(at)gmail(dot)com
Cc: hlinnaka(at)iki(dot)fi, alvherre(at)2ndquadrant(dot)com, simon(at)2ndquadrant(dot)com, tgl(at)sss(dot)pgh(dot)pa(dot)us, andres(at)anarazel(dot)de, masao(dot)fujii(at)gmail(dot)com, kleptog(at)svana(dot)org, pgsql-hackers(at)postgresql(dot)org
Subject: Re: WAL logging problem in 9.4.3?
Date: 2016-03-11 08:32:59
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

Hello, I considered on the original issue.

At Fri, 19 Feb 2016 22:27:00 +0900, Michael Paquier <michael(dot)paquier(at)gmail(dot)com> wrote in <CAB7nPqSGFKUAFqPe5t30jeEA+V9yFMM4yJGa3SnkgY1RHzn7Dg(at)mail(dot)gmail(dot)com>
> > Worth noting that this patch does not address the problem with index
> > relations when a TRUNCATE is used in the same transaction as its

Focusing this issue, what we should do is somehow building empty
index just after a index truncation. The attached patch does the
following things to fix this.

- make index_build use ambuildempty when the relation on which
the index will be built is apparently empty. That is, when the
relation has no block.

- add one parameter "persistent" to ambuildempty(). It behaves as
before if the parameter is false. If not, it creates an empty
index on MAIN_FORK and emits logs even if wal_level is minimal.

Creation of an index for an empty table can be safely done by
ambuildempty, since it creates the image for init fork, which can
be simply copied as main fork on initialization. And the heap is
always empty when RelationTruncateIndexes calls index_build.

For nonempty tables, ambuild properly initializes the new index.

The new parameter 'persistent' would be better be forknum because
it actually represents the persistency of the index to be
created. But I'm out of time now..


Kyotaro Horiguchi
NTT Open Source Software Center

Attachment Content-Type Size
Fix_wal_logging_problem_20160311.patch text/x-patch 13.5 KB

In response to


Browse pgsql-hackers by date

  From Date Subject
Next Message Bruce Momjian 2016-03-11 08:36:45 Re: The plan for FDW-based sharding
Previous Message Craig Ringer 2016-03-11 08:30:13 Re: The plan for FDW-based sharding