Re: Tablesync early exit

Поиск
Список
Период
Сортировка
От Amit Kapila
Тема Re: Tablesync early exit
Дата
Msg-id CAA4eK1Kp3m-3U2F_LFfTG18TMPTekRNy_J08YZ5GV+55nvvuyw@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Tablesync early exit  (Peter Smith <smithpb2250@gmail.com>)
Ответы Re: Tablesync early exit  (Peter Smith <smithpb2250@gmail.com>)
Список pgsql-hackers
On Fri, Apr 1, 2022 at 1:52 PM Peter Smith <smithpb2250@gmail.com> wrote:
>
> On Wed, Mar 16, 2022 at 4:07 PM Amit Kapila <amit.kapila16@gmail.com> wrote:
>
> I think the STATE_CATCHUP guarantees the apply worker must have
> received (or tried to receive) a message. See the previous answer.
>

Sorry, I intend to say till the sync worker has received any message.
The point is that LSN till where the copy has finished might actually
be later than some of the in-progress transactions on the server. It
may not be a good idea to blindly skip those changes if the apply
worker has already received those changes (say via a 'streaming'
mode). Today, all such changes would be written to the file and
applied at commit time but tomorrow, we can have an implementation
where we can apply such changes (via some background worker) by
skipping changes related to the table for which the table-sync worker
is in-progress. Now, in such a scenario, unless, we allow the table
sync worker to process more messages, we will end up losing some
changes for that particular table.

As per my understanding, this is safe as per the current code but it
can't be guaranteed for future implementations and the amount of extra
work is additional work to receive the messages for one transaction. I
still don't think that it is a good idea to pursue this patch.

-- 
With Regards,
Amit Kapila.



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

Предыдущее
От: Rushabh Lathia
Дата:
Сообщение: Re: PostgreSQL shutdown modes
Следующее
От: Julien Rouhaud
Дата:
Сообщение: Re: [PATCH] Tracking statements entry timestamp in pg_stat_statements