Re: Avoid erroring out when unable to remove or parse logical rewrite files to save checkpoint work
Bharath Rupireddy <bharath.rupireddyforpostgres@gmail.com>
From: Bharath Rupireddy <bharath.rupireddyforpostgres@gmail.com>
To: Julien Rouhaud <rjuju123@gmail.com>
Cc: Andres Freund <andres@anarazel.de>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Date: 2022-01-15T14:28:28Z
Lists: pgsql-hackers
On Sat, Jan 15, 2022 at 2:59 PM Julien Rouhaud <rjuju123@gmail.com> wrote: > > Hi, > > On Sat, Jan 15, 2022 at 02:04:12PM +0530, Bharath Rupireddy wrote: > > > > We had an issue where there were many mapping files generated during > > the crash recovery and end-of-recovery checkpoint was taking a lot of > > time. We had to manually intervene and delete some of the mapping > > files (although it may not sound sensible) to make end-of-recovery > > checkpoint faster. Because of the race condition between manual > > deletion and checkpoint deletion, the unlink error occurred which > > crashed the server and the server entered the recovery again wasting > > the entire earlier recovery work. > > Maybe I'm missing something but wouldn't > https://commitfest.postgresql.org/36/3448/ better solve the problem? The error can cause the new background process proposed there in that thread to restart, which is again costly. Since we have LOG-only and continue behavior in CheckPointSnapBuild already, having the same behavior for CheckPointLogicalRewriteHeap helps a lot. Regards, Bharath Rupireddy.
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