> >> 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-ow...@postgresql.org > [mailto:pgsql-hackers-ow...@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 <j...@agliodbs.com> wrote: > > On 07/31/2015 10:43 AM, Robert Haas wrote: > >> On Thu, Jul 30, 2015 at 9:17 PM, Josh Berkus <j...@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
allow_wal_buffer_over_2G.patch
Description: Binary data
smime.p7s
Description: S/MIME cryptographic signature
