Re: Avoid erroring out when unable to remove or parse logical rewrite files to save checkpoint work
Tom Lane <tgl@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Thomas Munro <thomas.munro@gmail.com>
Cc: Nathan Bossart <nathandbossart@gmail.com>,
Bharath Rupireddy <bharath.rupireddyforpostgres@gmail.com>,
Andres Freund <andres@anarazel.de>,
"Bossart,
Nathan" <bossartn@amazon.com>,
Julien Rouhaud <rjuju123@gmail.com>,
PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Date: 2022-08-09T03:50:18Z
Lists: pgsql-hackers
Thomas Munro <thomas.munro@gmail.com> writes: > On Tue, Aug 9, 2022 at 3:27 PM Tom Lane <tgl@sss.pgh.pa.us> wrote: >> I have not tried to analyze the error-handling properties of 0001, >> but if it's being equally cavalier then it shouldn't be committed >> either. > 0001 does introduce new errors, as mentioned in the commit message, in > the form of elevel ERROR passed into get_dirent_type(), which might be > thrown if your OS has no d_type and lstat() fails (also if you asked > to follow symlinks, but in those cases errors were already thrown). > But in those cases, it seems at least a little fishy that we ignored > errors from the existing lstat(). Hmmm ... I'll grant that ignoring lstat errors altogether isn't great. But should the replacement behavior be elog-LOG-and-press-on, or elog-ERROR-and-fail-the-surrounding-operation? I'm not in any hurry to believe that the latter is more appropriate without some analysis of what the callers are doing. The bottom line here is that I'm distrustful of behavioral changes introduced to simplify refactoring rather than to solve a live problem. regards, tom lane
Commits
-
Expand the use of get_dirent_type(), shaving a few calls to stat()/lstat()
- bfb9dfd93720 16.0 landed
-
fsync pg_logical/mappings in CheckPointLogicalRewriteHeap().
- fd48e5f5d3a1 13.6 landed
- f862cc09fad1 10.20 landed
- 2c15b29f7c22 11.15 landed
- 2b7dbe4bd587 14.2 landed
- 1c6d055ba77a 12.10 landed
- 1fabec7d7c38 15.0 landed
-
Introduce logical decoding.
- b89e151054a0 9.4.0 cited