> >> Why does this cause a core dump? We could consider fixing whatever
> >> the problem is rather than capping the value.
As far as I experiment with my own evaluation environment using
PostgreSQL-9.4.4 on a x86_64 Linux, this problem can be fixed with the patch
attached.
I have confirmed that applying the patch makes 'wal_buffers = 4GB' works
fine, while original PostgreSQL-9.4.4 results in core dump (segfault). I'll be
happy if anyone reconfirm this.
--
Takashi Horikawa
NEC Corporation
Knowledge Discovery Research Laboratories
> -----Original Message-----
> From: pgsql-hackers-owner@postgresql.org
> [mailto:pgsql-hackers-owner@postgresql.org] On Behalf Of Robert Haas
> Sent: Tuesday, August 04, 2015 2:29 AM
> To: Josh Berkus
> Cc: PostgreSQL-development
> Subject: Re: [HACKERS] patch: prevent user from setting wal_buffers over
> 2GB bytes
>
> On Fri, Jul 31, 2015 at 8:09 PM, Josh Berkus <josh@agliodbs.com> wrote:
> > On 07/31/2015 10:43 AM, Robert Haas wrote:
> >> On Thu, Jul 30, 2015 at 9:17 PM, Josh Berkus <josh@agliodbs.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
>
>
> --
> Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-hackers
