Re: [BUGS] Breakage with VACUUM ANALYSE + partitions
От | Andres Freund |
---|---|
Тема | Re: [BUGS] Breakage with VACUUM ANALYSE + partitions |
Дата | |
Msg-id | 20160502203634.hmjgdumfgqrldo6n@alap3.anarazel.de обсуждение исходный текст |
Ответ на | Re: [BUGS] Breakage with VACUUM ANALYSE + partitions (Fabien COELHO <coelho@cri.ensmp.fr>) |
Ответы |
Re: [BUGS] Breakage with VACUUM ANALYSE + partitions
|
Список | pgsql-hackers |
On 2016-05-02 22:00:14 +0200, Fabien COELHO wrote: > 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); Hm, don't care either way. Seems just as valid to understand it as the attempt to directly open the segment. > Also, I do not understand why this issue is raised by the flushing patch, it > seems rather independent. It's not the flushing itself, it's 72a98a639574d2e25ed94652848555900c81a799 > >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. Sure, but that's nothing unusual. Here's an attempt at doing so - not fully polished, just as a discussion point. I think it looks better. Fabien, Robert, what do you think? Greetings, Andres Freund
Вложения
В списке pgsql-hackers по дате отправления: