Re: [BUGS] Breakage with VACUUM ANALYSE + partitions
От | Fabien COELHO |
---|---|
Тема | Re: [BUGS] Breakage with VACUUM ANALYSE + partitions |
Дата | |
Msg-id | alpine.DEB.2.10.1605022146390.927@sto обсуждение исходный текст |
Ответ на | Re: [BUGS] Breakage with VACUUM ANALYSE + partitions (Andres Freund <andres@anarazel.de>) |
Ответы |
Re: [BUGS] Breakage with VACUUM ANALYSE + partitions
|
Список | pgsql-hackers |
Hello Andres, > Sure, attached. For what it is worth, it works for me on head. I'm wondering that if _mdfd_openseg may return NULL, then ISTM that "opened_directly" should logically be false, because it was not opened? If so, maybe consider something like: opened_directy = (seg != NULL); Now it does not change the result because the later code seems garded against a NULL seg, but it does not look right to have a boolean to say that a segment was opened if it was not indeed the case. Given the comments, I understand that the truncation implementation is a shortcut with a sting, as a lot of functions must then take into account that something unusual may have happen somewhere and deal with it... Also, I do not understand why this issue is raised by the flushing patch, it seems rather independent. > I'm not sure this is the best way to go about this. I can see valid > arguments for *always* using _mdfd_openseg() in mdsync(); and I'm > wondering whether we shouldn't make EXTENSION_* into a bitmask > (extend,extend_recovery,return_null,open_deleted). I thought about that when I looked at the previous fix, but it seemed that not all combinations made sense. -- Fabien.
В списке pgsql-hackers по дате отправления: