From: | Masahiko Sawada <masahiko(dot)sawada(at)2ndquadrant(dot)com> |
---|---|
To: | Alvaro Herrera <alvherre(at)2ndquadrant(dot)com> |
Cc: | Michael Paquier <michael(at)paquier(dot)xyz>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Using XLogFileNameP in critical section |
Date: | 2019-12-02 21:14:58 |
Message-ID: | CA+fd4k5w0kNqHS9ahOQR7HikBA60NzGFqnWJB_nyk77Cm8cq9A@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Mon, 2 Dec 2019 at 16:56, Alvaro Herrera <alvherre(at)2ndquadrant(dot)com> wrote:
>
> On 2019-Dec-02, Michael Paquier wrote:
>
> > I think that we had better just get rid of XLogFileNameP() (on HEAD)
> > and just change those code paths so as they use a buffer of size
> > MAXFNAMELEN, with XLogFileName() generating the file name. This leads
> > actually to some simplifications, see for example XLogWalRcvWrite..
>
> +1, that function is a footgun and there's no possible way to fix it so
> that it's never misused(*). Also, put a comment atop XLogFileName
> indicating never to create such a "helper" function again.
>
> (*) unless there was a way to have a StaticAssert() that the function is
> not called in a critical section -- have the compiler work for us. I
> don't think it's possible to write such a thing.
Agreed. I've attached the updated version patch. Please review it.
Regards,
--
Masahiko Sawada http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
Attachment | Content-Type | Size |
---|---|---|
fix_XLogFileNameP_v2.patch | application/octet-stream | 10.3 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2019-12-02 21:45:18 | Re: Bogus EXPLAIN results with column aliases for mismatched partitions |
Previous Message | Tom Lane | 2019-12-02 20:21:47 | Re: surprisingly expensive join planning query |