I just noticed that we had not one, but two commits in 9.4 that added
fields to pg_control. And neither one changed PG_CONTROL_VERSION.
This is inexcusable sloppiness on the part of the committers involved,
but the question is what do we do now?
Quick experimentation says that you don't really
On 06/04/2014 11:52 AM, Tom Lane wrote:
I think we could possibly ship 9.4 without fixing this, but it would be
imprudent. Anyone think differently?
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
On 06/04/2014 08:56 PM, Joshua D. Drake wrote:
On 06/04/2014 11:52 AM, Tom Lane wrote:
I think we could possibly ship 9.4 without fixing this, but it would be
imprudent. Anyone think differently?
Of course, if we do fix this then the door opens for pushing other
initdb-forcing fixes
On Jun 4, 2014 8:52 PM, Tom Lane t...@sss.pgh.pa.us wrote:
I just noticed that we had not one, but two commits in 9.4 that added
fields to pg_control. And neither one changed PG_CONTROL_VERSION.
This is inexcusable sloppiness on the part of the committers involved,
but the question is what
On Wed, Jun 4, 2014 at 2:52 PM, Tom Lane t...@sss.pgh.pa.us wrote:
I just noticed that we had not one, but two commits in 9.4 that added
fields to pg_control. And neither one changed PG_CONTROL_VERSION.
This is inexcusable sloppiness on the part of the committers involved,
but the question is
Robert Haas wrote
On Wed, Jun 4, 2014 at 2:52 PM, Tom Lane lt;
tgl@.pa
gt; wrote:
I just noticed that we had not one, but two commits in 9.4 that added
fields to pg_control. And neither one changed PG_CONTROL_VERSION.
This is inexcusable sloppiness on the part of the committers involved,
On 06/04/2014 03:50 PM, Robert Haas wrote:
On Wed, Jun 4, 2014 at 2:52 PM, Tom Lane t...@sss.pgh.pa.us wrote:
I just noticed that we had not one, but two commits in 9.4 that added
fields to pg_control. And neither one changed PG_CONTROL_VERSION.
This is inexcusable sloppiness on the part of
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
Andres Freund and...@2ndquadrant.com writes:
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
On Wed, Jun 4, 2014 at 9:52 PM, Andres Freund and...@2ndquadrant.com wrote:
Other things I'd like to change in that case:
Fwiw I tried to use the pg_lsn data type the other day and pretty much
immediately ran into the lack of the btree operator class. Pretty much
the first thing I did when I
On 2014-06-04 17:03:52 -0400, Tom Lane wrote:
Actually, that statement makes me realize that if we fix
PG_CONTROL_VERSION then it's a good idea to *also* do some regular catalog
changes, or at least bump catversion. Otherwise pg_upgrade won't be able to
cope with upgrading non-default
Greg Stark st...@mit.edu writes:
Fwiw I tried to use the pg_lsn data type the other day and pretty much
immediately ran into the lack of the btree operator class. Pretty much
the first thing I did when I loaded the data was select ... order by
lsn.
Agreed, now that we're going to force an
On Wed, Jun 04, 2014 at 09:16:36PM +0200, Stefan Kaltenbrunner wrote:
On 06/04/2014 08:56 PM, Joshua D. Drake wrote:
On 06/04/2014 11:52 AM, Tom Lane wrote:
I think we could possibly ship 9.4 without fixing this, but it would be
imprudent. Anyone think differently?
Of course, if we do
On Wed, Jun 4, 2014 at 4:37 PM, Andrew Dunstan and...@dunslane.net wrote:
On 06/04/2014 03:50 PM, Robert Haas wrote:
On Wed, Jun 4, 2014 at 2:52 PM, Tom Lane t...@sss.pgh.pa.us wrote:
I just noticed that we had not one, but two commits in 9.4 that added
fields to pg_control. And neither one
Robert Haas robertmh...@gmail.com writes:
On Wed, Jun 4, 2014 at 4:37 PM, Andrew Dunstan and...@dunslane.net wrote:
I agree it's scary but in a few minutes thinking about it I haven't been
able to come up with a good way of checking it. Maybe we could build
sizeof(ControlData) into the version
I wrote:
Robert Haas robertmh...@gmail.com writes:
I think that's worth considering. Another idea is: suppose we set up
a PostgreSQL database somewhere that contained information about what
controldata layout corresponded to what control version:
That seems possibly workable.
BTW, a
Stefan Kaltenbrunner wrote
On 06/04/2014 08:56 PM, Joshua D. Drake wrote:
On 06/04/2014 11:52 AM, Tom Lane wrote:
I think we could possibly ship 9.4 without fixing this, but it would be
imprudent. Anyone think differently?
Of course, if we do fix this then the door opens for pushing
David G Johnston david.g.johns...@gmail.com writes:
If we are planning on keeping this rule, which it seems like at least a few
people feel is too stringent, maybe we can consider releasing an Alpha
version and communicate the expectation that an initdb will be required to
go from the alpha to
18 matches
Mail list logo
