Hannu Krosing <hannu(at)skype(dot)net> writes:
> hel kenal peval, T, 2006-02-28 kell 10:26, kirjutas Tom Lane:
>> The current bgwriter is incapable of looking at catalog contents as
>> such --- it operates only at the level of physical data blocks.
> Would'nt it still be possible to drop a table from below bgwriter ?
The mechanism that handles that is that smgr.c calls
DropRelFileNodeBuffers before physically unlinking the file.
Hence, by the time the unlink happens, there is not any buffer
that the bgwriter might be trying to write into it.
Processes that might try to read in new pages must hold some kind
of lock on the relation the page belongs to, hence they must be
running a transaction. Otherwise there would be a race condition here.
(The process executing the DROP TABLE must hold exclusive lock on the
table, thereby guaranteeing that there is no one trying to read in
new pages from it.)
regards, tom lane
In response to
pgsql-hackers by date
|Next:||From: Tom Lane||Date: 2006-02-28 16:19:02|
|Subject: Re: character encoding in StartupMessage |
|Previous:||From: Martijn van Oosterhout||Date: 2006-02-28 16:14:17|
|Subject: Re: character encoding in StartupMessage|