Re: [HACKERS] rename/unlink handling for Win32

Поиск
Список
Период
Сортировка
От Bruce Momjian
Тема Re: [HACKERS] rename/unlink handling for Win32
Дата
Msg-id 200304211435.h3LEZKU06792@candle.pha.pa.us
обсуждение исходный текст
Список pgsql-patches
[ 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
Index: configure.in
===================================================================
RCS file: /cvsroot/pgsql-server/configure.in,v
retrieving revision 1.242
diff -c -c -r1.242 configure.in
*** configure.in    6 Apr 2003 22:45:22 -0000    1.242
--- configure.in    21 Apr 2003 14:24:02 -0000
***************
*** 856,863 ****
  esac

  # Solaris has a very slow qsort in certain cases, so we replace it.
! case $host_os in
!   solaris*) AC_LIBOBJ(qsort) ;;
  esac

  # On HPUX 9, rint() is not in regular libm.a but in /lib/pa1.1/libm.a;
--- 856,868 ----
  esac

  # Solaris has a very slow qsort in certain cases, so we replace it.
! case $host_os in solaris*)
! AC_LIBOBJ(qsort) ;;
! esac
!
! # Win32 can't to rename or unlink on an open file
! case $host_os in win32*)
! AC_LIBOBJ(dirmod) ;;
  esac

  # On HPUX 9, rint() is not in regular libm.a but in /lib/pa1.1/libm.a;
Index: src/include/c.h
===================================================================
RCS file: /cvsroot/pgsql-server/src/include/c.h,v
retrieving revision 1.138
diff -c -c -r1.138 c.h
*** src/include/c.h    18 Apr 2003 01:03:42 -0000    1.138
--- src/include/c.h    21 Apr 2003 14:24:24 -0000
***************
*** 711,716 ****
--- 711,727 ----
  off_t ftello(FILE *stream);
  #endif

+ /*
+  * Win32 doesn't have reliable rename/unlink during concurrent access
+  */
+ #ifdef WIN32
+ int pgrename(const char *from, const char *to);
+ int pgunlink(const char *path);
+ #define rename(path)        pgrename(path)
+ #define unlink(from, to)    pgunlink(from, to)
+ #endif
+
+
  /* These are for things that are one way on Unix and another on NT */
  #define NULL_DEV        "/dev/null"


В списке pgsql-patches по дате отправления:

Предыдущее
От: Nic Ferrier
Дата:
Сообщение: build patch
Следующее
От: Sean Chittenden
Дата:
Сообщение: Re: [HACKERS] Are we losing momentum?