Re: [HACKERS] make async slave to wait for lsn to be replayed
| От | Alexander Korotkov |
|---|---|
| Тема | Re: [HACKERS] make async slave to wait for lsn to be replayed |
| Дата | |
| Msg-id | CAPpHfduBSN8j5j5Ynn5x=ThD=8ypNd53D608VXGweBsPzxPvqA@mail.gmail.com обсуждение исходный текст |
| Ответ на | Re: [HACKERS] make async slave to wait for lsn to be replayed (Картышов Иван <i.kartyshov@postgrespro.ru>) |
| Ответы |
Re: [HACKERS] make async slave to wait for lsn to be replayed
|
| Список | pgsql-hackers |
Hi, Ivan!
On Fri, Jun 30, 2023 at 11:32 AM Картышов Иван <i.kartyshov@postgrespro.ru> wrote:
All rebased and tested
Thank you for continuing to work on this patch.
I see you're concentrating on the procedural version of this feature. But when you're calling a procedure within a normal SQL statement, the executor gets a snapshot and holds it until the procedure finishes. In the case the WAL record conflicts with this snapshot, the query will be canceled. Alternatively, when hot_standby_feedback = on, the query and WAL replayer will be in a deadlock (WAL replayer will wait for the query to finish, and the query will wait for WAL replayed). Do you see this issue? Or do you think I'm missing something?
XLogRecPtr
GetMinWaitedLSN(void)
{
return state->min_lsn.value;
}
{
return state->min_lsn.value;
}
You definitely shouldn't access directly the fields inside pg_atomic_uint64. In this particular case, you should use pg_atomic_read_u64().
Also, I think there is a race condition.
/* Check if we already reached the needed LSN */
if (cur_lsn >= target_lsn)
return true;
if (cur_lsn >= target_lsn)
return true;
AddWaitedLSN(target_lsn);
------
Regards,
Alexander Korotkov
В списке pgsql-hackers по дате отправления: