Re: [PATCHES] [pgsql-hackers-win32] win32 open patch for held unlink
Allow unlink/rename of files open by another process on Win32, using a special Win32 open flag FILE_SHARE_DELETE. Patch applied. Thanks. --- Claudio Natoli wrote: > > Revised patch, for application to HEAD [open.c destined for src/port] > > --- > Certain disclaimers and policies apply to all email sent from Memetrics. > For the full text of these disclaimers and policies see > href="http://www.memetrics.com/emailpolicy.html";>http://www.memetrics.com/em > ailpolicy.html > > [ Attachment, skipping... ] [ Attachment, skipping... ] > > ---(end of broadcast)--- > TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED] -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [PATCHES] [pgsql-hackers-win32] win32 open patch for held unlink
Revised patch, for application to HEAD [open.c destined for src/port] --- Certain disclaimers and policies apply to all email sent from Memetrics. For the full text of these disclaimers and policies see http://www.memetrics.com/emailpolicy.html";>http://www.memetrics.com/em ailpolicy.html open.patch Description: Binary data open.c Description: Binary data ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [PATCHES] [pgsql-hackers-win32] win32 open patch for held unlink
> Agreed, we still need dirmod.c in case someone has opened it using a non-unix mode. Ok. Wanted to make sure I was on the same page. > My only question was whether this new mode makes rename > possible on a target file opened by another backend. Looks good. Wrote a pair of 2 liner driver programs to test. Renaming fails when the file is open()'d, but proceeds correctly when win32_open()'d. Cheers, Claudio --- Certain disclaimers and policies apply to all email sent from Memetrics. For the full text of these disclaimers and policies see http://www.memetrics.com/emailpolicy.html";>http://www.memetrics.com/em ailpolicy.html ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [PATCHES] [pgsql-hackers-win32] win32 open patch for held unlink
Claudio Natoli wrote: > > > > Claudio, how does this handle renames if the file is open by someone > > else? Does this remove the need to loop over the rename? > > To be honest, I don't know that it does. [Will report back later.] > > Two points though: > > a) This could doesn't alleviate the needs for dirmod.c, as far as I'm aware. > That seems to be there for a different reason, namely that there appears to > be some timing issue between creating a file and issuing an unlink/rename. > > b) Do we have a case where rename's can block because of the file being held > open by another process? I haven't tripped over this yet... Agreed, we still need dirmod.c in case someone has opened it using a non-unix mode. My only question was whether this new mode makes rename possible on a target file opened by another backend. -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [PATCHES] [pgsql-hackers-win32] win32 open patch for held unlink
> a) This could doesn't alleviate the needs for dirmod.c, as This CODE doesn't alleviate the NEED for... Sheesh, Claudio --- Certain disclaimers and policies apply to all email sent from Memetrics. For the full text of these disclaimers and policies see http://www.memetrics.com/emailpolicy.html";>http://www.memetrics.com/em ailpolicy.html ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [PATCHES] [pgsql-hackers-win32] win32 open patch for held unlink
> Claudio, how does this handle renames if the file is open by someone > else? Does this remove the need to loop over the rename? To be honest, I don't know that it does. [Will report back later.] Two points though: a) This could doesn't alleviate the needs for dirmod.c, as far as I'm aware. That seems to be there for a different reason, namely that there appears to be some timing issue between creating a file and issuing an unlink/rename. b) Do we have a case where rename's can block because of the file being held open by another process? I haven't tripped over this yet... Cheers, Claudio --- Certain disclaimers and policies apply to all email sent from Memetrics. For the full text of these disclaimers and policies see http://www.memetrics.com/emailpolicy.html";>http://www.memetrics.com/em ailpolicy.html ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
