Re: [HACKERS] Stuff that doesn't work yet in IPv6 patch
On Fri, Apr 04, 2003 at 06:37:17PM -0500, Tom Lane wrote: 4. pgstat code can only bind to 127.0.0.1 (v4 loopback). On a v6-only machine this would not exist, would it? I'm not sure, but I think I changed something about that. Can you point me to that code? src/backend/postmaster/pgstat.c That was the code I was thinking it was. I changed the code already. I find it so weird, why isn't it just using socketpair() or something? Kurt ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
[HACKERS] Separate build directory
When I configure and make in a separate build directory tree, I get createdb.c:15: dumputils.h: No such file or directory and print.c:9: common.h: No such file or directory in src/bin/scripts. I don't know whether the attached change to the Makefile is the preferred way to fix this, at least it works for me. BTW, make creates these files in the source tree: ./src/backend/bootstrap/bootparse.c ./src/backend/bootstrap/bootscanner.c ./src/backend/bootstrap/bootstrap_tokens.h ./src/backend/parser/gram.c ./src/backend/parser/parse.h ./src/backend/parser/scan.c ./src/backend/utils/misc/guc-file.c ./src/bin/psql/sql_help.h ./src/interfaces/ecpg/preproc/pgc.c ./src/interfaces/ecpg/preproc/preproc.c ./src/interfaces/ecpg/preproc/preproc.h ./src/pl/plpgsql/src/pl.tab.h ./src/pl/plpgsql/src/pl_gram.c ./src/pl/plpgsql/src/pl_scan.c Shouldn't they better be created in the build tree? Servus Manfred diff -ruN ../base/src/bin/scripts/Makefile src/bin/scripts/Makefile --- ../base/src/bin/scripts/Makefile2003-04-04 15:45:47.0 +0200 +++ src/bin/scripts/Makefile2003-04-05 14:42:15.0 +0200 @@ -16,7 +16,7 @@ SCRIPTS := vacuumdb clusterdb PROGRAMS = createdb createlang createuser dropdb droplang dropuser -override CPPFLAGS := -I$(libpq_srcdir) $(CPPFLAGS) +override CPPFLAGS := -I$(libpq_srcdir) -I. -I$(top_srcdir)/src/bin/scripts $(CPPFLAGS) all: submake-libpq submake-backend $(PROGRAMS) ---(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: [HACKERS] more contrib: log rotator
On Fri, 4 Apr 2003, Tom Lane wrote: We should also take a look at Apache's rotator to see if there's any need to reinvent the wheel at all. I have not seen it, am not even sure what it's written in... It's written in 140 lines of C (blank lines and all), and has been very solid in my experience. I don't know of any deficiencies that would warrant rewriting it. Jon ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [HACKERS] Stuff that doesn't work yet in IPv6 patch
Kurt Roeckx [EMAIL PROTECTED] writes: I find it so weird, why isn't it just using socketpair() or something? Portability issues, perhaps. Does socketpair exist and behave the same everywhere? Checking the HPUX man page for it, I read socketpair() is supported only for AF_UNIX, which suggests that it's not possible to get datagram semantics from it, at least on this platform. regards, tom lane ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] [NOVICE] Timestamp with time zone change (error) in 7.3.2?
Doug Silver [EMAIL PROTECTED] writes: [ why does he get ] test=# select '2003-04-04'::date::timestamptz; timestamptz 2003-04-03 23:59:00-05 (1 row) Doug was kind enough to give me access to his machine (a FreeBSD 4.6 box) to look into it. The answer is that the timezone tables on this machine seem to have been built with leap second information; this causes the results of localtime() and related operations to diverge from what Postgres is expecting. What actually happens internally is that localtime() returns the value 2003-04-03 23:59:38-05 (22 seconds off the expected result), but we drop the seconds part for reasons mentioned in timestamp2tm(), giving the observed behavior. I believe that 22 seconds is about right for the accumulated number of leap seconds since 1970, so I'm, um, leaping to the conclusion that localtime is doing a leap-second-aware computation. FreeBSD's man localtime points out STANDARDS The asctime(), ctime(), difftime(), gmtime(), localtime(), and mktime() functions conform to ISO/IEC 9899:1990 (``ISO C89''), and conform to ISO/IEC 9945-1:1996 (``POSIX.1'') provided the selected local timezone does not contain a leap-second table (see zic(8)). We are expecting the POSIX-specified behavior (no accounting for leap seconds). Not sure if there's anything much we can do about this except to document don't do that. It seems impractical to make our datetime arithmetic operations cope with leap-second-aware timekeeping. One idea that comes to mind is to test for leap-second-aware behavior (for example, by checking to see that localtime() of a value that should be exactly midnight is exactly midnight) and complain about it if we find we are on a leap-second-using machine. But I'm not sure if it's worth the trouble. I'm also not sure exactly where/when to perform this test --- perhaps when setting a new timezone value? Comments anyone? regards, tom lane ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
[HACKERS] compile error in cvs tip
I'm getting a compile error on cvs tip. gcc -O2 -g -Wall -Wmissing-prototypes -Wmissing-declarations -I../../../../src/include -DPKGLIBDIR=\/usr/local/pgsql/lib\ -DDLSUFFIX=\.so\ -c -o dfmgr.o dfmgr.c -MMD dfmgr.c:330:1: directives may not be used inside a macro argument dfmgr.c:330:1: unterminated argument list invoking macro strcspn make[4]: *** [dfmgr.o] Error 1 Looks like it was caused here: http://developer.postgresql.org/cvsweb.cgi/pgsql-server/src/backend/utils/fmgr/dfmgr.c.diff?r1=1.57r2=1.58 Joe ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
