From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
---|---|
To: | Josh Berkus <josh(at)agliodbs(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-03 17:28:30 |
Message-ID: | CA+TgmoYSYD7dRVvcdRAzRA1WR7sT2vGRT83NKLM+ohRU4ZZRxg@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Fri, Jul 31, 2015 at 8:09 PM, Josh Berkus <josh(at)agliodbs(dot)com> wrote:
> 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.
OK. So capping it sounds like the right approach, then.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Haas | 2015-08-03 17:31:23 | Re: Minimum tuple threshold to decide last pass of VACUUM |
Previous Message | Kevin Grittner | 2015-08-03 17:07:55 | BRIN trivial tweaks |