Skip site navigation (1) Skip section navigation (2)

Re: initdb -S and tablespaces

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Abhijit Menon-Sen <ams(at)2ndquadrant(dot)com>
Cc: Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, Andres Freund <andres(at)2ndquadrant(dot)com>, Bruce Momjian <bruce(at)momjian(dot)us>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: initdb -S and tablespaces
Date: 2015-05-01 13:57:28
Message-ID: CA+TgmoZ_ZAGLt7QB9tmYN3-htVPJe_qvyrqogWg-J2O8hPHS0w@mail.gmail.com (view raw, whole thread or download thread mbox)
Thread:
Lists: pgsql-hackers
On Fri, May 1, 2015 at 8:42 AM, Abhijit Menon-Sen <ams(at)2ndquadrant(dot)com> wrote:
> At 2015-05-01 08:10:16 -0400, robertmhaas(at)gmail(dot)com wrote:
>> It seems to me that, at a minimum, it would be good to split those
>> controversial and definitely not-back-patchable changes into their
>> own patch.
>
> OK, split here (0002*).
>
>> I do mind putting it into xlog.c instead of some place that's actually
>> appropriate.
>
> OK, moved to storage/file/fd.c (0001*).

Here's a revised version of your 0001 patch which I am comfortable
with.  I changed some of the comments, and I moved the fsync_pgdata()
call slightly later, so that we don't do a (possibly long) set of
fsyncs before printing out the first log message that tells the user
what is going on.

If you don't object to this version, I'll commit it.  I believe this
part *should* be back-patched, but Tom seemed to disagree, for reasons
I'm not really clear on.  This is a potential data corrupting bug as
legitimate as any other, so a back-patch seems right to me.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

Attachment: fsync-pgdata-rmh.patch
Description: binary/octet-stream (5.7 KB)

In response to

Responses

pgsql-hackers by date

Next:From: Andres FreundDate: 2015-05-01 13:58:00
Subject: Re: INSERT ... ON CONFLICT UPDATE/IGNORE 4.0
Previous:From: Robert HaasDate: 2015-05-01 13:40:53
Subject: Re: cache invalidation for PL/pgsql functions

Privacy Policy | About PostgreSQL
Copyright © 1996-2018 The PostgreSQL Global Development Group