Re: [BUGS] Breakage with VACUUM ANALYSE + partitions

From: Andres Freund <andres(at)anarazel(dot)de>
To: Fabien COELHO <coelho(at)cri(dot)ensmp(dot)fr>
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-03 23:48:10
Message-ID: 20160503234810.vzbxwxq4jincgdng@alap3.anarazel.de
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs pgsql-hackers

Hi,

On 2016-05-03 07:24:46 +0200, Fabien COELHO wrote:
> >>I'm unsure about switching enum to #define, could be an enum still with
> >>explicit values set, something like:
> >
> >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 do not understand. I suggested to use enum to enumerate the bitmask
> constants, ISTM that it does not preclude to use it as a bitmask as you do,
> it is just a replacement of the #define? The type constraint on the enum
> does not disallow bitmasking values, I checked with both gcc & clang.

There's not really a point in using an enum if you use neither the type
(which you shouldn't because if you or the bitmask value you have types
outside the range of the enum), nor the autogenerated numbers. Anyway
seems fairly unimportant.

> >>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:
>
> [...]
>
> >* -- Optionally, any number of inactive segments of size 0 blocks.
> >* Inactive segments are those that once contained data but are currently
> >* not needed because of an mdtruncate() operation. The reason for leaving
> >* them present at size zero, rather than unlinking them, is that other
> >* backends and/or the checkpointer might 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 still be valid --- else data might get written
> >* out to an unlinked old copy of a segment file that will eventually
> >* disappear.
>
> Ok.
>
> Then should it be _OPEN_INACTIVE[TED] or _OPEN_TRUNCATED rather than
> _OPEN_DELETED, which is contradictory?

Well, TRUNCATED doesn't entirely work, there's I think some cases where
this currently also applies to deleted relations. I kind of like the
unintuitive sounding name, because it's really a dangerous options (any
further mdnblocks will be wrong).

Andres

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message Fabien COELHO 2016-05-04 05:46:42 Re: [BUGS] Breakage with VACUUM ANALYSE + partitions
Previous Message Fabien COELHO 2016-05-03 05:24:46 Re: [BUGS] Breakage with VACUUM ANALYSE + partitions

Browse pgsql-hackers by date

  From Date Subject
Next Message David Rowley 2016-05-04 00:17:58 Re: pg9.6 segfault using simple query (related to use fk for join estimates)
Previous Message Craig Ringer 2016-05-03 23:25:43 Re: what to revert