Re: [HACKERS] logical replication and PANIC during shutdowncheckpoint in publisher
От | Michael Paquier |
---|---|
Тема | Re: [HACKERS] logical replication and PANIC during shutdowncheckpoint in publisher |
Дата | |
Msg-id | CAB7nPqTWazV3CW+SiCj86LY7DAhYLXDr3XxGzX_tcFp5BNrOog@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: [HACKERS] logical replication and PANIC during shutdowncheckpoint in publisher (Pavan Deolasee <pavan.deolasee@gmail.com>) |
Список | pgsql-hackers |
On Fri, May 5, 2017 at 5:33 PM, Pavan Deolasee <pavan.deolasee@gmail.com> wrote: > > > On Fri, May 5, 2017 at 10:56 AM, Michael Paquier <michael.paquier@gmail.com> > wrote: >> >> On Wed, May 3, 2017 at 12:25 AM, Peter Eisentraut >> >> >> >>> Can we prevent HOT pruning during logical decoding? >> >> >> >> It does not sound much difficult to do, couldn't you just make it a >> >> no-op with am_walsender? >> > >> > That's my hope. >> >> The only code path doing HOT-pruning and generating WAL is >> heap_page_prune(). Do you think that we need to worry about FPWs as >> well? > > > IMO the check should go inside heap_page_prune_opt(). Do we need to worry > about wal_log_hints or checksums producing WAL because of hint bit updates? > While I haven't read the thread, I am assuming if HOT pruning can happen, > surely hint bits can get set too. Yeah, that's as well what I am worrying about. Experts of logical decoding will correct me, but it seems to me that we have to cover all the cases where heap scans can generate WAL. -- Michael
В списке pgsql-hackers по дате отправления: