Tom Lane wrote:
Heikki Linnakangas [EMAIL PROTECTED] writes:
Patch attached that does the three changes we've talked about:'
- make ForgetDatabaseFsyncRequests forget unlink requests as well
- make rmtree() not fail on ENOENT
- force checkpoint on in dropdb on all platforms
This looks fine as
Tom Lane wrote:
Heikki Linnakangas [EMAIL PROTECTED] writes:
Tom Lane wrote:
ISTM that we must fix the bgwriter so that ForgetDatabaseFsyncRequests
causes PendingUnlinkEntrys for the doomed DB to be thrown away too.
Because of the asynchronous nature of ForgetDatabaseFsyncRequests, this
Heikki Linnakangas [EMAIL PROTECTED] writes:
Patch attached that does the three changes we've talked about:'
- make ForgetDatabaseFsyncRequests forget unlink requests as well
- make rmtree() not fail on ENOENT
- force checkpoint on in dropdb on all platforms
This looks fine as far as it goes,
Tom Lane wrote:
ISTM that we must fix the bgwriter so that ForgetDatabaseFsyncRequests
causes PendingUnlinkEntrys for the doomed DB to be thrown away too.
This should prevent the unlink-live-data scenario, I think.
Even then, concurrent deletion attempts are probably possible (since
Heikki Linnakangas [EMAIL PROTECTED] writes:
Florian suggested a scheme where the xid and epoch is embedded in the
filename, but that's unnecessarily complex. We could just make
relfilenode a 64-bit integer. 2^64 should be enough for everyone.
Doesn't fix the problem unless DB and TS OIDs
Tom Lane wrote:
Heikki Linnakangas [EMAIL PROTECTED] writes:
Florian suggested a scheme where the xid and epoch is embedded in the
filename, but that's unnecessarily complex. We could just make
relfilenode a 64-bit integer. 2^64 should be enough for everyone.
Doesn't fix the problem unless
Tom Lane wrote:
Actually ... what if the same DB OID and relfilenode get re-made before
the checkpoint? Then we'd be unlinking live data. This is improbable
but hardly less so than the scenario the PendingUnlinkEntry code was
put in to prevent.
ISTM that we must fix the bgwriter so that
Heikki Linnakangas [EMAIL PROTECTED] writes:
Tom Lane wrote:
ISTM that we must fix the bgwriter so that ForgetDatabaseFsyncRequests
causes PendingUnlinkEntrys for the doomed DB to be thrown away too.
Because of the asynchronous nature of ForgetDatabaseFsyncRequests, this
still isn't enough,
Tom Lane wrote:
Heikki Linnakangas [EMAIL PROTECTED] writes:
Tom Lane wrote:
ISTM that we must fix the bgwriter so that ForgetDatabaseFsyncRequests
causes PendingUnlinkEntrys for the doomed DB to be thrown away too.
Because of the asynchronous nature of
Over the last couple days I twice saw complaints like this during
DROP DATABASE:
WARNING: could not remove file or directory base/80750/80825: No such file
or directory
WARNING: could not remove database directory base/80750
I poked at it for awhile and was eventually able to extract a
Tom Lane wrote:
I think that it should be coded
to ignore ENOENT the same as the bgwriter does, and that it should press
on and keep trying to delete things even if it gets a failure.
Perhaps, if it gets ENOENT, record this fact -- and after rmtree
returns, retry the whole thing.
--
Alvaro
Alvaro Herrera [EMAIL PROTECTED] writes:
Tom Lane wrote:
I think that it should be coded
to ignore ENOENT the same as the bgwriter does, and that it should press
on and keep trying to delete things even if it gets a failure.
Perhaps, if it gets ENOENT, record this fact -- and after rmtree
Tom Lane wrote:
Alvaro Herrera [EMAIL PROTECTED] writes:
Tom Lane wrote:
I think that it should be coded
to ignore ENOENT the same as the bgwriter does, and that it should press
on and keep trying to delete things even if it gets a failure.
Perhaps, if it gets ENOENT,
13 matches
Mail list logo
