From: | Andres Freund <andres(at)anarazel(dot)de> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Takashi Horikawa <t-horikawa(at)aj(dot)jp(dot)nec(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: patch: prevent user from setting wal_buffers over 2GB bytes |
Date: | 2015-08-04 13:52:09 |
Message-ID: | 20150804135209.GD4736@alap3.anarazel.de |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 2015-08-04 09:49:58 -0400, Tom Lane wrote:
> Takashi Horikawa <t-horikawa(at)aj(dot)jp(dot)nec(dot)com> writes:
> >>>> 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'm unsure whether this represents a complete fix ... but even if it does,
> it would be awfully easy to re-introduce similar bugs in future code
> changes, and who would notice? Josh's approach of restricting the buffer
> size seems a lot more robust.
>
> If there were any practical use-case for such large WAL buffers then it
> might be worth spending some effort/risk here. But AFAICS, there is not.
> Indeed, capping wal_buffers might be argued to be a good thing in itself
> because it would prevent users from wasting shared memory foolishly.
>
> So my vote is for the original approach. (I've not read Josh's patch,
> so there might be something wrong with it in detail, but I like the
> basic approach.)
+1
From | Date | Subject | |
---|---|---|---|
Next Message | Heikki Linnakangas | 2015-08-04 13:54:33 | Re: RFC: replace pg_stat_activity.waiting with something more descriptive |
Previous Message | Tom Lane | 2015-08-04 13:49:58 | Re: patch: prevent user from setting wal_buffers over 2GB bytes |