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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers