Re: [PATCHES] 8.0.0b1: configure.in cygipc
Peter Eisentraut schrieb: Reini Urban wrote: But my patch is still valid: The current cygipc check is wrong when cygserver is running. If cygserver is not running, it displays a warning when using the cygipc library. What would be wrong with using cygserver when available (!= when running), else cygipc? I did that in my patch. The problem is how to detect cygserver. I did it with checking against a running cygserver. The other possibility would be to check against an installed cygserver binary. I favored the first. Of course one should de-install cygipc, but I forgot that. Maybe others will also. It does not harm to build against the old cygipc daemon, but only if cygserver is NOT running. -- Reini Urban http://xarch.tu-graz.ac.at/home/rurban/ ---(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] time_t timezone
Tom Lane schrieb: Reini Urban [EMAIL PROTECTED] writes: Added configure time_t timezone check for the SUSV definition. Kindly do not claim that this is per SUS spec. http://www.opengroup.org/onlinepubs/007908799/xsh/timezone.html oops! sorry :( -- Reini Urban http://xarch.tu-graz.ac.at/home/rurban/ ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
[PATCHES] pg_autovacuum service fixes
Hi, The attached patch addresses the following issues with the WIn32 service code in pg_autovacuum. Please apply. - Add documentation. - Use the main PostgreSQL message dll when logging to the application log. - Set the -P (port) option correctly when installing as a service. Regards, Dave pg_autovacuum3.diff Description: pg_autovacuum3.diff ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [PATCHES] time_t timezone
I am inclined to leave the #ifdef Cygwin test in the code rather than add a configure check. --- Reini Urban wrote: Tom Lane schrieb: Reini Urban [EMAIL PROTECTED] writes: Added configure time_t timezone check for the SUSV definition. Kindly do not claim that this is per SUS spec. http://www.opengroup.org/onlinepubs/007908799/xsh/timezone.html oops! sorry :( -- Reini Urban http://xarch.tu-graz.ac.at/home/rurban/ ---(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 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] time_t timezone
Bruce Momjian schrieb: I am inclined to leave the #ifdef Cygwin test in the code rather than add a configure check. No, There are a lot of other systems with time_t timezone! newlib explains it like this: /* defines for the opengroup specifications Derived from Issue 1 of the SVID. */ extern __IMPORT time_t _timezone; extern __IMPORT int _daylight; extern __IMPORT char *_tzname[2]; SVID (System V Interface Definition) seems to be an interesting spec, which I found here: http://www.caldera.com/developers/devspecs/vol1a.pdf (nothing about the type of timezone though) But the time_t timezone issue is here: XSHd7 Aardvark Change Request Report http://www.opengroup.org/austin/docs/austin_97.txt (ERN 20 Accept as marked, page 1177) SUSV2 only defines it as long int http://www.opengroup.org/onlinepubs/007908799/xsh/timezone.html Caldera, redhat and IRIX 6.2 at least use time_t http://uw713doc.sco.com/en/man/html.3C/ctime.3C.html http://www.opensource.apple.com/darwinsource/10.0.4/tcl-3.1/tcl/unix/tcl.m4 Please google for time_t timezone and the accompanying autoconf .m4 files. tcl.m4 could be quite useful, if you don't like my hack. php also uses time_t and not long int. PS: For compatibility newlib has: #ifdef __CYGWIN__ #ifdef timezonevar #ifndef timezone #define timezone ((long int) _timezone) #endif #endif Looks like we only have to define timezonevar in our hint, eh Makefile.port, but then the other platforms will loose. --- Reini Urban wrote: Tom Lane schrieb: Reini Urban [EMAIL PROTECTED] writes: Added configure time_t timezone check for the SUSV definition. Kindly do not claim that this is per SUS spec. http://www.opengroup.org/onlinepubs/007908799/xsh/timezone.html oops! sorry :( -- Reini Urban http://xarch.tu-graz.ac.at/home/rurban/ ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [PATCHES] time_t timezone
Reini Urban [EMAIL PROTECTED] writes: But the time_t timezone issue is here: XSHd7 Aardvark Change Request Report http://www.opengroup.org/austin/docs/austin_97.txt (ERN 20 Accept as marked, page 1177) There is nothing whatever on that page about the datatype of the timezone variable. Caldera, redhat and IRIX 6.2 at least use time_t http://uw713doc.sco.com/en/man/html.3C/ctime.3C.html Red Hat certainly does not: [EMAIL PROTECTED] include]$ grep timezone /usr/include/*h /usr/include/time.h: of *TIMER in the local timezone. */ /usr/include/time.h:extern char *__tzname[2]; /* Current timezone names. */ /usr/include/time.h:extern long int __timezone; /* Seconds west of UTC. */ /usr/include/time.h:extern long int timezone; [EMAIL PROTECTED] include]$ But what may be more to the point is that AFAICS we make no assumption about the exact datatype of the timezone variable. So long as it is some signed integer type (which surely it must be), the code will work. I see no reason to add a configure test to test something we do not care about. regards, tom lane ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [PATCHES] time_t timezone
Tom Lane schrieb: Reini Urban [EMAIL PROTECTED] writes: But the time_t timezone issue is here: XSHd7 Aardvark Change Request Report http://www.opengroup.org/austin/docs/austin_97.txt (ERN 20 Accept as marked, page 1177) There is nothing whatever on that page about the datatype of the timezone variable. 1) in POSIX, the time_t value is always related to local time by the seconds since the Epoch expression and the timezone information. Yes, they are talking about the localtime return value, but nevertheless the newlib folks refer to that. Their fault. Should I discuss that with them? I will not do that. newlib is happening in the real world, standards just a general consensus, how it should happen. If some other platforms use newlib, you are lost with the make abort. Caldera, redhat and IRIX 6.2 at least use time_t http://uw713doc.sco.com/en/man/html.3C/ctime.3C.html Red Hat certainly does not: [EMAIL PROTECTED] include]$ grep timezone /usr/include/*h /usr/include/time.h: of *TIMER in the local timezone. */ /usr/include/time.h:extern char *__tzname[2]; /* Current timezone names. */ /usr/include/time.h:extern long int __timezone; /* Seconds west of UTC. */ /usr/include/time.h:extern long int timezone; [EMAIL PROTECTED] include]$ dertainly depends which redhat. I have no redhat around and newlib is quite new. This pgtz timezone code is also quite new. But what may be more to the point is that AFAICS we make no assumption about the exact datatype of the timezone variable. So long as it is some signed integer type (which surely it must be), the code will work. I see no reason to add a configure test to test something we do not care about. Bruce' patch only assumes time_t on CYGWIN and it is only for pgtypeslib (src/interfaces/ecpg/pgtypeslib/dt.h). Not for src/timezone/pgtz.c Fact is: src/timezone/pgtz.c does not compile on cygwin, and will not compile on any other similar platform, as I saw from googling around, unless it is checked in configure.in or - the dirty way - casted away in src/timezone/pgtz.c and the .m4 macro. Since the current configure check does not define HAVE_INT_TIMEZONE (not casted there, so it fails), the whole pgtz #ifdef branch will abort. http://developer.postgresql.org/cvsweb.cgi/pgsql-server/src/timezone/pgtz.c?rev=HEAD;content-type=text%2Fx-cvsweb-markup and http://developer.postgresql.org/cvsweb.cgi/pgsql-server/config/c-library.m4?rev=HEAD;content-type=text%2Fx-cvsweb-markup are wrong without the cast. -- Reini Urban http://xarch.tu-graz.ac.at/home/rurban/ ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [PATCHES] time_t timezone
Reini Urban [EMAIL PROTECTED] writes: Yes, they are talking about the localtime return value, but nevertheless the newlib folks refer to that. Their fault. Should I discuss that with them? Probably. They have a gratuitous variation from the Single Unix Spec. But what may be more to the point is that AFAICS we make no assumption about the exact datatype of the timezone variable. Bruce' patch only assumes time_t on CYGWIN and it is only for pgtypeslib (src/interfaces/ecpg/pgtypeslib/dt.h). Not for src/timezone/pgtz.c Per my recent post in pghackers, I think that the datatype has nothing to do with it anyway. The real problem is the loss of this code that was in pg_config_manual.h in 7.4 and before: /* * Define this if your operating system has _timezone rather than timezone */ #if defined(__CYGWIN__) || defined(WIN32) #define HAVE_INT_TIMEZONE /* has int _timezone */ #define HAVE_UNDERSCORE_TIMEZONE 1 #endif I'm inclined to just put it back, rather than adding a configure test that we never needed before. regards, tom lane ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
[PATCHES] Win32 Version patch
Evening committers, Any ideas when Magnus' win32 version numbering patch is likely to get applied? Regards, Dave. ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [PATCHES] time_t timezone
Tom Lane schrieb: Reini Urban [EMAIL PROTECTED] writes: Yes, they are talking about the localtime return value, but nevertheless the newlib folks refer to that. Their fault. Should I discuss that with them? Probably. They have a gratuitous variation from the Single Unix Spec. But what may be more to the point is that AFAICS we make no assumption about the exact datatype of the timezone variable. Bruce' patch only assumes time_t on CYGWIN and it is only for pgtypeslib (src/interfaces/ecpg/pgtypeslib/dt.h). Not for src/timezone/pgtz.c Per my recent post in pghackers, I think that the datatype has nothing to do with it anyway. The real problem is the loss of this code that was in pg_config_manual.h in 7.4 and before: /* * Define this if your operating system has _timezone rather than timezone */ #if defined(__CYGWIN__) || defined(WIN32) #define HAVE_INT_TIMEZONE /* has int _timezone */ #define HAVE_UNDERSCORE_TIMEZONE 1 #endif I'm inclined to just put it back, rather than adding a configure test that we never needed before. Fine with me. I'm just doing the cygwin packaging. And I can apply my cast to the pgtz.c code by myself also. But upstream would be better. I just wanted that you are aware of that. The configure test was more general and similar to other packages (tcl, php). -- Reini Urban http://xarch.tu-graz.ac.at/home/rurban/ ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [PATCHES] time_t timezone
Tom Lane wrote: Reini Urban [EMAIL PROTECTED] writes: Yes, they are talking about the localtime return value, but nevertheless the newlib folks refer to that. Their fault. Should I discuss that with them? Probably. They have a gratuitous variation from the Single Unix Spec. But what may be more to the point is that AFAICS we make no assumption about the exact datatype of the timezone variable. Bruce' patch only assumes time_t on CYGWIN and it is only for pgtypeslib (src/interfaces/ecpg/pgtypeslib/dt.h). Not for src/timezone/pgtz.c Per my recent post in pghackers, I think that the datatype has nothing to do with it anyway. The real problem is the loss of this code that was in pg_config_manual.h in 7.4 and before: /* * Define this if your operating system has _timezone rather than timezone */ #if defined(__CYGWIN__) || defined(WIN32) #define HAVE_INT_TIMEZONE /* has int _timezone */ #define HAVE_UNDERSCORE_TIMEZONE 1 #endif I'm inclined to just put it back, rather than adding a configure test that we never needed before. OK, I backed out the int cast I had made for dt.h. I agree time_t should cast to int naturally. I noticed that HAVE_INT_TIMEZONE is already a configure test. Is that test not working on Cygwin? Seems it is working on MinGW. The test is this: # PGAC_VAR_INT_TIMEZONE # - # Check if the global variable `timezone' exists. If so, define # HAVE_INT_TIMEZONE. AC_DEFUN([PGAC_VAR_INT_TIMEZONE], [AC_CACHE_CHECK(for int timezone, pgac_cv_var_int_timezone, [AC_TRY_LINK([#include time.h int res;], [res = timezone / 60;], [pgac_cv_var_int_timezone=yes], [pgac_cv_var_int_timezone=no])]) if test x$pgac_cv_var_int_timezone = xyes ; then AC_DEFINE(HAVE_INT_TIMEZONE,, [Define to 1 if you have the global variable 'int timezone'.]) fi])# PGAC_VAR_INT_TIMEZONE You can look in include/pg_config.h to see how it is defined. -- 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 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] dbsize contrib
Patch applied. Thanks. Can I get some documentation in the README for all the new functionality. --- Andreas Pflug wrote: The current implementation of dbsize doesn't handle tables in tablespaces correctly, and is quite restricted on objects covered (only tables and databases, but not tablespaces and indexes). The attached patch contributes: - database_size(name) - relation_size(text) These are the well-known functions, tablespace-aware. - pg_tablespace_size(oid) - pg_database_size(oid) - pg_relation_size(oid) Tablespace-aware implementations, used by the upper functions. pg_relation_size will report sizes of indexes as well. - pg_size_pretty(bigint) Formatting of sizes, to display '146MB' instead of '152885668' Regards, Andreas -- 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 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [PATCHES] Timezones on localized windows
Patch applied. Thanks.
This part of the patch was already in CVS:
*** 822,829
--- 822,832
{
int i;
chartzname[128];
+ charlocaltzname[128];
time_t t = time(NULL);
struct tm *tm = localtime(t);
+ HKEYrootKey;
+ int idx;
if (!tm)
---
Magnus Hagander wrote:
This patch attempts to fix the issue with localized timezones on
Windows.
Recap: When running on a localized windows version, the timezone name
returned is also localized, and therefor does not match our lookup
table.
Solution: The registry contains both the name of the timezone in english
and the localized name. The patch adds code to scan the registry for the
localized name and gets the english name from that, and then rescans the
table.
I have tested this on a Swedish WinXP, and it works without problems.
The registry layout is the same in Win2k, but I haven't specifically
tested it. It's also the same on different languages but again only
Swedish is tested.
//Magnus
Content-Description: win32localtz.patch
[ Attachment, skipping... ]
---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster
--
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 9: the planner will ignore your desire to choose an index scan if your
joining column's datatypes do not match
Re: [PATCHES] Timezones on localized windows
I have backed out my application of the patch because Tom already
applied it. I didn't see the merge failure because I assume Tom placed
your code in a different part of the code.
---
Bruce Momjian wrote:
Patch applied. Thanks.
This part of the patch was already in CVS:
*** 822,829
--- 822,832
{
int i;
chartzname[128];
+ charlocaltzname[128];
time_t t = time(NULL);
struct tm *tm = localtime(t);
+ HKEYrootKey;
+ int idx;
if (!tm)
---
Magnus Hagander wrote:
This patch attempts to fix the issue with localized timezones on
Windows.
Recap: When running on a localized windows version, the timezone name
returned is also localized, and therefor does not match our lookup
table.
Solution: The registry contains both the name of the timezone in english
and the localized name. The patch adds code to scan the registry for the
localized name and gets the english name from that, and then rescans the
table.
I have tested this on a Swedish WinXP, and it works without problems.
The registry layout is the same in Win2k, but I haven't specifically
tested it. It's also the same on different languages but again only
Swedish is tested.
//Magnus
Content-Description: win32localtz.patch
[ Attachment, skipping... ]
---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster
--
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 9: the planner will ignore your desire to choose an index scan if your
joining column's datatypes do not match
--
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 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] Win32 Version patch
Dave Page wrote: Evening committers, Any ideas when Magnus' win32 version numbering patch is likely to get applied? Good question. Last I saw it it was quite large. Magnus, would you post a new version so we can look it over again. I have no problem with the binary file you suggested. -- 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 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
