Re: Avoid erroring out when unable to remove or parse logical rewrite files to save checkpoint work - Mailing list pgsql-hackers

From Bharath Rupireddy
Subject Re: Avoid erroring out when unable to remove or parse logical rewrite files to save checkpoint work
Date
Msg-id CALj2ACV2boDSpQGYvp5Won6qfJgwdpeFMJTO-4Z7dKZy8UAH2Q@mail.gmail.com
Whole thread Raw
In response to Re: Avoid erroring out when unable to remove or parse logical rewrite files to save checkpoint work  (Michael Paquier <michael@paquier.xyz>)
Responses Re: Avoid erroring out when unable to remove or parse logical rewrite files to save checkpoint work
Re: Avoid erroring out when unable to remove or parse logical rewrite files to save checkpoint work
List pgsql-hackers
On Thu, Aug 25, 2022 at 5:51 PM Michael Paquier <michael@paquier.xyz> wrote:
>
> FWIW, the changes in reorderbuffer.c for
> ReorderBufferCleanupSerializedTXNs() reduce the code readability, in
> my opinion, so that's one less argument in favor of this change.

Agreed. I reverted the changes.

> The gain in ParseConfigDirectory() is kind of cool.
> pg_tzenumerate_next(), copydir(), RemoveXlogFile()
> StartupReplicationSlots(), CheckPointLogicalRewriteHeap() and
> RemovePgTempFilesInDir() seem fine, as well.  At least these avoid
> extra lstat() calls when the file type is unknown, which would be only
> a limited number of users where some of the three DT_* are missing
> (right?).

Yes, the idea is to avoid lstat() system calls when possible.

PSA v17 patch with reorderbuffer.c changes reverted.

-- 
Bharath Rupireddy
RDS Open Source Databases: https://aws.amazon.com/rds/postgresql/

Attachment

pgsql-hackers by date:

Previous
From: Bharath Rupireddy
Date:
Subject: Re: pg_stat_wal: tracking the compression effect
Next
From: Amit Kapila
Date:
Subject: Re: [BUG] Logical replication failure "ERROR: could not map filenode "base/13237/442428" to relation OID" with catalog modifying txns