BUG #15207: In crash recovery, SyncDataDirectory() will fall into recursion trap
The following bug has been logged on the website:
Bug reference: 15207
Logged by: bret shao
Email address: bret.shao@outlook.com
PostgreSQL version: 9.5.7
Operating system: windows 10
Description:
Hi，
I'm R&D engineer of HighGo Co. Ltd.
i run the test case as below.
I install the PG at location "D:\highgo\database\", then i create a table
space with "create tablespace spacetest location 'D:\highgo\database\'"
then make the PG crash.
In crash recovery, SyncDataDirectory() will be called in function
StartupXLOG(), in this function will call walkdir() to fsync the dir and its
contents.
Because of that the table space spacetest is point to data dir of PG, here
is 'D:\highgo\database\',
so function walkdir will fall into recursion trap due to lstat is defined to
stat in windows environment when the pg_tblspc is handled.
Due to windows restrict the length of filename to 255, so the recursion will
terminate when the length of file name reach 255.
Although， this issue will not affect the startup of PG but i think this
issue should be considered to fix.
the logs are showed as below.
2018-05-23 09:39:46 HKTLOG: 58P01: could not stat file
"./pg_tblspc/16384/pg_tblspc/16384/pg_tblspc/16384/pg_tblspc/16384/pg_tblspc/16384/pg_tblspc/16384/pg_tblspc/16384/pg_tblspc/16384/pg_tblspc/16384/pg_tblspc/16384/pg_tblspc/16384/pg_tblspc/16384/hgdb_log/postgresql-2018-05-23_082809.log":
No such file or directory
2018-05-23 09:39:46 HKTLOG: 58P01: could not stat file
.........
2018-05-23 09:43:24 HKTLOG: 58P01: could not stat file
"pg_tblspc/16384/pg_tblspc/16384/pg_tblspc/16384/pg_tblspc/16384/pg_tblspc/16384/pg_tblspc/16384/pg_tblspc/16384/pg_tblspc/16384/pg_tblspc/16384/pg_tblspc/16384/pg_tblspc/16384/pg_tblspc/16384/pg_tblspc/16384/pg_xlog/archive_status":
No such file or directory
2018-05-23 09:43:25 HKTLOG: 00000: database system was not properly shut
down; automatic recovery in progress
2018-05-23 09:43:25 HKTLOG: 00000: invalid record length at 0/1743418
2018-05-23 09:43:25 HKTLOG: 00000: redo is not required
2018-05-23 09:43:25 HKTLOG: 00000: MultiXact member wraparound protections
are now enabled
2018-05-23 09:43:25 HKTLOG: 00000: database system is ready to accept
connections
2018-05-23 09:43:25 HKTLOG: 00000: autovacuum launcher started
thanks.
Br.
Bret
=?utf-8?q?PG_Bug_reporting_form?= <noreply@postgresql.org> writes:
I install the PG at location "D:\highgo\database\", then i create a table
space with "create tablespace spacetest location 'D:\highgo\database\'"
This is pilot error isn't it? It's certainly hard to see what would be
the value of making a tablespace pointing at the data directory itself.
Offhand, I think we do not support tablespaces that are physically inside
the data directory, either.
I think there's been some discussion of having CREATE TABLESPACE try to
detect and reject such cases. But it would be easy enough to fool it
(through symlinks, variant path spellings, etc), that people haven't been
excited about adding such a check.
regards, tom lane
On Wed, May 23, 2018 at 09:36:33AM -0400, Tom Lane wrote:
Offhand, I think we do not support tablespaces that are physically inside
the data directory, either.
pg_upgrade and pg_basebackup work funnily in such cases.
I think there's been some discussion of having CREATE TABLESPACE try to
detect and reject such cases. But it would be easy enough to fool it
(through symlinks, variant path spellings, etc), that people haven't been
excited about adding such a check.
33cb8ff6 has added a warning when doing this operation. Here is the
related thread:
/messages/by-id/CA+TgmobZLyLU8tFCbMqbjMWB6t+=ERaDo820uQEJCVAQK_Paow@mail.gmail.com
--
Michael
I have got the history of this issue.
Thanks.
Br.
Bret
发送自 Windows 10 版邮件<https://go.microsoft.com/fwlink/?LinkId=550986>应用
发件人: Michael Paquier<mailto:michael@paquier.xyz>
发送时间: 2018年5月23日 22:03
收件人: Tom Lane<mailto:tgl@sss.pgh.pa.us>
抄送: bret.shao@outlook.com<mailto:bret.shao@outlook.com>; pgsql-bugs@lists.postgresql.org<mailto:pgsql-bugs@lists.postgresql.org>
主题: Re: BUG #15207: In crash recovery, SyncDataDirectory() will fall into recursion trap
On Wed, May 23, 2018 at 09:36:33AM -0400, Tom Lane wrote:
Offhand, I think we do not support tablespaces that are physically inside
the data directory, either.
pg_upgrade and pg_basebackup work funnily in such cases.
I think there's been some discussion of having CREATE TABLESPACE try to
detect and reject such cases. But it would be easy enough to fool it
(through symlinks, variant path spellings, etc), that people haven't been
excited about adding such a check.
33cb8ff6 has added a warning when doing this operation. Here is the
related thread:
/messages/by-id/CA+TgmobZLyLU8tFCbMqbjMWB6t+=ERaDo820uQEJCVAQK_Paow@mail.gmail.com
--
Michael