Re: standby recovery fails (tablespace related) (tentative patch and discussion)
Robert Haas <robertmhaas@gmail.com>
From: Robert Haas <robertmhaas@gmail.com>
To: Alvaro Herrera <alvherre@alvh.no-ip.org>
Cc: Kyotaro Horiguchi <horikyota.ntt@gmail.com>,
Michael Paquier <michael@paquier.xyz>, Julien Rouhaud <rjuju123@gmail.com>, "pgsql-hackers@postgresql.org" <pgsql-hackers@postgresql.org>
Date: 2022-03-28T16:17:50Z
Lists: pgsql-hackers
On Mon, Mar 21, 2022 at 3:02 PM Alvaro Herrera <alvherre@alvh.no-ip.org> wrote: > > 2. Why not instead change the code so that the operation can succeed, > > by creating the prerequisite parent directories? Do we not have enough > > information for that? I'm not saying that we definitely should do it > > that way rather than this way, but I think we do take that approach in > > some cases. > > It seems we can choose freely between these two implementations -- I > mean I don't see any upsides or downsides to either one. What got committed here feels inconsistent to me. Suppose we have a checkpoint, and then a series of operations that touch a tablespace, and then a drop database and drop tablespace. If the first operation happens to be CREATE DATABASE, then this patch is going to fix it by skipping the operation. However, if the first operation happens to be almost anything else, the way it's going to reference the dropped tablespace is via a block reference in a WAL record of a wide variety of types. That's going to result in a call to XLogReadBufferForRedoExtended() which will call XLogReadBufferExtended() which will do smgrcreate(smgr, forknum, true) which will in turn call TablespaceCreateDbspace() to fill in all the missing directories. I don't think that's very good. It would be reasonable to decide that we're never going to create the missing directories and instead just remember that they were not found so we can do a cross check. It's also reasonable to just create the directories on the fly. But doing a mix of those systems doesn't really seem like the right idea - particularly because it means that the cross-check system is probably not very effective at finding actual problems in the code. Am I missing something here? -- Robert Haas EDB: http://www.enterprisedb.com
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