I just had a thought about fixing those Windows "permission denied"
problems. The case that we believe we understand is where the bgwriter
is trying to execute a previously-logged fsync request against a table
file that is pending delete --- that is, actually has been unlink()'d,
but some other process is holding an open file reference to it. The
problem is only for fsync, not for write(), because the table drop
sequence always invalidates every shared buffer for the table before
trying to unlink it.
So: maybe the solution is to add a step to the drop sequence, namely
revoking any pending fsync request, before unlink. This would not only
clean up the Windows issue, it'd also let us remove the current hack in
md.c to not complain about an ENOENT failure (which is really hardly any
safer than ignoring EACCES would be, if you want to be honest about it).
The problem is that the ForwardFsyncRequest() mechanism is asynchronous:
currently, a backend could see pending fsync requests that are still in
the shared-memory queue, but there's no way to tell whether the bgwriter
has already absorbed some requests into its private memory. How can a
backend tell the bgwriter to forget about it, and then delay until it
can be sure that the bgwriter won't try it later?
We could have backends put "revoke fsync" requests into the shared queue
and then sleep until they see the queue has been drained ... but there's
not a convenient way to implement that delay, and I hardly want to just
"sleep and retry" during every table drop. It'd probably take at least
one more LWLock, and noticeably more complicated ForwardFsyncRequest()
logic, to make this work.
Thoughts? Is this a reasonable solution path, or is it likely to be a
waste of time? We know that there are causes of "permission denied"
that are not explained by the pending-delete problem.
regards, tom lane
---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match
