On 12/3/19 11:24 AM, Tom Lane wrote:
> I wrote:
>> Also, buildfarm member drongo is not happy:
>> postgres.def : error LNK2001: unresolved external symbol XLogFileNameP
>> [C:\prog\bf\root\HEAD\pgsql.build\postgres.vcxproj]
>> Release/postgres/postgres.lib : fatal error LNK1120: 1 unresolved ext
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. Any
On Tue, Dec 03, 2019 at 11:24:57AM -0500, Tom Lane wrote:
> So it seems that the problem might really be a faulty rule in our
> MSVC build script about when postgres.def needs to be regenerated?
> Or else it's some weird caching problem on drongo --- the lack of
> complaints from other Windows crit
On Tue, 3 Dec 2019 at 07:09, Michael Paquier wrote:
>
> On Mon, Dec 02, 2019 at 10:14:58PM +0100, Masahiko Sawada wrote:
> > Agreed. I've attached the updated version patch. Please review it.
>
> Thanks, applied on HEAD after a few edits. gettext() does not set
> errno, so the new style of issue_
I wrote:
> Also, buildfarm member drongo is not happy:
> postgres.def : error LNK2001: unresolved external symbol XLogFileNameP
> [C:\prog\bf\root\HEAD\pgsql.build\postgres.vcxproj]
> Release/postgres/postgres.lib : fatal error LNK1120: 1 unresolved externals
> [C:\prog\bf\root\HEAD\pgsql.build\p
Alvaro Herrera writes:
> 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.)
Also, buildfar
On 2019-Dec-03, Michael Paquier wrote:
> Per the low probability of the failures, I did not backpatch that
> stuff. I quickly looked at applying that further down, and attached
> is a version for v12 FWIW, and I suspect much more conflicts the more
> you go down (wal segment size added in 11, dif
On Mon, Dec 02, 2019 at 10:14:58PM +0100, Masahiko Sawada wrote:
> Agreed. I've attached the updated version patch. Please review it.
Thanks, applied on HEAD after a few edits. gettext() does not set
errno, so the new style of issue_xlog_fsync() is actually fine.
Please note that there was one mi
On Mon, 2 Dec 2019 at 16:56, Alvaro Herrera 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 nam
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 exam
On Fri, Nov 29, 2019 at 06:44:58PM +0100, Masahiko Sawada wrote:
> I encountered that the assertion error is reported instead of a proper
> PANIC message when failed to fsync WAL. The cause is that there are
> multiple places where we call XLogFileNameP function that calls palloc
> during critical
Hi,
I encountered that the assertion error is reported instead of a proper
PANIC message when failed to fsync WAL. The cause is that there are
multiple places where we call XLogFileNameP function that calls palloc
during critical section, for example XLogWrite function.
TRAP: FailedAssertion("Cri
12 matches
Mail list logo
