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 22:05:35
Message-ID: alpine.DEB.2.10.1605022346490.927@sto
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs pgsql-hackers


Hello Andres,

>>> 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?

My 0,02€.

Not tested, just a few comments on the patch from someone which does not
understand this API deep down... Nevertheless:

I agree that it is looks better than "EXTENSION_REALLY_RETURNS_NULL", that
I did not like much.

There are 3 possible behaviors on extension, but coding them as bits does
not make their exclusivity clear. Now mixing numbers & bits does not seem
advisable either.

Maybe consider checking for the exclusivity explicitely?

EXTENSION_BEHAVIORS = (EXTENSION_RETURN_NULL | ..._FAIL | ..._CREATE);

And then the Assert can check for the exclusivity:

int behavior = option & EXTENSION_BEHAVIORS;
Assert( (behavior == EXTENSION_RETURN_NULL) ||
(behavior == ..._FAIL) ||
(behavior == ..._CREATE));

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;

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

--
Fabien.

In response to

Responses

Browse pgsql-bugs by date

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

Browse pgsql-hackers by date

  From Date Subject
Next Message Andres Freund 2016-05-02 22:14:19 Re: [BUGS] Breakage with VACUUM ANALYSE + partitions
Previous Message David Fetter 2016-05-02 21:59:07 Re: Naming of new tsvector functions