From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
---|---|
To: | Thomas Munro <thomas(dot)munro(at)gmail(dot)com> |
Cc: | Andres Freund <andres(at)anarazel(dot)de>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>, Dilip Kumar <dilipbalaut(at)gmail(dot)com> |
Subject: | Re: wrong fds used for refilenodes after pg_upgrade relfilenode changes Reply-To: |
Date: | 2022-05-09 13:06:59 |
Message-ID: | CA+TgmoYJ03r5359gQutRGP9BtigYCg3_UskcmnVjBf-QO3-0pQ@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Sun, May 8, 2022 at 7:30 PM Thomas Munro <thomas(dot)munro(at)gmail(dot)com> wrote:
> Simple idea: how about logging the PID of processes that block
> progress for too long? In the attached, I arbitrarily picked 5
> seconds as the wait time between LOG messages. Also, DEBUG1 messages
> let you see the processing speed on eg build farm animals. Thoughts?
>
> To test this, kill -STOP a random backend, and then try an ALTER
> DATABASE SET TABLESPACE in another backend. Example output:
>
> DEBUG: waiting for all backends to process ProcSignalBarrier generation 1
> LOG: still waiting for pid 1651417 to accept ProcSignalBarrier
> STATEMENT: alter database mydb set tablespace ts1;
> LOG: still waiting for pid 1651417 to accept ProcSignalBarrier
> STATEMENT: alter database mydb set tablespace ts1;
> LOG: still waiting for pid 1651417 to accept ProcSignalBarrier
> STATEMENT: alter database mydb set tablespace ts1;
> LOG: still waiting for pid 1651417 to accept ProcSignalBarrier
> STATEMENT: alter database mydb set tablespace ts1;
This is a very good idea.
> Another thought is that it might be nice to be able to test with a
> dummy PSB that doesn't actually do anything. You could use it to see
> how fast your system processes it, while doing various other things,
> and to find/debug problems in other code that fails to handle
> interrupts correctly. Here's an attempt at that. I guess it could go
> into a src/test/modules/something instead of core, but on the other
> hand the PSB itself has to be in core anyway, so maybe not. Thoughts?
> No documentation yet, just seeing if people think this is worth
> having... better names/ideas welcome.
I did this at one point, but I wasn't convinced it was going to find
enough bugs to be worth committing. It's OK if you're convinced of
things that didn't convince me, though.
--
Robert Haas
EDB: http://www.enterprisedb.com
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Haas | 2022-05-09 13:11:37 | Re: should check interrupts in BuildRelationExtStatistics ? |
Previous Message | Peter Eisentraut | 2022-05-09 12:36:47 | Re: configure openldap crash warning |