BUG #8091: No permissions on the table file causing recovery failure

The following bug has been logged on the website:

Bug reference: 8091
Logged by: Hari Babu
Email address: haribabu(dot)kommi(at)huawei(dot)com
PostgreSQL version: 9.2.4
Operating system: Linux
Description:

During the testing of fixed old defect with some altered scenario leads to a
defect.

Fixed old defect description in release 9.1.3:

Avoid crashing when we have problems deleting table files post-commit (Tom
Lane)
Dropping a table should lead to deleting the underlying disk files only
after the transaction commits. In event of failure then (for instance,
because of wrong file permissions)
the code is supposed to just emit a warning message and go on, since it's
too late to abort the transaction. This logic got broken as of release 8.4,

causing such situations to result in a PANIC and an unrestartable database.

New defect scenario:
1. create table.
2. change the file permissions.
3. Drop table.
4. Restart the server leads to recovery failure.

As in the original defect, while replaying drop table redo is causing the
problem as the create table operation is carried out a long back which leads
to WAL not available in the present checkpoint cycle.

The new defect has both create and drop WAL in the checkpoint cycle causing
the create table operation replay failure.