Re: pg_control is missing a field for LOBLKSIZE

I just chanced to notice that if someone were to change the value for
LOBLKSIZE and recompile, there'd be nothing to stop him from starting
that postmaster against an existing database, even though it would
completely misinterpret and mangle any data in pg_largeobject.

I think there ought to be a guard for that, for exactly the same reasons
that we check TOAST_MAX_CHUNK_SIZE: correct interpretation of on-disk
data requires that this value match the original database configuration.

Obviously it's too late to do anything about this in existing branches,
but I propose to add a field to pg_control after we branch off 9.4.

regards, tom lane

On 06/04/2014 10:03 AM, Tom Lane wrote:
> I just chanced to notice that if someone were to change the value for
> LOBLKSIZE and recompile, there'd be nothing to stop him from starting
> that postmaster against an existing database, even though it would
> completely misinterpret and mangle any data in pg_largeobject.
>
> I think there ought to be a guard for that, for exactly the same reasons
> that we check TOAST_MAX_CHUNK_SIZE: correct interpretation of on-disk
> data requires that this value match the original database configuration.
>
> Obviously it's too late to do anything about this in existing branches,
> but I propose to add a field to pg_control after we branch off 9.4.
>
>

If we did an initdb-requiring change for 9.4 could we piggy-back this
onto it?

cheers

andrew

On 2014-06-04 10:25:07 -0400, Andrew Dunstan wrote:
> If we did an initdb-requiring change for 9.4 could we piggy-back this onto
> it?

Do you know of a problem requiring that?

Greetings,

Andres Freund

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

* Andrew Dunstan (andrew(at)dunslane(dot)net) wrote:
> On 06/04/2014 10:03 AM, Tom Lane wrote:
> >I just chanced to notice that if someone were to change the value for
> >LOBLKSIZE and recompile, there'd be nothing to stop him from starting
> >that postmaster against an existing database, even though it would
> >completely misinterpret and mangle any data in pg_largeobject.
> >
> >I think there ought to be a guard for that, for exactly the same reasons
> >that we check TOAST_MAX_CHUNK_SIZE: correct interpretation of on-disk
> >data requires that this value match the original database configuration.
> >
> >Obviously it's too late to do anything about this in existing branches,
> >but I propose to add a field to pg_control after we branch off 9.4.
> >
> >
>
> If we did an initdb-requiring change for 9.4 could we piggy-back
> this onto it?

I was thinking more-or-less the same thing...

Then again, I've never heard of a field complaint regarding this, so
pehraps it's not worth it.

Thanks,

Stephen

On 06/04/2014 10:27 AM, Andres Freund wrote:
> On 2014-06-04 10:25:07 -0400, Andrew Dunstan wrote:
>> If we did an initdb-requiring change for 9.4 could we piggy-back this onto
>> it?
> Do you know of a problem requiring that?
>

No, just thinking ahead.

cheers

andrew

Stephen Frost <sfrost(at)snowman(dot)net> writes:
> * Andrew Dunstan (andrew(at)dunslane(dot)net) wrote:
>> On 06/04/2014 10:03 AM, Tom Lane wrote:
>>> I just chanced to notice that if someone were to change the value for
>>> LOBLKSIZE and recompile, there'd be nothing to stop him from starting
>>> that postmaster against an existing database, even though it would
>>> completely misinterpret and mangle any data in pg_largeobject.

> Then again, I've never heard of a field complaint regarding this, so
> pehraps it's not worth it.

I've not heard one either, but there was just somebody asking in
pgsql-general about changing LOBLKSIZE, so he's going to be at risk.
That's not a big enough sample size to make me panic about getting a
hasty fix into 9.4, but I do think we should fix this going forward.

regards, tom lane

* Tom Lane (tgl(at)sss(dot)pgh(dot)pa(dot)us) wrote:
> Stephen Frost <sfrost(at)snowman(dot)net> writes:
> > * Andrew Dunstan (andrew(at)dunslane(dot)net) wrote:
> >> On 06/04/2014 10:03 AM, Tom Lane wrote:
> >>> I just chanced to notice that if someone were to change the value for
> >>> LOBLKSIZE and recompile, there'd be nothing to stop him from starting
> >>> that postmaster against an existing database, even though it would
> >>> completely misinterpret and mangle any data in pg_largeobject.
>
> > Then again, I've never heard of a field complaint regarding this, so
> > pehraps it's not worth it.
>
> I've not heard one either, but there was just somebody asking in
> pgsql-general about changing LOBLKSIZE, so he's going to be at risk.
> That's not a big enough sample size to make me panic about getting a
> hasty fix into 9.4, but I do think we should fix this going forward.

Agreed.

Thanks,

Stephen

On 2014-06-04 10:03:09 -0400, Tom Lane wrote:
> I just chanced to notice that if someone were to change the value for
> LOBLKSIZE and recompile, there'd be nothing to stop him from starting
> that postmaster against an existing database, even though it would
> completely misinterpret and mangle any data in pg_largeobject.
>
> I think there ought to be a guard for that, for exactly the same reasons
> that we check TOAST_MAX_CHUNK_SIZE: correct interpretation of on-disk
> data requires that this value match the original database configuration.
>
> Obviously it's too late to do anything about this in existing branches,
> but I propose to add a field to pg_control after we branch off 9.4.

Btw, I had wondered before if we shouldn't also add sizeof(long) to
pg_control to catch cases where a database is copied between a LLP64
(64bit windows) and an LP64 (nearly every other 64bit system) system. I
have my doubts that we're completely clean about the size
difference. Not to speak of extension datatypes.

Greetings,

Andres Freund

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

Andres Freund <andres(at)2ndquadrant(dot)com> writes:
> Btw, I had wondered before if we shouldn't also add sizeof(long) to
> pg_control to catch cases where a database is copied between a LLP64
> (64bit windows) and an LP64 (nearly every other 64bit system) system. I
> have my doubts that we're completely clean about the size
> difference. Not to speak of extension datatypes.

I don't believe that this is necessary. It's certainly true that some
in-memory structures will be laid out differently, but not on-disk.

regards, tom lane

Stephen Frost <sfrost(at)snowman(dot)net> writes:
> * Tom Lane (tgl(at)sss(dot)pgh(dot)pa(dot)us) wrote:
>> I've not heard one either, but there was just somebody asking in
>> pgsql-general about changing LOBLKSIZE, so he's going to be at risk.
>> That's not a big enough sample size to make me panic about getting a
>> hasty fix into 9.4, but I do think we should fix this going forward.

> Agreed.

BTW, just comparing the handling of TOAST_MAX_CHUNK_SIZE and LOBLKSIZE,
I noticed that the tuptoaster.c functions are reasonably paranoid about
checking that toast chunks are the expected size, but the large object
functions are not: the latter have either no check at all, or just an
Assert that the size is not more than expected. So we could provide at
least a partial guard against a wrong LOBLKSIZE configuration by making
all the large-object functions throw elog(ERROR) if the length of a LO
chunk is more than LOBLKSIZE. Unfortunately, length *less* than LOBLKSIZE
is an expected case, so this would only help in one direction. Still,
it'd be an easy and back-patchable change that would provide at least some
defense, so I'm thinking of doing it.

regards, tom lane

On Wed, Jun 4, 2014 at 1:21 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Stephen Frost <sfrost(at)snowman(dot)net> writes:
>> * Tom Lane (tgl(at)sss(dot)pgh(dot)pa(dot)us) wrote:
>>> I've not heard one either, but there was just somebody asking in
>>> pgsql-general about changing LOBLKSIZE, so he's going to be at risk.
>>> That's not a big enough sample size to make me panic about getting a
>>> hasty fix into 9.4, but I do think we should fix this going forward.
>
>> Agreed.
>
> BTW, just comparing the handling of TOAST_MAX_CHUNK_SIZE and LOBLKSIZE,
> I noticed that the tuptoaster.c functions are reasonably paranoid about
> checking that toast chunks are the expected size, but the large object
> functions are not: the latter have either no check at all, or just an
> Assert that the size is not more than expected. So we could provide at
> least a partial guard against a wrong LOBLKSIZE configuration by making
> all the large-object functions throw elog(ERROR) if the length of a LO
> chunk is more than LOBLKSIZE. Unfortunately, length *less* than LOBLKSIZE
> is an expected case, so this would only help in one direction. Still,
> it'd be an easy and back-patchable change that would provide at least some
> defense, so I'm thinking of doing it.

This seems like a pretty weak argument for adding run-time overhead.
Maybe it can be justified on the grounds that it would catch corrupted
TOAST data, but I've never heard of anyone changing LOBLKSIZE and see
no reason to get agitated about it.

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

Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> On Wed, Jun 4, 2014 at 1:21 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> BTW, just comparing the handling of TOAST_MAX_CHUNK_SIZE and LOBLKSIZE,
>> I noticed that the tuptoaster.c functions are reasonably paranoid about
>> checking that toast chunks are the expected size, but the large object
>> functions are not: the latter have either no check at all, or just an
>> Assert that the size is not more than expected. So we could provide at
>> least a partial guard against a wrong LOBLKSIZE configuration by making
>> all the large-object functions throw elog(ERROR) if the length of a LO
>> chunk is more than LOBLKSIZE. Unfortunately, length *less* than LOBLKSIZE
>> is an expected case, so this would only help in one direction. Still,
>> it'd be an easy and back-patchable change that would provide at least some
>> defense, so I'm thinking of doing it.

> This seems like a pretty weak argument for adding run-time overhead.
> Maybe it can be justified on the grounds that it would catch corrupted
> TOAST data, but I've never heard of anyone changing LOBLKSIZE and see
> no reason to get agitated about it.

One if-test per fetched tuple hardly seems likely to add measurable
overhead. As for "never heard of", see today's thread in pgsql-general:
http://www.postgresql.org/message-id/flat/CAGou9Mg=9qPYTdh18NDO3LTJtwQN8uRdTwABfkcyMRUt6D_fJw(at)mail(dot)gmail(dot)com
There was a similar gripe a few months ago:
http://www.postgresql.org/message-id/CACg6vWXy_84ShCCXzNCsz9xLfWnx5sZvQRU6aNcrR0c3XW1Bxg@mail.gmail.com

There are at least two places in inv_api.c where we have
"Assert(pagelen <= LOBLKSIZE)" that is protecting a subsequent memcpy
into a local variable of size LOBLKSIZE, so that the only thing standing
between us and a stack-smash security issue that's trivially exploitable
in production builds is that on-disk data conforms to our expectation
about LOBLKSIZE. I think it's definitely worth promoting these checks
to regular runtime-if-test-and-elog.

regards, tom lane

* Tom Lane (tgl(at)sss(dot)pgh(dot)pa(dot)us) wrote:
> There are at least two places in inv_api.c where we have
> "Assert(pagelen <= LOBLKSIZE)" that is protecting a subsequent memcpy
> into a local variable of size LOBLKSIZE, so that the only thing standing
> between us and a stack-smash security issue that's trivially exploitable
> in production builds is that on-disk data conforms to our expectation
> about LOBLKSIZE. I think it's definitely worth promoting these checks
> to regular runtime-if-test-and-elog.

Agreed. Promoting that to a run-time check seems well worth it to me.

Thanks,

Stephen

Stephen Frost <sfrost(at)snowman(dot)net> writes:
> * Tom Lane (tgl(at)sss(dot)pgh(dot)pa(dot)us) wrote:
>> There are at least two places in inv_api.c where we have
>> "Assert(pagelen <= LOBLKSIZE)" that is protecting a subsequent memcpy
>> into a local variable of size LOBLKSIZE, so that the only thing standing
>> between us and a stack-smash security issue that's trivially exploitable
>> in production builds is that on-disk data conforms to our expectation
>> about LOBLKSIZE. I think it's definitely worth promoting these checks
>> to regular runtime-if-test-and-elog.

> Agreed. Promoting that to a run-time check seems well worth it to me.

Here's a draft patch for this. Barring objections I'll commit the whole
thing to HEAD, and the inv_api.c changes to the back branches as well.

regards, tom lane

On Wed, Jun 4, 2014 at 06:57:31PM -0400, Tom Lane wrote:
> Stephen Frost <sfrost(at)snowman(dot)net> writes:
> > * Tom Lane (tgl(at)sss(dot)pgh(dot)pa(dot)us) wrote:
> >> There are at least two places in inv_api.c where we have
> >> "Assert(pagelen <= LOBLKSIZE)" that is protecting a subsequent memcpy
> >> into a local variable of size LOBLKSIZE, so that the only thing standing
> >> between us and a stack-smash security issue that's trivially exploitable
> >> in production builds is that on-disk data conforms to our expectation
> >> about LOBLKSIZE. I think it's definitely worth promoting these checks
> >> to regular runtime-if-test-and-elog.
>
> > Agreed. Promoting that to a run-time check seems well worth it to me.
>
> Here's a draft patch for this. Barring objections I'll commit the whole
> thing to HEAD, and the inv_api.c changes to the back branches as well.

Uh, I think pg_upgrade needs to check that they match too.

--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ Everyone has their own god. +

Bruce Momjian <bruce(at)momjian(dot)us> writes:
> Uh, I think pg_upgrade needs to check that they match too.

Possibly. What do you think it should do when examining a pg_control
version that lacks the field?

regards, tom lane

On Tue, Jun 17, 2014 at 12:28:46PM -0400, Tom Lane wrote:
> Bruce Momjian <bruce(at)momjian(dot)us> writes:
> > Uh, I think pg_upgrade needs to check that they match too.
>
> Possibly. What do you think it should do when examining a pg_control
> version that lacks the field?

Good question. I have existing cases where fields were removed, but not
ones that were added. As we have no way to query the old cluster's
value for LOBLKSIZE, I think I will just add code to compare them if
they _both_ exist.

--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ Everyone has their own god. +

Bruce Momjian wrote:
> On Tue, Jun 17, 2014 at 12:28:46PM -0400, Tom Lane wrote:
> > Bruce Momjian <bruce(at)momjian(dot)us> writes:
> > > Uh, I think pg_upgrade needs to check that they match too.
> >
> > Possibly. What do you think it should do when examining a pg_control
> > version that lacks the field?
>
> Good question. I have existing cases where fields were removed, but not
> ones that were added. As we have no way to query the old cluster's
> value for LOBLKSIZE, I think I will just add code to compare them if
> they _both_ exist.

Can't you compare it to the historic default value? I mean, add an
assumption that people thus far has never tweaked it.

--
Álvaro Herrera http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services

On Tue, Jun 17, 2014 at 03:55:02PM -0400, Alvaro Herrera wrote:
> Bruce Momjian wrote:
> > On Tue, Jun 17, 2014 at 12:28:46PM -0400, Tom Lane wrote:
> > > Bruce Momjian <bruce(at)momjian(dot)us> writes:
> > > > Uh, I think pg_upgrade needs to check that they match too.
> > >
> > > Possibly. What do you think it should do when examining a pg_control
> > > version that lacks the field?
> >
> > Good question. I have existing cases where fields were removed, but not
> > ones that were added. As we have no way to query the old cluster's
> > value for LOBLKSIZE, I think I will just add code to compare them if
> > they _both_ exist.
>
> Can't you compare it to the historic default value? I mean, add an
> assumption that people thus far has never tweaked it.

Well, if they did tweak it, then they would be unable to use pg_upgrade
because it would complain about a mismatch if they actually matched the
old and new servers.

--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ Everyone has their own god. +

Bruce Momjian <bruce(at)momjian(dot)us> writes:
> On Tue, Jun 17, 2014 at 03:55:02PM -0400, Alvaro Herrera wrote:
>> Can't you compare it to the historic default value? I mean, add an
>> assumption that people thus far has never tweaked it.

> Well, if they did tweak it, then they would be unable to use pg_upgrade
> because it would complain about a mismatch if they actually matched the
> old and new servers.

What about comparing to the symbolic value LOBLKSIZE? This would make
pg_upgrade assume that the old installation had been tweaked the same
as in its own build. This ends up being the same as what you said,
ie, effectively no comparison ... but it might be less complicated to
code/understand.

regards, tom lane

On Tue, Jun 17, 2014 at 07:12:16PM -0400, Tom Lane wrote:
> Bruce Momjian <bruce(at)momjian(dot)us> writes:
> > On Tue, Jun 17, 2014 at 03:55:02PM -0400, Alvaro Herrera wrote:
> >> Can't you compare it to the historic default value? I mean, add an
> >> assumption that people thus far has never tweaked it.
>
> > Well, if they did tweak it, then they would be unable to use pg_upgrade
> > because it would complain about a mismatch if they actually matched the
> > old and new servers.
>
> What about comparing to the symbolic value LOBLKSIZE? This would make
> pg_upgrade assume that the old installation had been tweaked the same
> as in its own build. This ends up being the same as what you said,
> ie, effectively no comparison ... but it might be less complicated to
> code/understand.

OK, assume the compiled-in default is the value for an old cluster that
has no value --- yeah, I could do that.

--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ Everyone has their own god. +

On Tue, Jun 17, 2014 at 8:46 PM, Bruce Momjian <bruce(at)momjian(dot)us> wrote:
> On Tue, Jun 17, 2014 at 07:12:16PM -0400, Tom Lane wrote:
>> Bruce Momjian <bruce(at)momjian(dot)us> writes:
>> > On Tue, Jun 17, 2014 at 03:55:02PM -0400, Alvaro Herrera wrote:
>> >> Can't you compare it to the historic default value? I mean, add an
>> >> assumption that people thus far has never tweaked it.
>>
>> > Well, if they did tweak it, then they would be unable to use pg_upgrade
>> > because it would complain about a mismatch if they actually matched the
>> > old and new servers.
>>
>> What about comparing to the symbolic value LOBLKSIZE? This would make
>> pg_upgrade assume that the old installation had been tweaked the same
>> as in its own build. This ends up being the same as what you said,
>> ie, effectively no comparison ... but it might be less complicated to
>> code/understand.
>
> OK, assume the compiled-in default is the value for an old cluster that
> has no value --- yeah, I could do that.

I'm not really sure why this is better than Bruce's original proposal, though.

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

Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> On Tue, Jun 17, 2014 at 8:46 PM, Bruce Momjian <bruce(at)momjian(dot)us> wrote:
>> On Tue, Jun 17, 2014 at 07:12:16PM -0400, Tom Lane wrote:
>>> What about comparing to the symbolic value LOBLKSIZE? This would make
>>> pg_upgrade assume that the old installation had been tweaked the same
>>> as in its own build. This ends up being the same as what you said,
>>> ie, effectively no comparison ... but it might be less complicated to
>>> code/understand.

>> OK, assume the compiled-in default is the value for an old cluster that
>> has no value --- yeah, I could do that.

> I'm not really sure why this is better than Bruce's original proposal, though.

The net behavior would be the same, but I thought it might be easier to
code by thinking of it this way. Or maybe it wouldn't --- it's just a
suggestion.

regards, tom lane

On Wed, Jun 18, 2014 at 2:55 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Robert Haas <robertmhaas(at)gmail(dot)com> writes:
>> On Tue, Jun 17, 2014 at 8:46 PM, Bruce Momjian <bruce(at)momjian(dot)us> wrote:
>>> On Tue, Jun 17, 2014 at 07:12:16PM -0400, Tom Lane wrote:
>>>> What about comparing to the symbolic value LOBLKSIZE? This would make
>>>> pg_upgrade assume that the old installation had been tweaked the same
>>>> as in its own build. This ends up being the same as what you said,
>>>> ie, effectively no comparison ... but it might be less complicated to
>>>> code/understand.
>
>>> OK, assume the compiled-in default is the value for an old cluster that
>>> has no value --- yeah, I could do that.
>
>> I'm not really sure why this is better than Bruce's original proposal, though.
>
> The net behavior would be the same, but I thought it might be easier to
> code by thinking of it this way. Or maybe it wouldn't --- it's just a
> suggestion.

Well, the difference is that if we just don't check it, there can
never be an error. Basically, it's the user's job to DTRT. If we
check it against some semi-arbitrary value, we'll catch the case where
the old cluster was modified with a custom setting and the new one was
not - but couldn't we also get false positives under obscure
circumstances?

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

Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> On Wed, Jun 18, 2014 at 2:55 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> The net behavior would be the same, but I thought it might be easier to
>> code by thinking of it this way. Or maybe it wouldn't --- it's just a
>> suggestion.

> Well, the difference is that if we just don't check it, there can
> never be an error. Basically, it's the user's job to DTRT. If we
> check it against some semi-arbitrary value, we'll catch the case where
> the old cluster was modified with a custom setting and the new one was
> not - but couldn't we also get false positives under obscure
> circumstances?

Huh? What we'd be checking is the LOBLKSIZE compiled into pg_upgrade
versus that stored into pg_control by the new postmaster. If those
are different, then pg_upgrade didn't come from the same build as the
new postmaster, which is already a pretty hazardous situation (especially
if the user is fooling with low-level stuff like this).

regards, tom lane

On Wed, Jun 18, 2014 at 3:28 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Robert Haas <robertmhaas(at)gmail(dot)com> writes:
>> On Wed, Jun 18, 2014 at 2:55 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>>> The net behavior would be the same, but I thought it might be easier to
>>> code by thinking of it this way. Or maybe it wouldn't --- it's just a
>>> suggestion.
>
>> Well, the difference is that if we just don't check it, there can
>> never be an error. Basically, it's the user's job to DTRT. If we
>> check it against some semi-arbitrary value, we'll catch the case where
>> the old cluster was modified with a custom setting and the new one was
>> not - but couldn't we also get false positives under obscure
>> circumstances?
>
> Huh? What we'd be checking is the LOBLKSIZE compiled into pg_upgrade
> versus that stored into pg_control by the new postmaster. If those
> are different, then pg_upgrade didn't come from the same build as the
> new postmaster, which is already a pretty hazardous situation (especially
> if the user is fooling with low-level stuff like this).

OK, I agree that checking that wouldn't hurt anything.

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

On Tue, Jun 17, 2014 at 08:46:00PM -0400, Bruce Momjian wrote:
> On Tue, Jun 17, 2014 at 07:12:16PM -0400, Tom Lane wrote:
> > Bruce Momjian <bruce(at)momjian(dot)us> writes:
> > > On Tue, Jun 17, 2014 at 03:55:02PM -0400, Alvaro Herrera wrote:
> > >> Can't you compare it to the historic default value? I mean, add an
> > >> assumption that people thus far has never tweaked it.
> >
> > > Well, if they did tweak it, then they would be unable to use pg_upgrade
> > > because it would complain about a mismatch if they actually matched the
> > > old and new servers.
> >
> > What about comparing to the symbolic value LOBLKSIZE? This would make
> > pg_upgrade assume that the old installation had been tweaked the same
> > as in its own build. This ends up being the same as what you said,
> > ie, effectively no comparison ... but it might be less complicated to
> > code/understand.
>
> OK, assume the compiled-in default is the value for an old cluster that
> has no value --- yeah, I could do that.

Turns out I already had values that could be missing in the old cluster,
so I just used the same format for this, rather than testing for
LOBLKSIZE.

Attached patch applied.

--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ Everyone has their own god. +