Re: [BUGS] Breakage with VACUUM ANALYSE + partitions
От | Fabien COELHO |
---|---|
Тема | Re: [BUGS] Breakage with VACUUM ANALYSE + partitions |
Дата | |
Msg-id | alpine.DEB.2.10.1604252026040.32250@sto обсуждение исходный текст |
Ответ на | Re: [BUGS] Breakage with VACUUM ANALYSE + partitions (Thom Brown <thom@linux.com>) |
Ответы |
Re: [BUGS] Breakage with VACUUM ANALYSE + partitions
|
Список | pgsql-hackers |
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 segmentsas 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.
В списке pgsql-hackers по дате отправления: