Re: BUG #17716: walsender process hang while decoding 'DROP PUBLICATION' XLOG
От | Amit Kapila |
---|---|
Тема | Re: BUG #17716: walsender process hang while decoding 'DROP PUBLICATION' XLOG |
Дата | |
Msg-id | CAA4eK1JcL6cW6OQi4GMW-kWwnGstunQW+QkW+NkEMmjqYt_tUw@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: BUG #17716: walsender process hang while decoding 'DROP PUBLICATION' XLOG (Bowen Shi <zxwsbg12138@gmail.com>) |
Список | pgsql-bugs |
On Mon, Dec 19, 2022 at 9:58 PM Bowen Shi <zxwsbg12138@gmail.com> wrote: > > Hello, > Thanks for your advice. I make some tests and this problem can't be > reproduced in PG 14+ version. I think adding a new XLOG type will help > resolve this problem. But I think the following patch may be helpful > in the PG 13 version. > > The invalidation contains two parts: pgoutput and relfilenodeMap. We > have no way to optimize relfilenodeMap part , since it has been > discussed in previous mails > https://www.postgresql.org/message-id/CANDwggKYveEtXjXjqHA6RL3AKSHMsQyfRY6bK+NqhAWJyw8psQ@mail.gmail.com. > > However, I'd like to contribute a patch to fix pgoutput part. We can skip > invalidating caches after first time with a lazy tag and this works. > It almost doubles the walsender performance while decoding this XLOG. > I don't see any obvious problem with your suggested fix but it doesn't appear to be a very good solution as it will still mark all entries for an invalidation after any valid DML operation. Also, there doesn't appear to be much benefit in versions >=v14 (as per tests done till now). So, instead of partially solving your use case for old versions, isn't it better if you can upgrade to later versions (>=14)? -- With Regards, Amit Kapila.
В списке pgsql-bugs по дате отправления: