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  (Andres Freund <andres@anarazel.de>)
Список 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 по дате отправления:

Предыдущее
От: "David G. Johnston"
Дата:
Сообщение: Re: Rename max_parallel_degree?
Следующее
От: Dean Rasheed
Дата:
Сообщение: Re: More inaccurate results from numeric pow()