From: | Bharath Rupireddy <bharath(dot)rupireddyforpostgres(at)gmail(dot)com> |
---|---|
To: | "Bossart, Nathan" <bossartn(at)amazon(dot)com> |
Cc: | PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | Re: Avoid erroring out when unable to remove or parse logical rewrite files to save checkpoint work |
Date: | 2022-01-13 06:02:53 |
Message-ID: | CALj2ACVEbN+M-WQ=uGGt8iRW=obkm_8nnqG4mkNiheYvKjH99A@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Thu, Jan 13, 2022 at 3:47 AM Bossart, Nathan <bossartn(at)amazon(dot)com> wrote:
>
> On 12/31/21, 4:44 AM, "Bharath Rupireddy" <bharath(dot)rupireddyforpostgres(at)gmail(dot)com> wrote:
> > Currently the server is erroring out when unable to remove/parse a
> > logical rewrite file in CheckPointLogicalRewriteHeap wasting the
> > amount of work the checkpoint has done and preventing the checkpoint
> > from finishing. This is unlike CheckPointSnapBuild does for snapshot
> > files i.e. it just emits a message at LOG level and continues if it is
> > unable to parse or remove the file. Attaching a small patch applying
> > the same idea to the mapping files.
>
> This seems reasonable to me. AFAICT moving on to other files after an
> error shouldn't cause any problems. In fact, it's probably beneficial
> to try to clean up as much as possible so that the files do not
> continue to build up.
Thanks for the review Nathan!
> The only feedback I have for the patch is that I don't think the new
> comments are necessary.
I borrowed the comments as-is from the CheckPointSnapBuild introduced
by the commit b89e15105. IMO, let the comments be there as they
explain why we are not emitting ERRORs, however I will leave it to the
committer to decide on that.
Regards,
Bharath Rupireddy.
From | Date | Subject | |
---|---|---|---|
Next Message | Bharath Rupireddy | 2022-01-13 06:20:53 | Re: Add checkpoint and redo LSN to LogCheckpointEnd log message |
Previous Message | Tom Lane | 2022-01-13 05:58:17 | Re: Custom Operator for citext LIKE predicates question |