From: | Andres Freund <andres(at)2ndquadrant(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | pgsql-hackers(at)postgreSQL(dot)org |
Subject: | Re: pg_control is missing a field for LOBLKSIZE |
Date: | 2014-06-04 15:03:05 |
Message-ID: | 20140604150305.GC10482@alap3.anarazel.de |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2014-06-04 15:06:26 | Re: Migrating from 9.2.4 to 9.3.0 with XML DOCTYPE |
Previous Message | Alexey Klyukin | 2014-06-04 14:59:10 | Could not open file pg_multixact/offsets/ ERROR on 9.3.4 |