rename/unlink handling for Win32

Oh, one more thing. dirmod.c has Win32 source to show the actual hangs
caused by rename/unlink --- just define TEST_VERSION and compile. If
someone wants a binary, let me know.

And sorry I posted to hackers rather than patches, where it belongs.

---------------------------------------------------------------------------

Bruce Momjian wrote:

Here is my approach to the use of rename/unlink on Win32. The full
discussion is at:

http://momjian.postgresql.org/cgi-bin/pgtodo?win32

Basically, rename/unlink will fail if the file is opened. You can move
the open file to another name, but that then requires open to loop in
case the file is missing.

The following patch loops over rename/unlink every 1/10th of second,
printing a warning message after 1 second, and printing a completion
message if a warning message was printed.

I looked at PeerDirect's and SRA's port, and neither provides a better
method. I looked at PeerDirect's and it actually has some conditional
code for rename. For example, it has a signal that is sent to all
backends to inform them to close their open WAL files. I am not sure if
that is required for us because there is some replication stuff in
there that we aren't using. Jan? In a few other places, it allows the
rename to fail.

I am inclined to implement it as shown, then see what delayed
rename/unlinks we get in testing.

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

Bruce Momjian writes:

The following patch loops over rename/unlink every 1/10th of second,
printing a warning message after 1 second, and printing a completion
message if a warning message was printed.

I don't like that; it seems arbitrary. How does the need to wait relate
to other factors, such as the system load?

About the code: The code you placed into pg_config_manual.h must go into
some other header file, probably a separate one that parallels the .c
file. Also, I would prefer if the C files in src/port were named after
the function they implement, so rename.c.

It might also be cleaner if we changed the code to use remove() instead of
unlink(), since the ISO C standard uses the former whereas the latter is
Unix-ish.

--
Peter Eisentraut peter_e@gmx.net

[ Thread moved to patches, where I should have posted it at first.]

Peter Eisentraut wrote:

Bruce Momjian writes:

The following patch loops over rename/unlink every 1/10th of second,
printing a warning message after 1 second, and printing a completion
message if a warning message was printed.

I don't like that; it seems arbitrary. How does the need to wait relate
to other factors, such as the system load?

I wasn't clear --- it basically tries 10 times, not necessarily over one
second, and it doesn't print "1 second" or anything.

The values only control whether it prints anything to the logs --- it
will continue looping until it succeeds. Do you see any other solution?

About the code: The code you placed into pg_config_manual.h must go into
some other header file, probably a separate one that parallels the .c
file. Also, I would prefer if the C files in src/port were named after

You want dirmod.h for two prototypes? If I do that, then am I including
that from pg_config_manual.h or somewhere else?

What we could do is to create a port.h file and pull the other /port
prototypes like fseeko() into that file. Is that what you want?

the function they implement, so rename.c.

But we have rename and unlink in there. I don't think we want two
files, do we? They do almost the same thing. That's why I called it
dirmod.c.

It might also be cleaner if we changed the code to use remove() instead of
unlink(), since the ISO C standard uses the former whereas the latter is
Unix-ish.

I didn't want to get into that for this patch. If someone wants to
rename them across the source code, they are welcome to do that, though
unlink() seems more common than remove() to me.

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073