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 a
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
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
st
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 ForgetDatabaseFsy
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
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 Forget
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
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 OID
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
ForgetDatabas
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, r
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
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.
--
Alvar
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
rep
13 matches
Mail list logo
