Unwanted LOG during recovery of DROP TABLESPACE REDO
I found and fixed a bug that causes recovery (crash recovery , PITR) to throw unwanted LOG message if the tablespace symlink is not found during the processing of DROP TABLESPACE redo.
LOG: could not remove symbolic link "pg_tblspc/16384": No such file or directory
To Reproduce the issue:
1. Start the server.
2. Create a tablespace.
3. Perform Checkpoint.
4. Drop tablespace.
5. Stop server using immediate mode.
6. Start server : At this stage, recovery throw log message as mentioned above.
Reason is that DROP TABLESPACE has already removed symlink and again it is being tried to remove during recovery.
As it is very much possible that DROP TABLESPACE was successful and cleaned up the file before server crashed. So this should be considered as valid scenario and no need to throw
any LOG in such case. In case of processing of CREATE TABLESPACE redo, same is already handled.
I will add this to 2014-08 CF for review.
Thanks and Regards,
Kumar Rajeev Rastogi
Attachments:
rec_issue_with_drop_tblspc_redo.patchapplication/octet-stream; name=rec_issue_with_drop_tblspc_redo.patchDownload
*** a/src/backend/commands/tablespace.c
--- b/src/backend/commands/tablespace.c
***************
*** 780,785 **** destroy_tablespace_directories(Oid tablespaceoid, bool redo)
--- 780,788 ----
* WAL replay (see TablespaceCreateDbspace), and it is also the case on
* Windows where junction points lstat() as directories.
*
+ * Also deal with the possibility that symlink is already removed as part
+ * of DROP TABLESPACE redo.
+ *
* Note: in the redo case, we'll return true if this final step fails;
* there's no point in retrying it. Also, ENOENT should provoke no more
* than a warning.
***************
*** 801,810 **** remove_symlink:
{
int saved_errno = errno;
! ereport(redo ? LOG : (saved_errno == ENOENT ? WARNING : ERROR),
! (errcode_for_file_access(),
! errmsg("could not remove symbolic link \"%s\": %m",
! linkloc)));
}
}
--- 804,825 ----
{
int saved_errno = errno;
! /*
! * If file does not exist incase of DROP TABLESPACE redo,then no
! * need to throw any LOG as it is very much valid scenario.
! */
! if (saved_errno != ENOENT)
! {
! ereport(redo ? LOG : ERROR),
! (errcode_for_file_access(),
! errmsg("could not remove symbolic link \"%s\": %m",
! linkloc)));
! }
! else if (!redo)
! ereport(WARNING,
! (errcode_for_file_access(),
! errmsg("could not remove symbolic link \"%s\": %m",
! linkloc)));
}
}
Rajeev rastogi <rajeev.rastogi@huawei.com> writes:
I found and fixed a bug that causes recovery (crash recovery , PITR) to throw unwanted LOG message if the tablespace symlink is not found during the processing of DROP TABLESPACE redo.
LOG: could not remove symbolic link "pg_tblspc/16384": No such file or directory
I don't think that's a bug: it's the designed behavior. Why should we
complicate the code to not print a log message in a situation where
it's unclear if the case is expected or not?
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On 7/16/14 4:33 PM, Tom Lane wrote:
Rajeev rastogi <rajeev.rastogi@huawei.com> writes:
I found and fixed a bug that causes recovery (crash recovery , PITR) to throw unwanted LOG message if the tablespace symlink is not found during the processing of DROP TABLESPACE redo.
LOG: could not remove symbolic link "pg_tblspc/16384": No such file or directoryI don't think that's a bug: it's the designed behavior. Why should we
complicate the code to not print a log message in a situation where
it's unclear if the case is expected or not?
I agree with Tom here; this doesn't seem like an improvement.
.marko
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On 08/15/2014 12:31 PM, Marko Tiikkaja wrote:
On 7/16/14 4:33 PM, Tom Lane wrote:
Rajeev rastogi <rajeev.rastogi@huawei.com> writes:
I found and fixed a bug that causes recovery (crash recovery , PITR) to throw unwanted LOG message if the tablespace symlink is not found during the processing of DROP TABLESPACE redo.
LOG: could not remove symbolic link "pg_tblspc/16384": No such file or directoryI don't think that's a bug: it's the designed behavior. Why should we
complicate the code to not print a log message in a situation where
it's unclear if the case is expected or not?I agree with Tom here; this doesn't seem like an improvement.
Well, for comparison, we also silently ignore non-existent files when
replaying a "DROP TABLE". I could go either way myself, but this is
clearly a very minor thing, and we have two -1's, so I'm marking this as
"Rejected" in the commitfest.
Thanks anyway!
- Heikki
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers