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
Sent via pgsql-hackers mailing list (email@example.com)
To make changes to your subscription: