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
 *              -- Exactly one partial segment of size 0 <= size < RELSEG_SIZE 
 *              -- Optionally, any number of inactive segments of size 0 blocks.
 *      The full and partial segments are collectively the "active" segments.
 *      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 
 *      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.

- Andres

Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:

Reply via email to