Re: [BUGS] Breakage with VACUUM ANALYSE + partitions

From: Fabien COELHO <coelho(at)cri(dot)ensmp(dot)fr>
To: Andres Freund <andres(at)anarazel(dot)de>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, Thom Brown <thom(at)linux(dot)com>, Abhijit Menon-Sen <ams(at)2ndquadrant(dot)com>, Michael Paquier <michael(dot)paquier(at)gmail(dot)com>, Haribabu Kommi <kommi(dot)haribabu(at)gmail(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: [BUGS] Breakage with VACUUM ANALYSE + partitions
Date: 2016-05-02 20:00:14
Message-ID: alpine.DEB.2.10.1605022146390.927@sto
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs 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.

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message Andres Freund 2016-05-02 20:36:34 Re: [BUGS] Breakage with VACUUM ANALYSE + partitions
Previous Message Andres Freund 2016-05-02 16:54:38 Re: [BUGS] Breakage with VACUUM ANALYSE + partitions

Browse pgsql-hackers by date

  From Date Subject
Next Message Dean Rasheed 2016-05-02 20:00:24 Re: More inaccurate results from numeric pow()
Previous Message David G. Johnston 2016-05-02 19:49:11 Re: Rename max_parallel_degree?