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