recovery test error

Started by Andrew Dunstanover 1 year ago3 messages
#1Andrew Dunstan
andrew@dunslane.net

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

#2Michael Paquier
michael@paquier.xyz
In reply to: Andrew Dunstan (#1)
Re: recovery test error

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

#3Andrew Dunstan
andrew@dunslane.net
In reply to: Michael Paquier (#2)
Re: recovery test error

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