Re: Suppressing useless wakeups in walreceiver
От | Thomas Munro |
---|---|
Тема | Re: Suppressing useless wakeups in walreceiver |
Дата | |
Msg-id | CA+hUKG+J8m-g+4WRO1gP6h=oB1JzjsC2_YuoExR6XkE15XV+RQ@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Suppressing useless wakeups in walreceiver (Thomas Munro <thomas.munro@gmail.com>) |
Ответы |
Re: Suppressing useless wakeups in walreceiver
|
Список | pgsql-hackers |
On Mon, Nov 14, 2022 at 12:11 PM Thomas Munro <thomas.munro@gmail.com> wrote: > On Mon, Nov 14, 2022 at 11:26 AM Nathan Bossart > <nathandbossart@gmail.com> wrote: > > On Sun, Nov 13, 2022 at 05:08:04PM -0500, Tom Lane wrote: > > > There is something very seriously wrong with this patch. > > > > > > On my machine, running "make -j10 check-world" (with compilation > > > already done) has been taking right about 2 minutes for some time. > > > Since this patch, it's taking around 2:45 --- I did a bisect run > > > to confirm that this patch is where it changed. > > > > I've been looking into this. I wrote a similar patch for logical/worker.c > > before noticing that check-world was taking much longer. The problem in > > that case seems to be that process_syncing_tables() isn't called as often. > > It wouldn't surprise me if there's also something in walreceiver.c that > > depends upon the frequent wakeups. I suspect this will require a revert. > > In the case of "meson test pg_basebackup/020_pg_receivewal" it looks > like wait_for_catchup hangs around for 10 seconds waiting for HS > feedback. I'm wondering if we need to go back to high frequency > wakeups until it's caught up, or (probably better) arrange for a > proper event for progress. Digging... Maybe there is a better way to code this (I mean, who likes global variables?) and I need to test some more, but I suspect the attached is approximately what we missed.
Вложения
В списке pgsql-hackers по дате отправления: