Re: Avoid erroring out when unable to remove or parse logical rewrite files to save checkpoint work
От | Nathan Bossart |
---|---|
Тема | Re: Avoid erroring out when unable to remove or parse logical rewrite files to save checkpoint work |
Дата | |
Msg-id | 20220202183738.GA746893@nathanxps13 обсуждение исходный текст |
Ответ на | Re: Avoid erroring out when unable to remove or parse logical rewrite files to save checkpoint work (Bharath Rupireddy <bharath.rupireddyforpostgres@gmail.com>) |
Ответы |
Re: Avoid erroring out when unable to remove or parse logical rewrite files to save checkpoint work
|
Список | pgsql-hackers |
On Wed, Feb 02, 2022 at 05:19:26PM +0530, Bharath Rupireddy wrote: > On Wed, Feb 2, 2022 at 5:25 AM Nathan Bossart <nathandbossart@gmail.com> wrote: >> However, I'm not sure about the change to ReadDirExtended(). That might be >> okay for CheckPointSnapBuild(), which is just trying to remove old files, >> but CheckPointLogicalRewriteHeap() is responsible for ensuring that files >> are flushed to disk for the checkpoint. If we stop reading the directory >> after an error and let the checkpoint continue, isn't it possible that some >> mappings files won't be persisted to disk? > > Unless I mis-read your above statement, with LOG level in > ReadDirExtended, I don't think we stop reading the files in > CheckPointLogicalRewriteHeap. Am I missing something here? ReadDirExtended() has the following comment: * If elevel < ERROR, returns NULL after any error. With the normal coding * pattern, this will result in falling out of the loop immediately as * though the directory contained no (more) entries. If there is a problem reading the directory, we will LOG and then exit the loop. If we didn't scan through all the entries in the directory, there is a chance that we didn't fsync() all the files that need it. -- Nathan Bossart Amazon Web Services: https://aws.amazon.com
В списке pgsql-hackers по дате отправления: