Re: patch: prevent user from setting wal_buffers over 2GB bytes

From: Josh Berkus <josh(at)agliodbs(dot)com>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: patch: prevent user from setting wal_buffers over 2GB bytes
Date: 2015-08-01 00:09:26
Message-ID: 55BC0E36.5050606@agliodbs.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 07/31/2015 10:43 AM, Robert Haas wrote:
> On Thu, Jul 30, 2015 at 9:17 PM, Josh Berkus <josh(at)agliodbs(dot)com> wrote:
>> In guc.c, the maximum for wal_buffers is INT_MAX. However, wal_buffers
>> is actually measured in 8KB buffers, not in bytes. This means that
>> users are able to set wal_buffers > 2GB. When the database is started,
>> this can cause a core dump if the WAL offset is > 2GB.
>
> Why does this cause a core dump? We could consider fixing whatever
> the problem is rather than capping the value.

The underlying issue is that byte position in wal_buffers is a 32-bit
INT, so as soon as you exceed that, core dump.

Given that useful ranges for wal_buffers are in the 8MB to 128MB range,
I don't see that a cap at 2GB is much of a burden. For that reason, I'd
prefer capping the value to replumbing. We have not previously
documented the limit for this parameter, which is probably how the bug
happened in the first place. Clearly no user has been setting it above
2GB, or they would have been core dumping.

Oh, and yes, I think this should be backported; this issue exists in all
supported versions.

--
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Josh Berkus 2015-08-01 00:18:59 Re: 64-bit XIDs again
Previous Message Tom Lane 2015-07-31 23:43:05 Re: Use of PRId64 with PostgreSQL functions