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  (Fabien COELHO <coelho@cri.ensmp.fr>)
Список 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 по дате отправления:

Предыдущее
От: Rodrigo Cavalcante
Дата:
Сообщение: Pg_stop_backup process does not run - Backup Intervals
Следующее
От: Kevin Grittner
Дата:
Сообщение: Re: snapshot too old, configured by time