Re: Using XLogFileNameP in critical section
Michael Paquier <michael@paquier.xyz>
From: Michael Paquier <michael@paquier.xyz>
To: Alvaro Herrera <alvherre@2ndquadrant.com>
Cc: Masahiko Sawada <masahiko.sawada@2ndquadrant.com>, PostgreSQL-development <pgsql-hackers@postgresql.org>
Date: 2019-12-04T05:48:16Z
Lists: pgsql-hackers
Attachments
- gettext-fix.patch (text/x-diff) patch
- 0001-Remove-use-of-XLogFileNameP-in-error-string-generati-v12.patch (text/x-diff) patch v12-0001
On Tue, Dec 03, 2019 at 09:35:00AM -0300, Alvaro Herrera wrote: > You didn't attach anything, but I concur about the low probability > aspect: the assertion failure does not occur in production builds > (obviously); and only an out-of-memory situation is a real problem > when > an fsync fails. Anyway this should be a very localized fix, right? Sorry. You get something like the attached. The recent refactoring work you committed in this area causes already conflicts on REL_12_STABLE. > I'm not sure that the internationalization stuff in issue_xlog_fsync > is correct. I think the _() should be gettext_noop(), or alternatively > the errmsg() should be errmsg_internal(); otherwise the translation is > invoked twice. (I didn't verify this.) Hmm. We actually do both in tablecmds.c:ATWrongRelkindError(), and that's the code I was looking at yesterday when thinking about the problem.. However, parse_agg.c, parse_expr.c and parse_func.c among others like vacuumlazy.c use directly errmsg_internal() without translating the string first. So there is indeed duplicated work for both. Does the attached patch look correct to you? -- Michael
Commits
-
Remove XLogFileNameP() from the tree
- 9989d37d1c8d 13.0 landed