Re: standby recovery fails (tablespace related) (tentative patch and discussion)
Kyotaro HORIGUCHI <horiguchi.kyotaro@lab.ntt.co.jp>
From: Kyotaro HORIGUCHI <horiguchi.kyotaro@lab.ntt.co.jp>
To: pguo@pivotal.io
Cc: apraveen@pivotal.io, pgsql-hackers@postgresql.org
Date: 2019-04-22T07:40:27Z
Lists: pgsql-hackers
Attachments
- ignore_dir_create_error_before_consistency_v2.patch (text/x-patch) patch v2
Oops! The comment in the previous patch is wrong. At Mon, 22 Apr 2019 16:15:13 +0900 (Tokyo Standard Time), Kyotaro HORIGUCHI <horiguchi.kyotaro@lab.ntt.co.jp> wrote in <20190422.161513.258021727.horiguchi.kyotaro@lab.ntt.co.jp> > At Mon, 22 Apr 2019 12:36:43 +0800, Paul Guo <pguo@pivotal.io> wrote in <CAEET0ZGpUrMGUzfyzVF9FuSq+zb=QovYa2cvyRnDOTvZ5vXxTw@mail.gmail.com> > > Please see my replies inline. Thanks. > > > > On Fri, Apr 19, 2019 at 12:38 PM Asim R P <apraveen@pivotal.io> wrote: > > > > > On Wed, Apr 17, 2019 at 1:27 PM Paul Guo <pguo@pivotal.io> wrote: > > > > > > > > create db with tablespace > > > > drop database > > > > drop tablespace. > > > > > > Essentially, that sequence of operations causes crash recovery to fail > > > if the "drop tablespace" transaction was committed before crashing. > > > This is a bug in crash recovery in general and should be reproducible > > > without configuring a standby. Is that right? > > > > > > > No. In general, checkpoint is done for drop_db/create_db/drop_tablespace on > > master. > > That makes the file/directory update-to-date if I understand the related > > code correctly. > > For standby, checkpoint redo does not ensure that. > > That's right partly. As you must have seen, fast shutdown forces > restartpoint for the last checkpoint and it prevents the problem > from happening. Anyway it seems to be a problem. > > > > Your patch creates missing directories in the destination. Don't we > > > need to create the tablespace symlink under pg_tblspc/? I would > > > > > > > 'create db with tablespace' redo log does not include the tablespace real > > directory information. > > Yes, we could add in it into the xlog, but that seems to be an overdesign. > > But I don't think creating directory that is to be removed just > after is a wanted solution. The directory most likely to be be > removed just after. > > > > prefer extending the invalid page mechanism to deal with this, as > > > suggested by Ashwin off-list. It will allow us to avoid creating > > > > directories and files only to remove them shortly afterwards when the > > > drop database and drop tablespace records are replayed. > > > > > > > > 'invalid page' mechanism seems to be more proper for missing pages of a > > file. For > > missing directories, we could, of course, hack to use that (e.g. reading > > any page of > > a relfile in that database) to make sure the tablespace create code > > (without symlink) > > safer (It assumes those directories will be deleted soon). > > > > More feedback about all of the previous discussed solutions is welcome. > > It doesn't seem to me that the invalid page mechanism is > applicable in straightforward way, because it doesn't consider > simple file copy. > > Drop failure is ignored any time. I suppose we can ignore the > error to continue recovering as far as recovery have not reached > consistency. The attached would work *at least* your case, but I > haven't checked this covers all places where need the same > treatment. The comment for the new function XLogMakePGDirectory is wrong: + * There is a possibility that WAL replay causes a creation of the same + * directory left by the previous crash. Issuing ERROR prevents the caller + * from continuing recovery. The correct one is: + * There is a possibility that WAL replay causes an error by creation of a + * directory under a directory removed before the previous crash. Issuing + * ERROR prevents the caller from continuing recovery. It is fixed in the attached. regards. -- Kyotaro Horiguchi NTT Open Source Software Center
Commits
-
Improve recently-added test reliability
- ad0e08394746 10.22 landed
- 9d5c96d9be64 14.5 landed
- 8c5d9ccca967 13.8 landed
- 782e5631e5dd 12.12 landed
- 772e6383d1da 11.17 landed
- 6c1c9f88ad54 16.0 landed
- 6390bc740f90 15.0 landed
-
Fix new recovery test for log_error_verbosity=verbose case
- b998196bb59a 16.0 cited
-
Fix test instability
- fcd72cf295c3 11.17 landed
- 7cfe688dee86 13.8 landed
- 798d64488ca9 15.0 landed
- 6ffaf75a8001 10.22 landed
- 658e5d53459f 12.12 landed
- 59be1c942a47 16.0 landed
- 4d8d85740c02 14.5 landed
-
Fix replay of create database records on standby
- 9e4f914b5eba 16.0 landed
- a3aacb7cbfc7 14.5 landed
- 9a7e26b9c2ac 13.8 landed
- 8348413dbded 15.0 landed
- 6d20f8c5a46a 12.12 landed
- 5a10c262fc60 11.17 landed
- 084318c33a1f 10.22 landed
- ffd28516e699 14.3 landed
- 50e3ed8e9172 13.7 landed
- 49d9cfc68bf4 15.0 landed
-
Allow "in place" tablespaces.
- 961cab0a5a90 14.5 landed
- 16e7a8fd8e97 13.8 landed
- ca347f5433ed 12.12 landed
- 7bdbbb87340f 10.22 landed
- 258c896418bf 11.17 landed
-
Fix get_dirent_type() for Windows junction points.
- fee0165fc1cf 14.5 landed
- 6d306ab73168 15.0 landed
- 9d3444dcce4d 16.0 landed
-
Revert "Fix replay of create database records on standby"
- bf902c13930c 15.0 landed
- adc943b4e1fe 14.3 landed
- a54ed2de80ec 13.7 landed
-
Add end-to-end testing of pg_basebackup's tar-format output.
- 081876d75ea1 14.0 cited
-
Make DROP DATABASE command generate less WAL records.
- e6d8069522c8 13.0 cited
-
Consolidate methods for translating a Perl path to a Windows path.
- 660a2b19038b 12.0 cited