Hello Andres,
Fixes it for me too.
Yep, for me too.
I'm not at ease with the part of the API the code is dealing with, so I do
not feel like a competent reviewer. I agree with the "more comments"
suggested by Robert.
I have just a small naming point:
/* ereport if segment not present, create in recovery */
EXTENSION_FAIL,
/* return NULL if not present, create in recovery */
EXTENSION_RETURN_NULL,
/* return NULL if not present */
EXTENSION_REALLY_RETURN_NULL,
/* create new segments as needed */
EXTENSION_CREATE
The comments seem pretty clear, but the naming of these options are more
behavioral than functional somehow (or the reverse?), especially the
RETURN_NULL and REALLY_RETURN_NULL names seemed pretty contrived to me.
There is one context: whether it is in recovery. There are 3 possible
behaviors: whether to error or ignore or create if segment does not
exist.
In recovery it is always create if asked for it must be made available,
maybe it does not exists because of the crash...
If I understand correctly, with flushes kept a long time before being
processed, there is a new state which is "ignore whatever", we do not want
to create a segment for flushing non existing data.
So I would suggest it would be better to name the options closer to the
comments above, something like:
normal / in recovery:
EXTENSION_ERROR_OR_IR_CREATE
EXTENSION_IGNORE_OR_IR_CREATE
EXTENSION_IGNORE
EXTENSION_CREATE
Now, maybe that is too late to try to find a better name for these
options now:-)
--
Fabien.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
