Re: Using XLogFileNameP in critical section

Поиск
Список
Период
Сортировка
От Andrew Dunstan
Тема Re: Using XLogFileNameP in critical section
Дата
Msg-id 41357459-90ec-408a-cb65-9d284eeb7ab0@dunslane.net
обсуждение исходный текст
Ответ на Re: Using XLogFileNameP in critical section  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
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 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
>


this was pilot error on my part. Should be fixed now.


cheers


andrew




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

Предыдущее
От: Pavel Stehule
Дата:
Сообщение: Re: log bind parameter values on error
Следующее
От: Jakob Egger
Дата:
Сообщение: Re: Frontend/Backend Protocol: SSL / GSS Protocol Negotiation Problem