Re: pg_stat_bgwriter.buffers_backend is pretty meaningless (and more?)
От | Andres Freund |
---|---|
Тема | Re: pg_stat_bgwriter.buffers_backend is pretty meaningless (and more?) |
Дата | |
Msg-id | 20230306190919.ai6mxdq3sygyyths@awork3.anarazel.de обсуждение исходный текст |
Ответ на | Re: pg_stat_bgwriter.buffers_backend is pretty meaningless (and more?) (Melanie Plageman <melanieplageman@gmail.com>) |
Ответы |
Re: pg_stat_bgwriter.buffers_backend is pretty meaningless (and more?)
|
Список | pgsql-hackers |
Hi, On 2023-03-06 10:09:24 -0500, Melanie Plageman wrote: > On Mon, Mar 6, 2023 at 1:48 AM Kyotaro Horiguchi > <horikyota.ntt@gmail.com> wrote: > > > > At Mon, 06 Mar 2023 15:24:25 +0900 (JST), Kyotaro Horiguchi <horikyota.ntt@gmail.com> wrote in > > > In any case, I think we need to avoid such concurrent autovacuum/analyze. > > > > If it is correct, I believe the attached fix works. > > Thanks for investigating this! > > Yes, this fix looks correct and makes sense to me. Wouldn't it be better to just perform the section from the ALTER TABLE till the DROP TABLE in a transaction? Then there couldn't be any other accesses in just that section. I'm not convinced it's good to disallow all concurrent activity in other parts of the test. Greetings, Andres Freund
В списке pgsql-hackers по дате отправления: