Re: [BUGS] Breakage with VACUUM ANALYSE + partitions

Hi,

On 2016-05-03 00:05:35 +0200, Fabien COELHO wrote:
> Maybe consider checking for the exclusivity explicitely?

I thought about it, and decided it's not worth it.  Requiring one of
those to be specified seems stringent enough.

> I'm unsure about switching enum to #define, could be an enum still with
> explicit values set, something like:
> 
>   enum {
>     EXTENSION_RETURN_NULL = (1 << 0),
>     ...
>   } extension_behavior;

An enum doesn't have a benefit for a bitmask imo - you can't "legally"
use it as a type for functions accepting the bitmask.

> I'm fuzzy about the _OPEN_DELETED part because it is an oxymoron. Is it
> RECREATE really?

No. The relevant explanation is at the top of the file:*    On disk, a relation must consist of consecutively numbered
segment*   files in the pattern*        -- Zero or more full segments of exactly RELSEG_SIZE blocks each*        --
Exactlyone partial segment of size 0 <= size < RELSEG_SIZE blocks*        -- Optionally, any number of inactive
segmentsof size 0 blocks.*    The full and partial segments are collectively the "active" segments.*    Inactive
segmentsare those that once contained data but are currently*    not needed because of an mdtruncate() operation.  The
reasonfor leaving*    them present at size zero, rather than unlinking them, is that other*    backends and/or the
checkpointermight be holding open file references to*    such segments.  If the relation expands again after
mdtruncate(),such*    that a deactivated segment becomes active again, it is important that*    such file references
stillbe valid --- else data might get written*    out to an unlinked old copy of a segment file that will eventually*
disappear.
 

- Andres