From: "Tom Lane" <[EMAIL PROTECTED]>
I suggested that here
> http://archives.postgresql.org/pgsql-hackers/2007-01/msg00642.php
> but have received no feedback about it ...
I'm sorry, I missed it.
From: "Tom Lane" <[EMAIL PROTECTED]>
> Magnus Hagander <[EMAIL PROTECTED]> writes:
>> Tom Lane wrote:
>>> So: maybe the solution is to add a step to the drop sequence,
namely
>>> revoking any pending fsync request, before unlink.
>
>> Perhaps we could have the bgwrite check the queue *if* it gets the
>> ENOENT/EACCESS error and then re-check the queue for drops on that
file?
>
> I've committed a tentative patch along these lines to HEAD. Please
> test.
I agree with Magnus-san's suggestion, too.
Though I'm willing to test, I'm not familiar with building on Windows
yet and do not have enogh time for other works right now. If someone
builds and gives me the new postgres.exe, I'll put it on my 8.2
installation and test. Or, could anyone do the following? These are
what I did in yesterday's test.
1. Open two psql sessions. Let me call those session1 and session2.
2. On session1, execute:
create table a (c int);
insert into a values(1);
3. On session2, execute:
select * from a;
4. On session1, execute:
drop table a;
checkpoint;
Checkpoint command here reported an error yesterday. If Tom-san's
patch is effective, it should not fail and no messages are put in the
event log.
---------------------------(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
