Re: Avoid erroring out when unable to remove or parse logical rewrite files to save checkpoint work
От | Bharath Rupireddy |
---|---|
Тема | Re: Avoid erroring out when unable to remove or parse logical rewrite files to save checkpoint work |
Дата | |
Msg-id | CALj2ACXKYq4q6xinUNwA=ttQK_5QeSR3oxk6rLv5sW_9Hb28tg@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Avoid erroring out when unable to remove or parse logical rewrite files to save checkpoint work (Nathan Bossart <nathandbossart@gmail.com>) |
Ответы |
Re: Avoid erroring out when unable to remove or parse logical rewrite files to save checkpoint work
|
Список | pgsql-hackers |
On Sat, Apr 9, 2022 at 1:49 AM Nathan Bossart <nathandbossart@gmail.com> wrote: > > On Wed, Mar 30, 2022 at 09:21:30AM -0700, Nathan Bossart wrote: > > Here is an updated patch set. > > rebased Thanks. 0001 - there are many places where lstat/stat is being used - don't we need to replace all or most of them with get_dirent_type? 0002 - I'm not quite happy with this patch, with the change, checkpoint errors out, if it can't remove just a file - the comments there says it all. Is there any strong reason for this change? - /* - * It's not particularly harmful, though strange, if we can't - * remove the file here. Don't prevent the checkpoint from - * completing, that'd be a cure worse than the disease. - */ if (unlink(path) < 0) - { - ereport(LOG, + ereport(ERROR, (errcode_for_file_access(), errmsg("could not remove file \"%s\": %m", path))); - continue; - } Regards, Bharath Rupireddy.
В списке pgsql-hackers по дате отправления: