Re: hash_xlog_split_allocate_page: failed to acquire cleanup lock
От | Andres Freund |
---|---|
Тема | Re: hash_xlog_split_allocate_page: failed to acquire cleanup lock |
Дата | |
Msg-id | 20220930190512.5aiar5cdr5suoiee@alap3.anarazel.de обсуждение исходный текст |
Ответ на | Re: hash_xlog_split_allocate_page: failed to acquire cleanup lock (Amit Kapila <amit.kapila16@gmail.com>) |
Ответы |
Re: hash_xlog_split_allocate_page: failed to acquire cleanup lock
Re: hash_xlog_split_allocate_page: failed to acquire cleanup lock |
Список | pgsql-hackers |
Hi, This issue does occasionally happen in CI, as e.g. noted in this thread: https://www.postgresql.org/message-id/20220930185345.GD6256%40telsasoft.com On 2022-08-18 15:17:47 +0530, Amit Kapila wrote: > I agree with you that getting rid of the clean-up lock on the new > bucket is a more invasive patch and should be done separately if > required. Yesterday, I have done a brief analysis and I think that is > possible but it doesn't seem to be a good idea to backpatch it. My problem with this approach is that the whole cleanup lock is hugely misleading as-is. As I noted in https://www.postgresql.org/message-id/20220817193032.z35vdjhpzkgldrd3%40awork3.anarazel.de we take the cleanup lock *after* re-initializing the page. Thereby completely breaking the properties that a cleanup lock normally tries to guarantee. Even if that were to achieve something useful (doubtful in this case), it'd need a huge comment explaining what's going on. Greetings, Andres Freund
В списке pgsql-hackers по дате отправления: