Re: Using XLogFileNameP in critical section

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: Using XLogFileNameP in critical section
Дата
Msg-id 12161.1575390297@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: Using XLogFileNameP in critical section  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: Using XLogFileNameP in critical section  (Michael Paquier <michael@paquier.xyz>)
Re: Using XLogFileNameP in critical section  (Andrew Dunstan <andrew@dunslane.net>)
Список pgsql-hackers
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\postgres.vcxproj]
> I'm guessing you missed a reference someplace.

Hm ... grep swears up and down that there is no remaining instance
of the string "XLogFileNameP" anywhere in the tree.  So this doesn't
seem to be the fault of 9989d37d1 per se.  What my eye now falls on
is this, a bit further up in the build log [1]:

...
PreLinkEvent:
  Generate DEF file
  perl src\tools\msvc\gendef.pl Release\postgres x64
  :VCEnd
  Not re-generating POSTGRES.DEF, file already exists.
Link:
...

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 critters might point the finger
that way.

            regards, tom lane

[1] https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=drongo&dt=2019-12-03%2007%3A30%3A01



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Fabien COELHO
Дата:
Сообщение: Re: pgbench -i progress output on terminal
Следующее
От: Tom Lane
Дата:
Сообщение: Re: Windows buildfarm members vs. new async-notify isolation test