Andres Freund <and...@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