Re: initdb -S and tablespaces

From: Andres Freund <andres(at)2ndquadrant(dot)com>
To: Abhijit Menon-Sen <ams(at)2ndQuadrant(dot)com>
Cc: Bruce Momjian <bruce(at)momjian(dot)us>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: initdb -S and tablespaces
Date: 2014-09-29 10:59:09
Message-ID: 20140929105909.GE4716@alap3.anarazel.de
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 2014-09-29 15:43:32 +0530, Abhijit Menon-Sen wrote:
> At 2014-09-29 11:54:10 +0200, andres(at)2ndquadrant(dot)com wrote:
> >
> > Note that the perform_fsync() *was* ok for its original purpose in
> > initdb. At the end of initdb there's no relevant tablespaces. But if
> > used *after* pg_upgrade, that's not necessarily the case.
>
> Right.
>
> So, since I'm writing a function to fsync everything inside PGDATA
> anyway, it makes sense to call it both from initdb and StartupXLOG.
> It'll do what initdb -S now does, plus follow links in pg_tblspc.
>
> Any suggestions about where to put such a function? (I was looking at
> backend/utils/init, but I'm not sure that's a good place for this.)

That can't work unfortunately. Both frontend and backend code need to
execute it... I'm not sure it's realistic to handle both cases the
same. The error handling, opening files/directories, and all will be
different. It'll also make backpatching hard :(.

So I'm afraid at least in a first patch it'll need to be a bit of
duplication. Fixing initdb's code back to 9.3 and the backend all the
way back to 9.0.

Greetings,

Andres Freund

--
Andres Freund http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Abhijit Menon-Sen 2014-09-29 11:02:32 Re: initdb -S and tablespaces
Previous Message Andres Freund 2014-09-29 10:50:43 Re: Options OUTPUT_PLUGIN_* controlling format are confusing (Was: Misleading error message in logical decoding)