Обсуждение: recovery test error

Поиск
Список
Период
Сортировка

recovery test error

От
Andrew Dunstan
Дата:
As I was trying out the libpq perl wrapper on Windows, I encountered a 
failure in recovery test 002_archiving.pl from this query:

SELECT size IS NOT NULL FROM 

pg_stat_file('c:/prog/postgresql/build/testrun/recovery/002_archiving/data/t_002_archiving_primary_data/archives/00000002.history')

The test errored out because the file didn't exist.

This was called by poll_query_until(), which is changed by the patch to 
use a libpq session rather than constantly forking psql. ISTM we should 
be passing true as a second parameter so we keep going if the file 
doesn't exist.

Thoughts?


cheers


andrew

--
Andrew Dunstan
EDB: https://www.enterprisedb.com




Re: recovery test error

От
Michael Paquier
Дата:
On Tue, Jul 16, 2024 at 03:04:13PM -0400, Andrew Dunstan wrote:
> This was called by poll_query_until(), which is changed by the patch to use
> a libpq session rather than constantly forking psql. ISTM we should be
> passing true as a second parameter so we keep going if the file doesn't
> exist.
>
> Thoughts?

Sounds like a good idea to me as this call could return ENOENT
depending on the timing of the archiver pushing the new history file,
as writeTimeLineHistory() at the end of recovery notifies the archiver
but does not wait for the fact to happen (history files are
prioritized, still there is a delay).
--
Michael

Вложения

Re: recovery test error

От
Andrew Dunstan
Дата:
On 2024-07-16 Tu 7:45 PM, Michael Paquier wrote:
> On Tue, Jul 16, 2024 at 03:04:13PM -0400, Andrew Dunstan wrote:
>> This was called by poll_query_until(), which is changed by the patch to use
>> a libpq session rather than constantly forking psql. ISTM we should be
>> passing true as a second parameter so we keep going if the file doesn't
>> exist.
>>
>> Thoughts?
> Sounds like a good idea to me as this call could return ENOENT
> depending on the timing of the archiver pushing the new history file,
> as writeTimeLineHistory() at the end of recovery notifies the archiver
> but does not wait for the fact to happen (history files are
> prioritized, still there is a delay).


Thanks. Done.


cheers


andrew

--
Andrew Dunstan
EDB: https://www.enterprisedb.com