Re: Sigh, we need an initdb - Mailing list pgsql-hackers

From Andres Freund
Subject Re: Sigh, we need an initdb
Date
Msg-id 20140604205220.GE785@awork2.anarazel.de
Whole thread Raw
In response to Sigh, we need an initdb  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Sigh, we need an initdb  (Tom Lane <tgl@sss.pgh.pa.us>)
Re: Sigh, we need an initdb  (Greg Stark <stark@mit.edu>)
List pgsql-hackers
Hi,

On 2014-06-04 14:52:35 -0400, Tom Lane wrote:
> I think we could possibly ship 9.4 without fixing this, but it would be
> imprudent.  Anyone think differently?

Agreed. Additionally I also agree with Stefan that the price of a initdb
during beta isn't that high these days.

> Of course, if we do fix this then the door opens for pushing other
> initdb-forcing fixes into 9.4beta2, such as the LOBLKSIZE addition
> that I was looking at when I noticed this, or the pg_lsn catalog
> additions that were being discussed a couple weeks ago.

Other things I'd like to change in that case:

* rename pg_replication_slots.xmin to something else. After the replication slot patch went in, in another patch's
reviewyou/Tom objected that xmin isn't the best name. The only problem being that I still don't have a better idea than
myoriginal 'data_xmin' which Robert disliked.
 

* Standardize on either slot_name for the replication slot's name. Currently some functions have a parameter named
'slotname'but all columnnames (from SRFs) are slot_name. That's not really bad since the parameter names don't really
meanmuch, but if we can we should fix it imo.
 

Greetings,

Andres Freund

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



pgsql-hackers by date:

Previous
From: Andrew Dunstan
Date:
Subject: Re: Sigh, we need an initdb
Next
From: Tom Lane
Date:
Subject: Re: Sigh, we need an initdb