Re: Inconvenience of pg_read_binary_file()

Поиск
Список
Период
Сортировка
От Michael Paquier
Тема Re: Inconvenience of pg_read_binary_file()
Дата
Msg-id Yp7/YUfgYD1Tr1Ri@paquier.xyz
обсуждение исходный текст
Ответ на Inconvenience of pg_read_binary_file()  (Kyotaro Horiguchi <horikyota.ntt@gmail.com>)
Ответы Re: Inconvenience of pg_read_binary_file()  (Kyotaro Horiguchi <horikyota.ntt@gmail.com>)
Список pgsql-hackers
On Tue, Jun 07, 2022 at 04:05:20PM +0900, Kyotaro Horiguchi wrote:
> If I want to read a file that I'm not sure of the existence but I want
> to read the whole file if exists, I would call
> pg_read_binary_file('path', 0, -1, true) but unfortunately this
> doesn't work.

Yeah, the "normal" cases that I have seen in the past just used an
extra call to pg_stat_file() to retrieve the size of the file before
reading it, but arguably it does not help if the file gets extended
between the stat() call and the read() call (we don't need to care
about this case with pg_rewind that has been the reason why the
missing_ok argument was introduced first, for one, as file extensions
don't matter as we'd replay from the LSN point where the rewind
began, adding the new blocks at replay).

There is also an argument for supporting negative values rather than
just -1.  For example -2 could mean to read all the file except the
last byte.  Or you could have an extra flavor, as of
pg_read_file(text, bool) to read the whole by default.  Supporting
just -1 as special value for the amount of data to read would be
confusing IMO.  So I would tend to choose for a set of arguments based
on (text, bool).
--
Michael

Вложения

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

Предыдущее
От: Michael Paquier
Дата:
Сообщение: Re: pg_rewind: warn when checkpoint hasn't happened after promotion
Следующее
От: Michael Paquier
Дата:
Сообщение: Re: Logging query parmeters in auto_explain