Andres Freund <andres@anarazel.de> writes:
> On 2017-09-16 14:30:21 -0400, Tom Lane wrote:
>> I wonder whether we shouldn't just revert this patch altogether.
> The problem is that the patch that makes the segment size configurable
> also adds a bunch more ordering constraints due to the fact that the
> contents of the control file influence how much shared buffers are
> needed (via wal_buffers = -1, which requires the segment size, which is
> read from the control file). Reading things in the wrong order leads to
> bad results too.
Maybe we could redefine wal_buffers to avoid that. Or read the control
file at the time where we need it. This does not seem like a problem
that justifies a system-wide change that's much more delicate than
you thought.
>> I'm now quite worried about whether we aren't introducing
>> hazards of using stale values from the file; if a system crash isn't
>> enough to get it to flush its cache, then what is?
> I don't think the problem here is stale values, it's "just" a stale
> pointer pointing into shared memory that gets reiniitalized?
The code that's crashing is attempting to install some pre-existing
copy of pg_control into shared memory. Even if there were good reason
to think the copy were up to date, I'm not sure we should trust it
in a crash recovery context. I'd rather see this hunk of code just
playing dumb and reading the file (which, I'm pretty sure, is what
it did up till this week).
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers