Re: BUG #17577: pg_ctl promote is not preemptive in archive recovery

Поиск
Список
Период
Сортировка
От Daniel Farina
Тема Re: BUG #17577: pg_ctl promote is not preemptive in archive recovery
Дата
Msg-id CACN56+Pe0Nitnn-+d9=sfYG_1S_vrsRZrsr4ZNWQhbf25auHaw@mail.gmail.com
обсуждение исходный текст
Ответ на Re: BUG #17577: pg_ctl promote is not preemptive in archive recovery  ("David G. Johnston" <david.g.johnston@gmail.com>)
Ответы Re: BUG #17577: pg_ctl promote is not preemptive in archive recovery  (Kyotaro Horiguchi <horikyota.ntt@gmail.com>)
Список pgsql-bugs
On Fri, Aug 5, 2022 at 12:21 PM David G. Johnston
<david.g.johnston@gmail.com> wrote:
>
> On Fri, Aug 5, 2022 at 12:10 PM PG Bug reporting form <noreply@postgresql.org> wrote:
>>
>> The following bug has been logged on the website:
>>
>> Bug reference:      17577
>> Logged by:          Daniel Farina
>> Email address:      daniel@fdr.io
>> PostgreSQL version: 14.4
>> Operating system:   AlmaLinux 8.6
>> Description:
>>
>>
>> 5) try to run pg_ctl promote while the server is in archive restore
>> 6) it will block until timeout, and not promote until restore_command exits
>> abnormally
>>
>
> On what basis are you considering this a bug?  Or, IOW, what do you expect to happen?  It doesn't seem possible for
thepromotion to actually happen as the server knows additional WAL must exist that it hasn't yet restored since all
attemptsto restore WAL have succeeded. 

pg_ctl promote should have consistent behavior regardless of WAL
transport. If I (or a computer program of mine) is issuing pg_ctl
promote, I mean for it to happen now, that's how it happens with
streaming, and in the case of streaming, the amount of WAL that can
eventually come into existence is practically unbounded.



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

Предыдущее
От: "David G. Johnston"
Дата:
Сообщение: Re: BUG #17577: pg_ctl promote is not preemptive in archive recovery
Следующее
От: PG Bug reporting form
Дата:
Сообщение: BUG #17578: undetected (on one side) deadlock with reindex CONCURRENTLY partitioned index vs drop index