[HACKERS] Failed to initialize lc_messages 7.3b5
Hi, I don't know if it's important or not ... but on my linux Debian woody, with fr_FReuro parameter when I do the initdb I've got a creating template1 database in /usr/local/pgsql/data/base/1... Failed to initialize lc_messages to '' I just would like to know what that's mean exactly ... Exact message of initdb : /usr/local/pgsql/bin/initdb -D /usr/local/pgsql/data The files belonging to this database system will be owned by user postgres. This user must also own the server process. The database cluster will be initialized with locale fr_FReuro. This locale setting will prevent the use of indexes for pattern matching operations. If that is a concern, rerun initdb with the collation order set to C. For more information see the Administrator's Guide. Fixing permissions on existing directory /usr/local/pgsql/data... ok creating directory /usr/local/pgsql/data/base... ok creating directory /usr/local/pgsql/data/global... ok creating directory /usr/local/pgsql/data/pg_xlog... ok creating directory /usr/local/pgsql/data/pg_clog... ok creating template1 database in /usr/local/pgsql/data/base/1... Failed to initialize lc_messages to '' ok creating configuration files... ok initializing pg_shadow... ok enabling unlimited row size for system tables... ok initializing pg_depend... ok creating system views... ok loading pg_description... ok creating conversions... ok setting privileges on built-in objects... ok vacuuming database template1... ok copying template1 to template0... ok Success. You can now start the database server using: /usr/local/pgsql/bin/postmaster -D /usr/local/pgsql/data or /usr/local/pgsql/bin/pg_ctl -D /usr/local/pgsql/data -l logfile start regards, -- Hervé Piedvache Elma Ingénierie Informatique 6 rue du Faubourg Saint-Honoré F-75008 - Paris - France Tel. 33-144949901 fax. 33-144949902 ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [PORTS] [HACKERS] PostgreSQL supported platform report and a
That's true! But I had to export CFLAGS=-Xb to compile (this should be in port Makefile IMHO) Also, I think the Setting of LD_LIBRARY_PATH could be a win to. Although I doubt anyone would run uw whith at least LD_LIBRARY_PATH=/lib:/usr/local/lib, setting LD_LIBRARY_PATH and includes in the port makefile could ease the configure process as readline is not found if you don't add --with-includes ans --with-libs on configure command. Reagrds On Wed, 6 Nov 2002, Larry Rosenman wrote: Date: Wed, 06 Nov 2002 23:27:31 -0600 From: Larry Rosenman [EMAIL PROTECTED] To: Billy G. Allie [EMAIL PROTECTED], [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: Re: [PORTS] [HACKERS] PostgreSQL supported platform report and a patch. We already have success messages from Olivier Prenant for 7.3B4 on 8.0.0, and me for 7.1.3. I don't believe your changes are necessary. --On Wednesday, November 06, 2002 22:57:26 -0500 Billy G. Allie [EMAIL PROTECTED] wrote: I am including a set of 4 small patches that enable PostgreSQL 7.3b3 to build successfully on OpenUnix 8.0. These same patches should also work for UnixWare 7.x. I will confirm that tomorrow (Nov 7, 2002). Here is an explanation of the patches: 1. An update of the FAQ_SCO file. 2. This patch removes a static declaration of a in-line function in src/backend/utils/sort/tuplesort.c 3. This patch to src/makefiles/Makefile.unixware, together with the patch tosrc/Makefile.global.in allows any addition library search directories (addedwith the configure --with-libraries option) to be added to the rpath option sent to the linker. The use of a different variable to pass the addition search paths was necessary to avoid a circular reference to LDFLAGS. 4. This patch creates the variable (trpath) used by the patch to Makefile.unixware. This patch would also be for other platforms that would have to add the additional library search paths to the rpath linker option.See Makefile.unixware for an example of how to do this. After applying these patches, PostgreSQL successfully compiled on OpenUnix 8 and it passed all the regression tests. -- Olivier PRENANT Tel:+33-5-61-50-97-00 (Work) Quartier d'Harraud Turrou +33-5-61-50-97-01 (Fax) 31190 AUTERIVE +33-6-07-63-80-64 (GSM) FRANCE Email: [EMAIL PROTECTED] -- Make your life a dream, make your dream a reality. (St Exupery) ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] PostgreSQL supported platform report and a patch.
--On Thursday, November 07, 2002 01:17:55 -0500 Billy G. Allie [EMAIL PROTECTED] wrote: Larry Rosenman wrote: We already have success messages from Olivier Prenant for 7.3B4 on 8.0.0, and me for 7.1.3. I don't believe your changes are necessary. Was that using gcc or the native compiler? Native. Was it in linux kernel personality mode or OpenUNIX mode. Native. I was compiling using the native (UDK) compiler. and it failed in tuplesort.c. It was also unable to file the readline shared libraries without the changes to the makefiles or setting LD_RUN_PATH (which is a pain and is depreciated in OpenUNIX 8 and UnixWare 7). Tom fixed the tuplesort.c issue with some help from the Caldera/SCO Compiler team (I'm on the 7.1.3 BETA). My system has always found the readline stuff (I use the skunkware readline). It hasn't been an issue on my system. -- | Billy G. Allie| Domain: [EMAIL PROTECTED] | /| | 7436 Hartwell | MSN...: [EMAIL PROTECTED] | -/-|- | Dearborn, MI 48126| | / |LLIE | (313) 582-1540| -- Larry Rosenman, Sr. Network Engineer, Internet America, Inc. E-Mail: [EMAIL PROTECTED] Phone: +1 214-861-2571, Fax: 214-861-2663 US Mail: 350 N. St. Paul, Suite 3000, Dallas, TX 75201 ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] PostgreSQL supported platform report and a patch.
--On Thursday, November 07, 2002 02:42:47 -0500 Tom Lane [EMAIL PROTECTED] wrote: Larry Rosenman [EMAIL PROTECTED] writes: I don't believe your changes are necessary. The static-inline change was obsoleted by a recent fix, per discussion. But the rpath changes seem possibly useful (or maybe my thoughts are just colored by the fact that I'm currently trying to persuade OpenSSL to build with a non-broken rpath setup on HPUX...) Do you have an objection to the rpath part of Billy's patch? Not necessarily. I was just concerned about the tuplesort one, and the fact that mine builds and passes without the changes. regards, tom lane -- Larry Rosenman, Sr. Network Engineer, Internet America, Inc. E-Mail: [EMAIL PROTECTED] Phone: +1 214-861-2571, Fax: 214-861-2663 US Mail: 350 N. St. Paul, Suite 3000, Dallas, TX 75201 ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [PORTS] [HACKERS] PostgreSQL supported platform report and a
--On Thursday, November 07, 2002 13:32:18 +0100 Olivier PRENANT [EMAIL PROTECTED] wrote: That's true! But I had to export CFLAGS=-Xb to compile (this should be in port Makefile IMHO) Tom fixed that with a later tuplesort.c fix (per a discussion with the Caldera/SCO compiler guys). Also, I think the Setting of LD_LIBRARY_PATH could be a win to. Although I doubt anyone would run uw whith at least LD_LIBRARY_PATH=/lib:/usr/local/lib, setting LD_LIBRARY_PATH and includes in the port makefile could ease the configure process as readline is not found if you don't add --with-includes ans --with-libs on configure command. Not a problem here. (the change that is). Reagrds On Wed, 6 Nov 2002, Larry Rosenman wrote: Date: Wed, 06 Nov 2002 23:27:31 -0600 From: Larry Rosenman [EMAIL PROTECTED] To: Billy G. Allie [EMAIL PROTECTED], [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: Re: [PORTS] [HACKERS] PostgreSQL supported platform report and a patch. We already have success messages from Olivier Prenant for 7.3B4 on 8.0.0, and me for 7.1.3. I don't believe your changes are necessary. --On Wednesday, November 06, 2002 22:57:26 -0500 Billy G. Allie [EMAIL PROTECTED] wrote: I am including a set of 4 small patches that enable PostgreSQL 7.3b3 to build successfully on OpenUnix 8.0. These same patches should also work for UnixWare 7.x. I will confirm that tomorrow (Nov 7, 2002). Here is an explanation of the patches: 1. An update of the FAQ_SCO file. 2. This patch removes a static declaration of a in-line function in src/backend/utils/sort/tuplesort.c 3. This patch to src/makefiles/Makefile.unixware, together with the patch tosrc/Makefile.global.in allows any addition library search directories (addedwith the configure --with-libraries option) to be added to the rpath option sent to the linker. The use of a different variable to pass the addition search paths was necessary to avoid a circular reference to LDFLAGS. 4. This patch creates the variable (trpath) used by the patch to Makefile.unixware. This patch would also be for other platforms that would have to add the additional library search paths to the rpath linker option.See Makefile.unixware for an example of how to do this. After applying these patches, PostgreSQL successfully compiled on OpenUnix 8 and it passed all the regression tests. -- Olivier PRENANT Tel: +33-5-61-50-97-00 (Work) Quartier d'Harraud Turrou +33-5-61-50-97-01 (Fax) 31190 AUTERIVE +33-6-07-63-80-64 (GSM) FRANCE Email: [EMAIL PROTECTED] - - Make your life a dream, make your dream a reality. (St Exupery) -- Larry Rosenman, Sr. Network Engineer, Internet America, Inc. E-Mail: [EMAIL PROTECTED] Phone: +1 214-861-2571, Fax: 214-861-2663 US Mail: 350 N. St. Paul, Suite 3000, Dallas, TX 75201 ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] Outstanding patches
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 \pset pager always: I thought we had rejected that idea in favor of making the whether-to-use-pager decision pay attention to width as well as number of lines. The main problem with this is that all pagers (by definition) support vertical scrolling, but only some support horizontal scrolling. Since we have no way of knowing whether the client supports horizontal, we would be doing a disservice to call the pager on wide but short output for those clients that only do vertical. Therefore, the patch allows the user to override the default behavior and always call the pager, regardless of vertical or horizontal dimensions. Greg Sabino Mullane [EMAIL PROTECTED] PGP Key: 0x14964AC8 200211070746 -BEGIN PGP SIGNATURE- Comment: http://www.turnstep.com/pgp.html iD8DBQE9ymGFvJuQZxSWSsgRAvKvAJ9qzB76H69DowOYEPdpvwR79j5/6QCg2UQC /hpgJ3PpxplsjVfYuU7J+QU= =Amsq -END PGP SIGNATURE- ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
[HACKERS] command
what is the command to launch a sql script not in psql thanks ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
[HACKERS] [ pgsql-monitoring ]
Hi, I hasa dinamic application, constructed on php, connectingin db postgres 7.2. I would like monitor the all established connection. I want know whish command is running at moment. Help, please !!! Osvâneo A. Ferreira [EMAIL PROTECTED]
Re: [HACKERS] openbsd 3.2, postgresql 7.3beta3 and openssl 'e_os.h' include file
According to the feedback I have had, e_os.h is no longer a public interface header file in OpenSSL. 'get_last_socket_error' is a macro that seems to expand to errno. Can I suggest someone with better understanding of the postgresql sources, and ssl support, please pick this up - maybe in time for the 7.3 release ? rgds, -- Peter - Original Message - From: Peter Galbavy [EMAIL PROTECTED] To: [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Tuesday, November 05, 2002 8:13 AM Subject: openbsd 3.2, postgresql 7.3beta3 and openssl 'e_os.h' include file [To BOTH postgresql and openbsd ports lists... please reply as appropriate.] I finally got around to trying to build 7.3beta3 on an fresh OpenBSD 3.2/i386 box, without all the historical lint that gets collected up. OpenSSL 0.9.x is including in the base release. The includsion of openssl/e_os.h in src/backend/libpq/be-secure.c fails. Removing this include results in a compile, but a missing reference to 'get_last_socket_error()' in linking. I cannot find that in any openssl include file :( I know *nothing* about using the OpenSSL libraries, and I am off away from the 'net for a week from tonight. :( Sorry. I will include any patches in the OpenBSD postgresql port that I am working on, but this may affect other systems that (perhaps) use the newer OpenSSL libraries ? Any ideas ? -- Peter ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] [ pgsql-monitoring ]
On Tue, Nov 05, 2002 at 06:48:30PM -0200, Osv?neo A. Ferreira wrote: Hi, I has a dinamic application, constructed on php, connecting in db postgres 7.2. I would like monitor the all established connection. I want know whish command is running at moment. Help, please !!! Check out pg_monitor (go to gborg.postgresql.org). Also, this sort of question belongs on -general. A -- Andrew Sullivan 204-4141 Yonge Street Liberty RMS Toronto, Ontario Canada [EMAIL PROTECTED] M2P 2A8 +1 416 646 3304 x110 ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Failed to initialize lc_messages 7.3b5
=?iso-8859-15?q?Herv=E9=20Piedvache?= [EMAIL PROTECTED] writes: I don't know if it's important or not ... but on my linux Debian woody, with fr_FR@euro parameter when I do the initdb I've got a creating template1 database in /usr/local/pgsql/data/base/1... Failed to initialize lc_messages to '' I just would like to know what that's mean exactly ... It means your platform doesn't accept fr_FR@euro as a setting for LC_MESSAGES. Since fr_FR@euro is evidently accepted as a setting for other LC_ variables, this is a bug in the locale definition, which you should report to the Debian folk. Until they fix it, you can probably work around it by starting the postmaster with LC_MESSAGES explicitly set to something different than LANG/LC_ALL are (maybe plain fr_FR would work). I think you will need to adjust lc_messages in postgresql.conf as well. regards, tom lane ---(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] command
On Tue, Nov 05, 2002 at 03:19:44PM +0100, Florian Litot wrote: what is the command to launch a sql script not in psql Perl? Or maybe you just want to read SQL into Postgres using the shell. In which case, try the -f switch to psql. A -- Andrew Sullivan 204-4141 Yonge Street Liberty RMS Toronto, Ontario Canada [EMAIL PROTECTED] M2P 2A8 +1 416 646 3304 x110 ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [PORTS] [HACKERS] PostgreSQL supported platform report and a
On Thu, 7 Nov 2002, Larry Rosenman wrote: Date: Thu, 07 Nov 2002 06:41:02 -0600 From: Larry Rosenman [EMAIL PROTECTED] To: [EMAIL PROTECTED] Cc: Billy G. Allie [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED] Subject: Re: [PORTS] [HACKERS] PostgreSQL supported platform report and a --On Thursday, November 07, 2002 13:32:18 +0100 Olivier PRENANT [EMAIL PROTECTED] wrote: That's true! But I had to export CFLAGS=-Xb to compile (this should be in port Makefile IMHO) Tom fixed that with a later tuplesort.c fix (per a discussion with the Caldera/SCO compiler guys). Huh! I just tried to compile 7.3b5 without CFLAGS=-Xb, it still bugs the compiler... -- Olivier PRENANT Tel:+33-5-61-50-97-00 (Work) Quartier d'Harraud Turrou +33-5-61-50-97-01 (Fax) 31190 AUTERIVE +33-6-07-63-80-64 (GSM) FRANCE Email: [EMAIL PROTECTED] -- Make your life a dream, make your dream a reality. (St Exupery) ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] RC1 on Friday?
On Wed, 6 Nov 2002, Bruce Momjian wrote: Marc G. Fournier wrote: News to me ... On Wed, 6 Nov 2002, Bruce Momjian wrote: Are we still on schedule for RC1 on Friday? I am asking. We almost got to RC1 last Friday, so I figured we could do RC1 this Friday. The changes between betas is minimal. Since beta4 was a dead attempt (well, riddled with fixes that were required), I'd like to announce and get beta5 out there and tested *before* we do RC1 ... Tom, my understanding is that CONVERT stuff required an initdb, and was also the only thing 'critical' that went in ... correct? What impact does that have? For instance, could it cause one of the regression tests to fail, or is it something that is relatively benign? ---(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: [CYGWIN] [HACKERS] Request for supported platforms
This post is just for closure -- both of the issues below have been resolved: On Tue, Oct 29, 2002 at 09:47:35AM -0500, Jason Tishler wrote: 1. Cygwin bison needs to be upgraded from 1.35 to 1.75 (i.e., 1.50+) to process src/interfaces/ecpg/preproc/preproc.y successfully. I will post to the Cygwin mailing list asking the maintainer for this upgrade. OK. This shouldn't stop a release though I assume, only a build from CVS. Yes. Nevertheless, I have posted my request: http://cygwin.com/ml/cygwin/2002-10/msg01740.html http://cygwin.com/ml/cygwin-announce/2002-10/msg00016.html 2. The following fseeko/ftello ifdef in src/include/pg_config.h.in: #ifndef HAVE_FSEEKO #define fseeko(a, b, c) fseek((a), (b), (c)) #define ftello(a) ftell((a)) #endif conflicts with the following Cygwin /usr/include/stdio.h entries: int _EXFUN(fseeko, (FILE *, off_t, int)); off_t _EXFUN(ftello, ( FILE *)); Unfortunately, I'm not sure what is the best way to solve this one yet. Any suggestions would be appreciated. I found a solution to the above which will hopefully find its way into the next Cygwin release: http://cygwin.com/ml/cygwin-patches/2002-q4/msg00042.html http://cygwin.com/ml/cygwin-patches/2002-q4/msg00089.html Jason -- PGP/GPG Key: http://www.tishler.net/jason/pubkey.asc or key servers Fingerprint: 7A73 1405 7F2B E669 C19D 8784 1AFD E4CC ECF4 8EF6 ---(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] protocol change in 7.4
Hi all, Mike Mascari [EMAIL PROTECTED] wrote: Is there any thought about changing the protocol to support two-phase commit? Not that 2PC and distributed transactions would be implemented in 7.4, but to prevent another protocol change in the future? I'm now implementing 2PC replication and distributed transaction. My 2PC needs some support in startup packet to establish a replication session and a recovery session. BTW, 2PC replication is working, and I'm implementing 2PC recovery now. -- NAGAYASU Satoshi [EMAIL PROTECTED] ---(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] [GENERAL] Database replication... - Mission Critica
My presumption would be that if you initialize 2 databases to a known identical start, have all the same triggers and rules on both, then send all queries to both databases, you will have 2 identical databases at the end. This is wrong assumption. If 1st client executes UPDATE t SET a = 1 WHERE b = 2; 2nd client executes UPDATE t SET a = 2 WHERE b = 2; at the same time you don't know in what order these queries will be executed on two different servers (because you can't control what transaction will lock record(s) for update first). Vadim ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] protocol change in 7.4
On Wed, Nov 06, 2002 at 05:02:14PM +0900, Satoshi Nagayasu wrote: Hannu Krosing [EMAIL PROTECTED] wrote: Exactly. When user send the COMMIT command to the master server, the master.talks to the slaves to process precommit-vote-commit using the 2PC. The 2PC cycle is hidden from user application. User application just talks the normal FE/BE protocol. But _can_ client (libpq/jdbc/...) also talk 2PC FE/BE protocol, i.e. act as master ? Not for now. The current libpq/jdbc can talk only normal FE/BE protocol. But it can be implemented. Because my (experimantal)libpq can talk 2PC FE/BE protocol. :-) snip Because the postgres backend must detect a type of incomming connection (from the client app or the master). If it is comming from the client, the backend relays the queries to the slaves (act as the master). But if it is comming from the master server, the backend must act as a slave, and does not relay the queries. So, your replication is an all-or-nothing type of thing? you can't replicate some tables and not others? If only some tables are replicated, then you can't decide if this is a distributed transaction until it's been parsed. Also, if we want to cascade, then one server can be both master and slave, as it were. For full-on-2PC, I'm not sure cascading is a good idea, but it's something to consider, especially if there's provisions for partial replication, or 'optional' slaves. I think there are several types of connection in the sync replication or the distributed transaction. Especially, the bulk transfer of tables or indexes will be neccesary for the distributed query in future. So, I think embedding the connection type information in the startup packet is a good idea. Is there some fundamental reason that the slave backends can't just wait and see if the first commit command is PRECOMMIT or COMMIT and then act accordingly on for each transaction ? Are two commit commands required on the clustered postgres? And is one commit command required on the single postgres? I think Hannu is suggesting that COMMIT could occur from either of two states in the transaction state diagram: from an open transaction, or from PRECOMMIT. There's no need to determine before that moment if this particular transaction is part of a 2PC or not, is there? So, no you don't _require_ PRECOMMIT/COMMIT because it's clustered: if a 'bare' COMMIT shows up, do what you currently do: hide the details. If a PRECOMMIT shows up, report status back to the 'client'. So, it seems to me that the minimum protocol change necessary to support this model is reporting the current transaction status to the client. I think it will confuse the application programmer. I think your mental image of an application programmer needsto be expanded: it should also include middleware vendors, who very much want to be able to control a distributed transaction, one part of which may be a postgresql replicated cluster. Ross ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] PostgreSQL supported platform report and a patch.
Tom Lane wrote: Billy G. Allie [EMAIL PROTECTED] writes: Here is the error messages generated during the compile: cc -K pentium_pro,host,inline,loop_unroll -I../../../../src/include -I/usr/local/include -I/usr/local/ssl/include -c -o tuplesort.o tuplesort. c UX:acomp: ERROR: tuplesort.c, line 1854: inline functions cannot use static identifier: myFunctionCall2 Uh, what version are you testing exactly? I thought we'd resolved that as of a week or so back (certainly in 7.3b4). It was 7.3b3. I've just downloaded 7.3b5 and will re-test. If that's the case then ignore the patch to tuplesort.c The rest of the patches are still valid though. -- | Billy G. Allie| Domain: [EMAIL PROTECTED] | /| | 7436 Hartwell | MSN...: [EMAIL PROTECTED] |-/-|- | Dearborn, MI 48126| |/ |LLIE | (313) 582-1540| msg24831/pgp0.pgp Description: PGP signature
Re: [HACKERS] PostgreSQL supported platform report and a patch.
Tom Lane wrote: Bruce Momjian [EMAIL PROTECTED] writes: I am fine with this because it only touches unixware-specific stuff, except the change to Tom's inline function: [static] inline Datum myFunctionCall2(FmgrInfo *flinfo, Datum arg1, Datum arg2) Tom will have to comment on that. That change would actively break some platforms (see C99 inline specifications). Why is it necessary for SCO? We certainly have plenty of other static inline functions ... regards, tom lane Here is the error messages generated during the compile: cc -K pentium_pro,host,inline,loop_unroll -I../../../../src/include -I/usr/local/include -I/usr/local/ssl/include -c -o tuplesort.o tuplesort.c UX:acomp: ERROR: tuplesort.c, line 1854: inline functions cannot use static identifier: myFunctionCall2 UX:acomp: ERROR: tuplesort.c, line 1856: inline functions cannot use static identifier: myFunctionCall2 UX:acomp: ERROR: tuplesort.c, line 1870: inline functions cannot use static identifier: myFunctionCall2 UX:acomp: ERROR: tuplesort.c, line 1872: inline functions cannot use static identifier: myFunctionCall2 UX:acomp: ERROR: tuplesort.c, line 1885: inline functions cannot use static identifier: myFunctionCall2 UX:acomp: ERROR: tuplesort.c, line 1897: inline functions cannot use static identifier: myFunctionCall2 gmake[4]: *** [tuplesort.o] Error 1 The problem only occurs in tuplesort.c. It does not occur in pg_lzcompress.c or aset.c, which are the only other source files that contain static inline function definitions that get compiled. The rest are IF DEFed out. I think the problem is that myFunctionCall2 is called by a non-static inline function, ApplySortFunction. If I make ApplySortFunction static, it compiles (but break the link phase). If I remove the inline from ApplySortFunction, it compiles and builds. In order for tuplesort.c to compile on OpenUNIX the code must be changed to either: 1. Remove the static modifier from myFuntionCall2 or 2. Remove the inline from ApplySortFunction or 3. Wrap the static modifier for myFunctionCall2 with an IF DEF so it's not there when USE_UNIVEL_CC is defined. I think that option 2 is the best choice, but it's your call. -- | Billy G. Allie| Domain: [EMAIL PROTECTED] | /| | 7436 Hartwell | MSN...: [EMAIL PROTECTED] |-/-|- | Dearborn, MI 48126| |/ |LLIE | (313) 582-1540| msg24832/pgp0.pgp Description: PGP signature
Re: [HACKERS] PostgreSQL supported platform report and a patch.
Larry Rosenman wrote: We already have success messages from Olivier Prenant for 7.3B4 on 8.0.0, and me for 7.1.3. I don't believe your changes are necessary. Was that using gcc or the native compiler? Was it in linux kernel personality mode or OpenUNIX mode. I was compiling using the native (UDK) compiler. and it failed in tuplesort.c. It was also unable to file the readline shared libraries without the changes to the makefiles or setting LD_RUN_PATH (which is a pain and is depreciated in OpenUNIX 8 and UnixWare 7). -- | Billy G. Allie| Domain: [EMAIL PROTECTED] | /| | 7436 Hartwell | MSN...: [EMAIL PROTECTED] |-/-|- | Dearborn, MI 48126| |/ |LLIE | (313) 582-1540| msg24833/pgp0.pgp Description: PGP signature
Re: [PORTS] [HACKERS] PostgreSQL supported platform report and a
--On Thursday, November 07, 2002 14:23:43 +0100 Olivier PRENANT [EMAIL PROTECTED] wrote: On Thu, 7 Nov 2002, Larry Rosenman wrote: Date: Thu, 07 Nov 2002 06:41:02 -0600 From: Larry Rosenman [EMAIL PROTECTED] To: [EMAIL PROTECTED] Cc: Billy G. Allie [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED] Subject: Re: [PORTS] [HACKERS] PostgreSQL supported platform report and a --On Thursday, November 07, 2002 13:32:18 +0100 Olivier PRENANT [EMAIL PROTECTED] wrote: That's true! But I had to export CFLAGS=-Xb to compile (this should be in port Makefile IMHO) Tom fixed that with a later tuplesort.c fix (per a discussion with the Caldera/SCO compiler guys). Huh! I just tried to compile 7.3b5 without CFLAGS=-Xb, it still bugs the compiler... Didn't for me :-( Wierd. -- Olivier PRENANT Tel: +33-5-61-50-97-00 (Work) Quartier d'Harraud Turrou +33-5-61-50-97-01 (Fax) 31190 AUTERIVE +33-6-07-63-80-64 (GSM) FRANCE Email: [EMAIL PROTECTED] - - Make your life a dream, make your dream a reality. (St Exupery) -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 972-414-9812 E-Mail: [EMAIL PROTECTED] US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749 ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] [GENERAL] Database replication... - Mission Critica
Mikheev, Vadim [EMAIL PROTECTED] writes: My presumption would be that if you initialize 2 databases to a known identical start, have all the same triggers and rules on both, then send all queries to both databases, you will have 2 identical databases at the end. This is wrong assumption. Agreed. Another simple example is: INSERT INTO foo VALUES (random()); Cheers, Neil -- Neil Conway [EMAIL PROTECTED] || PGP Key ID: DB3C29FC ---(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] RC1 on Friday?
Marc G. Fournier [EMAIL PROTECTED] writes: Tom, my understanding is that CONVERT stuff required an initdb, and was also the only thing 'critical' that went in ... correct? What impact does that have? For instance, could it cause one of the regression tests to fail, or is it something that is relatively benign? I would like to think it's a pretty safe change, but that's why we do betas ;-). More seriously, we are still attacking various portability issues, and there is still some undone docs work. I doubt we can make a tarball tomorrow that is an honest release candidate. Maybe Monday? regards, tom lane ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [PORTS] [HACKERS] PostgreSQL supported platform report and a
Olivier PRENANT [EMAIL PROTECTED] writes: Huh! I just tried to compile 7.3b5 without CFLAGS=-Xb, it still bugs the compiler... It won't get better if you don't show any details... regards, tom lane ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] [GENERAL] Database replication... - Mission Critica
On 4 Nov 2002 at 12:23, Mikheev, Vadim wrote: My presumption would be that if you initialize 2 databases to a known identical start, have all the same triggers and rules on both, then send all queries to both databases, you will have 2 identical databases at the end. This is wrong assumption. If 1st client executes UPDATE t SET a = 1 WHERE b = 2; 2nd client executes UPDATE t SET a = 2 WHERE b = 2; at the same time you don't know in what order these queries will be executed on two different servers (because you can't control what transaction will lock record(s) for update first). I guess we would need two phase commit in this case. Then it could be guaranteed. Bye Shridhar -- There comes to all races an ultimate crisis which you have yet to face One day our minds became so powerful we dared think of ourselves as gods. -- Sargon, Return to Tomorrow, stardate 4768.3 ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] RC1 on Friday?
Tom Lane wrote: Marc G. Fournier [EMAIL PROTECTED] writes: Tom, my understanding is that CONVERT stuff required an initdb, and was also the only thing 'critical' that went in ... correct? What impact does that have? For instance, could it cause one of the regression tests to fail, or is it something that is relatively benign? I would like to think it's a pretty safe change, but that's why we do betas ;-). More seriously, we are still attacking various portability issues, and there is still some undone docs work. I doubt we can make a tarball tomorrow that is an honest release candidate. Maybe Monday? OK, but we are already in month 2, week 1 on beta. As some point, we have to decide we are not going to do any more platform tweeking and move on to a release. If they really wanted their platform supported, they should have shown up on September. I am loosing tolerance for these last-minute changes. We should not hold up release to support some obscure platform. I don't think we want another 4 month beta! -- 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: [HACKERS] command
Be more specific with your question, what exactly are You trying to do ? Did you ment PL/PSQL script (stored procedure) , or You are asking about interfaces to PostgreSQL ? I suppose the right place to ask questions like that would be [EMAIL PROTECTED], not to hackers. regards ! On Tuesday 05 November 2002 14:19, Florian Litot wrote: what is the command to launch a sql script not in psql thanks ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] command
On Tue, 5 Nov 2002, Florian Litot wrote: what is the command to launch a sql script not in psql thanks without actually being IN psql, you can use it to run one line scripts like this: psql dbname -c -- 'single query goes here' or you can run a large file full of sql queries like this: psql dbname -f filename.sql ---(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] CREATE TABLE/AS does not allow WITH OIDS?
How would we make use of 'hasoids' in the case of multiple source tables, or a source table defined by an SRF? Choose a convention. At the moment, the first source table provides more characteristics to the target than do the other sources, and that could be true for OIDs also. I would be inclined to have the logic be that if *any* source table has OIDs, then the target gets them. Unless it was explicitly specified using the WITH/WITHOUT syntax of course. Unless we can define some consistent semantics for when we use the hasoids of the source table(s), I'd say we should just add the WITH/WITHOUT OIDS syntax. Right. There is no problem coming up with consistant semantics, though there may be a problem getting a consensus on what those should be. In the meantime we have broken compatibility with the previous release (since targets are created without OIDs) and should think about fixing that. - Thomas ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] protocol change in 7.4
There has been some previous discussion of changing the FE/BE protocol in 7.4, in order to fix several problems. I think this is worth doing: if we can resolve all these issues in a single release, it will lessen the upgrade difficulties for users. Here are a couple of other changes you might consider (maybe these changes already exist and I just don't know about them): a) Make much of the metadata sent to the client optional. When I execute 20 fetches against the same cursor, I don't need the same metadata 20 times. For narrow result sets, the metadata can easily double or triple the number of bytes sent across the net. It looks like the protocol needs the field count, but everything else seems to be sent for the convenience of the client application. b) Send a decoded version of atttypmod - specifically, decode the precision and scale for numeric types. ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
[HACKERS] problem building pg 7.3 beta 3 on solaris 8 -m64
Dave Miller ([EMAIL PROTECTED]) tells me this bug is fixed in gcc 3.2.1 (which does not appear to be distributed yet). FYI. alex ---(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] protocol change in 7.4
b) Send a decoded version of atttypmod - specifically, decode the precision and scale for numeric types. I want decode type,length,precision and scale regards Haris Peco ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] protocol change in 7.4
b) Send a decoded version of atttypmod - specifically, decode the precision and scale for numeric types. I want decode type,length,precision and scale Type is returned by PQftype(), length is returned by PQfsize(). Precision and scale are encoded in the return value from PQfmod() and you have to have a magic decoder ring to understand them. (Magic decoder rings are available, you just have to read the source code :-) PQftype() is not easy to use because it returns an OID instead of a name (or a standardized symbol), but I can't think of anything better to return to the client. Of course if you really want to make use of PQftype(), you can preload a client-side cache of type definitions. I seem to remember seeing a patch a while back that would build the cache and decode precision and scale too. PQfsize() is entertaining, but not often what you really want (you really want the width of the widest value in the column after conversion to some string format - it seems reasonable to let the client applicatin worry about that, although maybe that would be a useful client-side libpq function). ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] protocol change in 7.4
On Thursday 07 November 2002 09:50 pm, korry wrote: b) Send a decoded version of atttypmod - specifically, decode the precision and scale for numeric types. I want decode type,length,precision and scale Type is returned by PQftype(), length is returned by PQfsize(). Precision and scale are encoded in the return value from PQfmod() and you have to have a magic decoder ring to understand them. (Magic decoder rings are available, you just have to read the source code :-) PQftype() is not easy to use because it returns an OID instead of a name (or a standardized symbol), but I can't think of anything better to return to the client. Of course if you really want to make use of PQftype(), you can preload a client-side cache of type definitions. I seem to remember seeing a patch a while back that would build the cache and decode precision and scale too. PQfsize() is entertaining, but not often what you really want (you really want the width of the widest value in the column after conversion to some string format - it seems reasonable to let the client applicatin worry about that, although maybe that would be a useful client-side libpq function). I want this in any catalog view regards Haris Peco ---(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] Win32 port
Hi, all. I just wanted to give you an update on where my company (PeerDirect) is with regards to our native Windows port. We are planning on contributing the code for the native port sometime next month (in December). We would have liked to contribute it earlier, but our work schedules here didn't allow it. The state of the port is that it passes all postgres regression tests. It's been in BETA since early August with about 27 beta customers. The beta customers came from a post made to the cygwin mailing list (http://archives.postgresql.org/pgsql-cygwin/2002-08/msg00012.php). The BETA has proven successful and several problems were found and fixed. At this point you are welcome to run the latest version of this BETA. There is no installer, but there is a setenv.bat script to help setup the environment. The beta can be downloaded at: ftp://209.61.187.152/postgres/postgres_beta4.zip This version has its own catalog version which is slightly different than 7.2.1, so you'll need to do a pg_dump and pg_restore. If you find any issues, please don't mail me directly. Instead, please send emails to [EMAIL PROTECTED] Several people monitor this address and the issue will get resolved more quickly. There is still some cleanup work to do, such as migrating from 7.2.1 to 7.4, but my company is committed to contributing this port to the community by the end of the year. Regards, Katie Ward Principal Engineer [EMAIL PROTECTED] ---(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
[HACKERS] PL/PgSQL buglet / doc error
The 7.3 docs for the PL/PgSQL return statement say: RETURN with an expression is used to return from a PL/pgSQL function that does not return a set. [...] If you have declared the function to return void, then the expression can be omitted, and will be ignored in any case. However, that does not seem to be the case: nconway=# select version(); version -- PostgreSQL 7.4devel on i686-pc-linux-gnu, compiled by GCC 2.95.4 (1 row) nconway=# create table bar (a int); CREATE TABLE nconway=# create or replace function test_func() returns void as 'begin insert into bar values (5); end;' language 'plpgsql'; CREATE FUNCTION nconway=# select test_func(); WARNING: Error occurred while executing PL/pgSQL function test_func WARNING: at END of toplevel PL block ERROR: control reaches end of function without RETURN nconway=# create or replace function test_func() returns void as 'begin insert into bar values (5); return; end;' language 'plpgsql'; CREATE FUNCTION nconway=# select test_func(); test_func --- (1 row) Should this be implemented, or should the assertion that 'RETURN is optional' be removed from the docs? Cheers, Neil -- Neil Conway [EMAIL PROTECTED] || PGP Key ID: DB3C29FC ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] PL/PgSQL buglet / doc error
Stephan Szabo [EMAIL PROTECTED] writes: On 7 Nov 2002, Neil Conway wrote: If you have declared the function to return void, then the expression can be omitted, and will be ignored in any case. I'm not sure how you translated the above to return is optional. I'd read it as the expression portion of the return statement is optional if the function returns void. Thus you can say return; for the return because the expression is optional. Woops :-) There might be a case to be made for actually implementing this (not requiring a blank RETURN at the end of a function body if the function doesn't return anything), but the original bug is obviously a case of my misreading the docs. Sorry for the noise. Cheers, Neil -- Neil Conway [EMAIL PROTECTED] || PGP Key ID: DB3C29FC ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] [ pgsql-monitoring ]
Turn on query monitoring in the postgresql.conf and then go: select * from pg_stat_activity; Chris -Original Message-From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Osvâneo A. FerreiraSent: Wednesday, 6 November 2002 4:49 AMTo: [EMAIL PROTECTED]Subject: [HACKERS] [ pgsql-monitoring ] Hi, I hasa dinamic application, constructed on php, connectingin db postgres 7.2. I would like monitor the all established connection. I want know whish command is running at moment. Help, please !!! Osvâneo A. Ferreira [EMAIL PROTECTED]
Re: [HACKERS] Outstanding patches
I concur, but do we have some sort of commitment that the rest of the SQL200x sequence machinery will be supported eventually? Otherwise, adding some irrelevant syntax variations in limited places doesn't seem fruitful. Yes, I'll implement the rest of the SQL200x sequence stuff eventually. However, if you'd rather wait for me to finish it all and then commit it at that point, that's fine with me. I'd suggest contributing what you have now. Waiting just keeps others from contributing to the topic (which is not your intention certainly, but it would have that effect). - Thomas ---(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] Outstanding patches
Thomas Lockhart [EMAIL PROTECTED] writes: I'd suggest contributing what you have now. Waiting just keeps others from contributing to the topic (which is not your intention certainly, but it would have that effect). Right -- all the work I've done on the topic has been submitted to Bruce. I'm fine with it being committed as is (as you suggest), or waiting until there is more substantial work done on the topic. Cheers, Neil -- Neil Conway [EMAIL PROTECTED] || PGP Key ID: DB3C29FC ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] CREATE TABLE/AS does not allow WITH OIDS?
Neil Conway [EMAIL PROTECTED] writes: Unless we can define some consistent semantics for when we use the hasoids of the source table(s), I'd say we should just add the WITH/WITHOUT OIDS syntax. I agree with Neil: in many situations it's not reasonable to try to associate a unique source table with a CREATE AS or SELECT INTO, and therefore automatically propagating hasoids is doomed to failure. A WITH/WITHOUT OIDS option on CREATE TABLE AS might be reasonable. There are implementation gotchas to worry about. The reason the behavior changed in 7.3 is that with the new OIDS-are-optional tuple header layout, the top level plan node's tupdesc *must* have the correct hasoids setting, and it turned out to be too difficult to back-patch this decision into an already-built plan tree. It's hard even to get it to work for INSERT/UPDATE (see the notes in ExecAssignResultTypeFromTL), and SELECT INTO is such a wart on the side of the system that that solution doesn't work for it (see the notes in InitPlan). This area could use some rethinking in 7.4 (too late to mess with it for 7.3 though). Someday it would be worth restructuring CREATE AS/SELECT INTO so that they internally look like INSERT ... SELECT rather than a warty version of SELECT. (But INSERT ... SELECT is pretty warty itself; someday we need to fix the querytree structure so that there's not a forced one-to-one relationship between targetlists and rangetables. INSERT ... SELECT would really prefer to have two tlists and only one rtable.) regards, tom lane ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [HACKERS] CREATE TABLE/AS does not allow WITH OIDS?
I agree with Neil: in many situations it's not reasonable to try to associate a unique source table with a CREATE AS or SELECT INTO, and therefore automatically propagating hasoids is doomed to failure. Well, it certainly is reasonable to have better behavior than currently. We do something now, which is at odds with the previous convention (which also did something). A WITH/WITHOUT OIDS option on CREATE TABLE AS might be reasonable. Of course. There are implementation gotchas to worry about. The reason the behavior changed in 7.3 is that with the new OIDS-are-optional tuple header layout, the top level plan node's tupdesc *must* have the correct hasoids setting, and it turned out to be too difficult to back-patch this decision into an already-built plan tree. It's hard even to get it to work for INSERT/UPDATE (see the notes in ExecAssignResultTypeFromTL), and SELECT INTO is such a wart on the side of the system that that solution doesn't work for it (see the notes in InitPlan). This area could use some rethinking in 7.4 (too late to mess with it for 7.3 though). It is unfortunate that the optional-OIDs has this drawback; it perhaps should have been more explicit in the initial discussions. But I'm hearing about difficulties, not impossibilities, so that is encouraging ;) What would be required to have OIDs for all SELECT/INTO product tables for this release? That could fit into 7.3 and not break applications; the current convention for this (that is, dropping OID characteristics) might be characterized as an omission, not a choice. - Thomas ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [PORTS] [HACKERS] PostgreSQL supported platform report and a
On Thu, 7 Nov 2002, Larry Rosenman wrote: Date: Thu, 07 Nov 2002 08:41:58 -0600 From: Larry Rosenman [EMAIL PROTECTED] To: [EMAIL PROTECTED] Cc: Billy G. Allie [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED] Subject: Re: [PORTS] [HACKERS] PostgreSQL supported platform report and a Tom fixed that with a later tuplesort.c fix (per a discussion with the Caldera/SCO compiler guys). Huh! I just tried to compile 7.3b5 without CFLAGS=-Xb, it still bugs the compiler... Didn't for me :-( Wierd. BTW, this is on 7.1.1 not (yet) on 8.0.0 I'll let you know hopefully today. (How did you get 713 when it's due for december?) Can I have a copy? -- Olivier PRENANT Tel:+33-5-61-50-97-00 (Work) Quartier d'Harraud Turrou +33-5-61-50-97-01 (Fax) 31190 AUTERIVE +33-6-07-63-80-64 (GSM) FRANCE Email: [EMAIL PROTECTED] - - Make your life a dream, make your dream a reality. (St Exupery) -- Olivier PRENANT Tel:+33-5-61-50-97-00 (Work) Quartier d'Harraud Turrou +33-5-61-50-97-01 (Fax) 31190 AUTERIVE +33-6-07-63-80-64 (GSM) FRANCE Email: [EMAIL PROTECTED] -- Make your life a dream, make your dream a reality. (St Exupery) ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [PORTS] [HACKERS] PostgreSQL supported platform report and a
--On Thursday, November 07, 2002 15:44:37 +0100 Olivier PRENANT [EMAIL PROTECTED] wrote: On Thu, 7 Nov 2002, Larry Rosenman wrote: Date: Thu, 07 Nov 2002 08:41:58 -0600 From: Larry Rosenman [EMAIL PROTECTED] To: [EMAIL PROTECTED] Cc: Billy G. Allie [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED] Subject: Re: [PORTS] [HACKERS] PostgreSQL supported platform report and a Tom fixed that with a later tuplesort.c fix (per a discussion with the Caldera/SCO compiler guys). Huh! I just tried to compile 7.3b5 without CFLAGS=-Xb, it still bugs the compiler... Didn't for me :-( Wierd. BTW, this is on 7.1.1 not (yet) on 8.0.0 I'll let you know hopefully today. (How did you get 713 when it's due for december?) Can I have a copy? I'm on the Beta. No, I can't give it to you. You might want to sign up on http://www.caldera.com/beta/ to get in on the next one. -- Olivier PRENANT Tel: +33-5-61-50-97-00 (Work) Quartier d'Harraud Turrou +33-5-61-50-97-01 (Fax) 31190 AUTERIVE +33-6-07-63-80-64 (GSM) FRANCE Email: [EMAIL PROTECTED] -- --- - Make your life a dream, make your dream a reality. (St Exupery) -- Olivier PRENANT Tel: +33-5-61-50-97-00 (Work) Quartier d'Harraud Turrou +33-5-61-50-97-01 (Fax) 31190 AUTERIVE +33-6-07-63-80-64 (GSM) FRANCE Email: [EMAIL PROTECTED] - - Make your life a dream, make your dream a reality. (St Exupery) -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 972-414-9812 E-Mail: [EMAIL PROTECTED] US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749 ---(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] RC1 on Friday?
Tom Lane wrote: Bruce Momjian [EMAIL PROTECTED] writes: I am loosing tolerance for these last-minute changes. We should not hold up release to support some obscure platform. As long as the docs are unfinished, I don't feel any particular compunction about not applying portability fixes. If you want RC1 tomorrow, when are you going to update the release history? That takes 5 minutes. I will do it now. I am not pushing Friday, but I am saying we need to have some urgency to get to RC1 or we will drag. -- 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: [PORTS] [HACKERS] PostgreSQL supported platform report and a
It looks like you do **NOT** have B4 or B5 LER --On Thursday, November 07, 2002 17:00:21 +0100 Olivier PRENANT [EMAIL PROTECTED] wrote: On Thu, 7 Nov 2002, Tom Lane wrote: Date: Thu, 07 Nov 2002 10:21:25 -0500 From: Tom Lane [EMAIL PROTECTED] To: [EMAIL PROTECTED] Cc: Larry Rosenman [EMAIL PROTECTED], Billy G. Allie [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED] Subject: Re: [PORTS] [HACKERS] PostgreSQL supported platform report and a Olivier PRENANT [EMAIL PROTECTED] writes: Huh! I just tried to compile 7.3b5 without CFLAGS=-Xb, it still bugs the compiler... It won't get better if you don't show any details... Ok... (sorry) this is on UW 711 WITHOUT CFLAGS=-Xb: Script started on Thu Nov 7 16:57:05 2002 $ cd postgresql*5 $ make Using GNU make found at /usr/local/bin/gmake /usr/local/bin/gmake -C doc all gmake[1]: Entering directory `/home/postgres/postgresql-7.3b5/doc' gmake[1]: Nothing to be done for `all'. gmake[1]: Leaving directory `/home/postgres/postgresql-7.3b5/doc' /usr/local/bin/gmake -C src all gmake[1]: Entering directory `/home/postgres/postgresql-7.3b5/src' /usr/local/bin/gmake -C port all gmake[2]: Entering directory `/home/postgres/postgresql-7.3b5/src/port' gmake[2]: Nothing to be done for `all'. gmake[2]: Leaving directory `/home/postgres/postgresql-7.3b5/src/port' /usr/local/bin/gmake -C backend all gmake[2]: Entering directory `/home/postgres/postgresql-7.3b5/src/backend' /usr/local/bin/gmake -C ../../src/port all gmake[3]: Entering directory `/home/postgres/postgresql-7.3b5/src/port' gmake[3]: Nothing to be done for `all'. gmake[3]: Leaving directory `/home/postgres/postgresql-7.3b5/src/port' /usr/local/bin/gmake -C access all gmake[3]: Entering directory `/home/postgres/postgresql-7.3b5/src/backend/access' /usr/local/bin/gmake -C common SUBSYS.o gmake[4]: Entering directory `/home/postgres/postgresql-7.3b5/src/backend/access/common' gmake[4]: `SUBSYS.o' is up to date. gmake[4]: Leaving directory `/home/postgres/postgresql-7.3b5/src/backend/access/common' /usr/local/bin/gmake -C gist SUBSYS.o gmake[4]: Entering directory `/home/postgres/postgresql-7.3b5/src/backend/access/gist' gmake[4]: `SUBSYS.o' is up to date. gmake[4]: Leaving directory `/home/postgres/postgresql-7.3b5/src/backend/access/gist' /usr/local/bin/gmake -C hash SUBSYS.o gmake[4]: Entering directory `/home/postgres/postgresql-7.3b5/src/backend/access/hash' gmake[4]: `SUBSYS.o' is up to date. gmake[4]: Leaving directory `/home/postgres/postgresql-7.3b5/src/backend/access/hash' /usr/local/bin/gmake -C heap SUBSYS.o gmake[4]: Entering directory `/home/postgres/postgresql-7.3b5/src/backend/access/heap' gmake[4]: `SUBSYS.o' is up to date. gmake[4]: Leaving directory `/home/postgres/postgresql-7.3b5/src/backend/access/heap' /usr/local/bin/gmake -C index SUBSYS.o gmake[4]: Entering directory `/home/postgres/postgresql-7.3b5/src/backend/access/index' gmake[4]: `SUBSYS.o' is up to date. gmake[4]: Leaving directory `/home/postgres/postgresql-7.3b5/src/backend/access/index' /usr/local/bin/gmake -C nbtree SUBSYS.o gmake[4]: Entering directory `/home/postgres/postgresql-7.3b5/src/backend/access/nbtree' gmake[4]: `SUBSYS.o' is up to date. gmake[4]: Leaving directory `/home/postgres/postgresql-7.3b5/src/backend/access/nbtree' /usr/local/bin/gmake -C rtree SUBSYS.o gmake[4]: Entering directory `/home/postgres/postgresql-7.3b5/src/backend/access/rtree' gmake[4]: `SUBSYS.o' is up to date. gmake[4]: Leaving directory `/home/postgres/postgresql-7.3b5/src/backend/access/rtree' /usr/local/bin/gmake -C transam SUBSYS.o gmake[4]: Entering directory `/home/postgres/postgresql-7.3b5/src/backend/access/transam' gmake[4]: `SUBSYS.o' is up to date. gmake[4]: Leaving directory `/home/postgres/postgresql-7.3b5/src/backend/access/transam' gmake[3]: Leaving directory `/home/postgres/postgresql-7.3b5/src/backend/access' /usr/local/bin/gmake -C bootstrap all gmake[3]: Entering directory `/home/postgres/postgresql-7.3b5/src/backend/bootstrap' gmake[3]: Nothing to be done for `all'. gmake[3]: Leaving directory `/home/postgres/postgresql-7.3b5/src/backend/bootstrap' /usr/local/bin/gmake -C catalog all gmake[3]: Entering directory `/home/postgres/postgresql-7.3b5/src/backend/catalog' gmake[3]: Nothing to be done for `all'. gmake[3]: Leaving directory `/home/postgres/postgresql-7.3b5/src/backend/catalog' /usr/local/bin/gmake -C parser all gmake[3]: Entering directory `/home/postgres/postgresql-7.3b5/src/backend/parser' gmake[3]: Nothing to be done for `all'. gmake[3]: Leaving directory `/home/postgres/postgresql-7.3b5/src/backend/parser' /usr/local/bin/gmake -C commands all gmake[3]: Entering directory `/home/postgres/postgresql-7.3b5/src/backend/commands' gmake[3]: Nothing to be done for `all'. gmake[3]: Leaving directory `/home/postgres/postgresql-7.3b5/src/backend/commands' /usr/local/bin/gmake -C executor all gmake[3]: Entering directory `/home/postgres/postgresql-7.3b5/src/backend/executor' gmake[3]: Nothing to be done for
Re: [HACKERS] RC1 on Friday?
Bruce Momjian [EMAIL PROTECTED] writes: I am loosing tolerance for these last-minute changes. We should not hold up release to support some obscure platform. As long as the docs are unfinished, I don't feel any particular compunction about not applying portability fixes. If you want RC1 tomorrow, when are you going to update the release history? regards, tom lane ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [PORTS] [HACKERS] PostgreSQL supported platform report and a
On Thu, 7 Nov 2002, Tom Lane wrote: Date: Thu, 07 Nov 2002 10:21:25 -0500 From: Tom Lane [EMAIL PROTECTED] To: [EMAIL PROTECTED] Cc: Larry Rosenman [EMAIL PROTECTED], Billy G. Allie [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED] Subject: Re: [PORTS] [HACKERS] PostgreSQL supported platform report and a Olivier PRENANT [EMAIL PROTECTED] writes: Huh! I just tried to compile 7.3b5 without CFLAGS=-Xb, it still bugs the compiler... It won't get better if you don't show any details... Ok... (sorry) this is on UW 711 WITHOUT CFLAGS=-Xb: Script started on Thu Nov 7 16:57:05 2002 $ cd postgresql*5 $ make Using GNU make found at /usr/local/bin/gmake /usr/local/bin/gmake -C doc all gmake[1]: Entering directory `/home/postgres/postgresql-7.3b5/doc' gmake[1]: Nothing to be done for `all'. gmake[1]: Leaving directory `/home/postgres/postgresql-7.3b5/doc' /usr/local/bin/gmake -C src all gmake[1]: Entering directory `/home/postgres/postgresql-7.3b5/src' /usr/local/bin/gmake -C port all gmake[2]: Entering directory `/home/postgres/postgresql-7.3b5/src/port' gmake[2]: Nothing to be done for `all'. gmake[2]: Leaving directory `/home/postgres/postgresql-7.3b5/src/port' /usr/local/bin/gmake -C backend all gmake[2]: Entering directory `/home/postgres/postgresql-7.3b5/src/backend' /usr/local/bin/gmake -C ../../src/port all gmake[3]: Entering directory `/home/postgres/postgresql-7.3b5/src/port' gmake[3]: Nothing to be done for `all'. gmake[3]: Leaving directory `/home/postgres/postgresql-7.3b5/src/port' /usr/local/bin/gmake -C access all gmake[3]: Entering directory `/home/postgres/postgresql-7.3b5/src/backend/access' /usr/local/bin/gmake -C common SUBSYS.o gmake[4]: Entering directory `/home/postgres/postgresql-7.3b5/src/backend/access/common' gmake[4]: `SUBSYS.o' is up to date. gmake[4]: Leaving directory `/home/postgres/postgresql-7.3b5/src/backend/access/common' /usr/local/bin/gmake -C gist SUBSYS.o gmake[4]: Entering directory `/home/postgres/postgresql-7.3b5/src/backend/access/gist' gmake[4]: `SUBSYS.o' is up to date. gmake[4]: Leaving directory `/home/postgres/postgresql-7.3b5/src/backend/access/gist' /usr/local/bin/gmake -C hash SUBSYS.o gmake[4]: Entering directory `/home/postgres/postgresql-7.3b5/src/backend/access/hash' gmake[4]: `SUBSYS.o' is up to date. gmake[4]: Leaving directory `/home/postgres/postgresql-7.3b5/src/backend/access/hash' /usr/local/bin/gmake -C heap SUBSYS.o gmake[4]: Entering directory `/home/postgres/postgresql-7.3b5/src/backend/access/heap' gmake[4]: `SUBSYS.o' is up to date. gmake[4]: Leaving directory `/home/postgres/postgresql-7.3b5/src/backend/access/heap' /usr/local/bin/gmake -C index SUBSYS.o gmake[4]: Entering directory `/home/postgres/postgresql-7.3b5/src/backend/access/index' gmake[4]: `SUBSYS.o' is up to date. gmake[4]: Leaving directory `/home/postgres/postgresql-7.3b5/src/backend/access/index' /usr/local/bin/gmake -C nbtree SUBSYS.o gmake[4]: Entering directory `/home/postgres/postgresql-7.3b5/src/backend/access/nbtree' gmake[4]: `SUBSYS.o' is up to date. gmake[4]: Leaving directory `/home/postgres/postgresql-7.3b5/src/backend/access/nbtree' /usr/local/bin/gmake -C rtree SUBSYS.o gmake[4]: Entering directory `/home/postgres/postgresql-7.3b5/src/backend/access/rtree' gmake[4]: `SUBSYS.o' is up to date. gmake[4]: Leaving directory `/home/postgres/postgresql-7.3b5/src/backend/access/rtree' /usr/local/bin/gmake -C transam SUBSYS.o gmake[4]: Entering directory `/home/postgres/postgresql-7.3b5/src/backend/access/transam' gmake[4]: `SUBSYS.o' is up to date. gmake[4]: Leaving directory `/home/postgres/postgresql-7.3b5/src/backend/access/transam' gmake[3]: Leaving directory `/home/postgres/postgresql-7.3b5/src/backend/access' /usr/local/bin/gmake -C bootstrap all gmake[3]: Entering directory `/home/postgres/postgresql-7.3b5/src/backend/bootstrap' gmake[3]: Nothing to be done for `all'. gmake[3]: Leaving directory `/home/postgres/postgresql-7.3b5/src/backend/bootstrap' /usr/local/bin/gmake -C catalog all gmake[3]: Entering directory `/home/postgres/postgresql-7.3b5/src/backend/catalog' gmake[3]: Nothing to be done for `all'. gmake[3]: Leaving directory `/home/postgres/postgresql-7.3b5/src/backend/catalog' /usr/local/bin/gmake -C parser all gmake[3]: Entering directory `/home/postgres/postgresql-7.3b5/src/backend/parser' gmake[3]: Nothing to be done for `all'. gmake[3]: Leaving directory `/home/postgres/postgresql-7.3b5/src/backend/parser' /usr/local/bin/gmake -C commands all gmake[3]: Entering directory `/home/postgres/postgresql-7.3b5/src/backend/commands' gmake[3]: Nothing to be done for `all'. gmake[3]: Leaving directory `/home/postgres/postgresql-7.3b5/src/backend/commands' /usr/local/bin/gmake -C executor all gmake[3]: Entering directory `/home/postgres/postgresql-7.3b5/src/backend/executor' gmake[3]: Nothing to be done for `all'. gmake[3]: Leaving directory `/home/postgres/postgresql-7.3b5/src/backend/executor' /usr/local/bin/gmake -C lib all gmake[3]:
Re: [HACKERS] [GENERAL] Database replication... - Mission Critica
This is wrong assumption. If 1st client executes UPDATE t SET a = 1 WHERE b = 2; 2nd client executes UPDATE t SET a = 2 WHERE b = 2; at the same time you don't know in what order these queries will be executed on two different servers (because you can't control what transaction will lock record(s) for update first). I guess we would need two phase commit in this case. Then it could be guaranteed. I'm not sure 2PC would guarantee order here. There is potential for a dead lock across system boundary in this example. If the pre commit messages were sent at the same time which server would lock the resource? Darren ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
[HACKERS] postgresql.conf server_min_messages
I now realize that server_min_messages should have been log_min_messages. The log_* grouping was done after I added server_min_messages and I didn't see the similarity. Also, show_parser_stats, etc. should be log_parser_stats because the output goes to the log and not to the user's terminal. I may clean that up in 7.4. Too late for 7.3. -- 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: [PORTS] [HACKERS] PostgreSQL supported platform report and a
Olivier PRENANT [EMAIL PROTECTED] writes: *WHAT??** this directory has hust been created by de-taring postgresql-7.3b5.tar.gz from my own mirror dated nov 6 20:04... Well, there's something darn weird here. Is src/backend/utils/sort/tuplesort.c version 1.28 or 1.29? At line 1838, do you see inline int32 ApplySortFunction(FmgrInfo *sortFunction, SortFunctionKind kind, or static inline int32 inlineApplySortFunction(FmgrInfo *sortFunction, SortFunctionKind kind, regards, tom lane ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [PORTS] [HACKERS] PostgreSQL supported platform report and a
*WHAT??** this directory has hust been created by de-taring postgresql-7.3b5.tar.gz from my own mirror dated nov 6 20:04... On Thu, 7 Nov 2002, Larry Rosenman wrote: Date: Thu, 07 Nov 2002 10:07:37 -0600 From: Larry Rosenman [EMAIL PROTECTED] To: [EMAIL PROTECTED], Tom Lane [EMAIL PROTECTED] Cc: Billy G. Allie [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED] Subject: Re: [PORTS] [HACKERS] PostgreSQL supported platform report and a It looks like you do **NOT** have B4 or B5 LER --On Thursday, November 07, 2002 17:00:21 +0100 Olivier PRENANT [EMAIL PROTECTED] wrote: On Thu, 7 Nov 2002, Tom Lane wrote: Date: Thu, 07 Nov 2002 10:21:25 -0500 From: Tom Lane [EMAIL PROTECTED] To: [EMAIL PROTECTED] Cc: Larry Rosenman [EMAIL PROTECTED], Billy G. Allie [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED] Subject: Re: [PORTS] [HACKERS] PostgreSQL supported platform report and a Olivier PRENANT [EMAIL PROTECTED] writes: Huh! I just tried to compile 7.3b5 without CFLAGS=-Xb, it still bugs the compiler... It won't get better if you don't show any details... Ok... (sorry) this is on UW 711 WITHOUT CFLAGS=-Xb: Script started on Thu Nov 7 16:57:05 2002 $ cd postgresql*5 $ make Using GNU make found at /usr/local/bin/gmake /usr/local/bin/gmake -C doc all gmake[1]: Entering directory `/home/postgres/postgresql-7.3b5/doc' gmake[1]: Nothing to be done for `all'. gmake[1]: Leaving directory `/home/postgres/postgresql-7.3b5/doc' /usr/local/bin/gmake -C src all gmake[1]: Entering directory `/home/postgres/postgresql-7.3b5/src' /usr/local/bin/gmake -C port all gmake[2]: Entering directory `/home/postgres/postgresql-7.3b5/src/port' gmake[2]: Nothing to be done for `all'. gmake[2]: Leaving directory `/home/postgres/postgresql-7.3b5/src/port' /usr/local/bin/gmake -C backend all gmake[2]: Entering directory `/home/postgres/postgresql-7.3b5/src/backend' /usr/local/bin/gmake -C ../../src/port all gmake[3]: Entering directory `/home/postgres/postgresql-7.3b5/src/port' gmake[3]: Nothing to be done for `all'. gmake[3]: Leaving directory `/home/postgres/postgresql-7.3b5/src/port' /usr/local/bin/gmake -C access all gmake[3]: Entering directory `/home/postgres/postgresql-7.3b5/src/backend/access' /usr/local/bin/gmake -C common SUBSYS.o gmake[4]: Entering directory `/home/postgres/postgresql-7.3b5/src/backend/access/common' gmake[4]: `SUBSYS.o' is up to date. gmake[4]: Leaving directory `/home/postgres/postgresql-7.3b5/src/backend/access/common' /usr/local/bin/gmake -C gist SUBSYS.o gmake[4]: Entering directory `/home/postgres/postgresql-7.3b5/src/backend/access/gist' gmake[4]: `SUBSYS.o' is up to date. gmake[4]: Leaving directory `/home/postgres/postgresql-7.3b5/src/backend/access/gist' /usr/local/bin/gmake -C hash SUBSYS.o gmake[4]: Entering directory `/home/postgres/postgresql-7.3b5/src/backend/access/hash' gmake[4]: `SUBSYS.o' is up to date. gmake[4]: Leaving directory `/home/postgres/postgresql-7.3b5/src/backend/access/hash' /usr/local/bin/gmake -C heap SUBSYS.o gmake[4]: Entering directory `/home/postgres/postgresql-7.3b5/src/backend/access/heap' gmake[4]: `SUBSYS.o' is up to date. gmake[4]: Leaving directory `/home/postgres/postgresql-7.3b5/src/backend/access/heap' /usr/local/bin/gmake -C index SUBSYS.o gmake[4]: Entering directory `/home/postgres/postgresql-7.3b5/src/backend/access/index' gmake[4]: `SUBSYS.o' is up to date. gmake[4]: Leaving directory `/home/postgres/postgresql-7.3b5/src/backend/access/index' /usr/local/bin/gmake -C nbtree SUBSYS.o gmake[4]: Entering directory `/home/postgres/postgresql-7.3b5/src/backend/access/nbtree' gmake[4]: `SUBSYS.o' is up to date. gmake[4]: Leaving directory `/home/postgres/postgresql-7.3b5/src/backend/access/nbtree' /usr/local/bin/gmake -C rtree SUBSYS.o gmake[4]: Entering directory `/home/postgres/postgresql-7.3b5/src/backend/access/rtree' gmake[4]: `SUBSYS.o' is up to date. gmake[4]: Leaving directory `/home/postgres/postgresql-7.3b5/src/backend/access/rtree' /usr/local/bin/gmake -C transam SUBSYS.o gmake[4]: Entering directory `/home/postgres/postgresql-7.3b5/src/backend/access/transam' gmake[4]: `SUBSYS.o' is up to date. gmake[4]: Leaving directory `/home/postgres/postgresql-7.3b5/src/backend/access/transam' gmake[3]: Leaving directory `/home/postgres/postgresql-7.3b5/src/backend/access' /usr/local/bin/gmake -C bootstrap all gmake[3]: Entering directory `/home/postgres/postgresql-7.3b5/src/backend/bootstrap' gmake[3]: Nothing to be done for `all'. gmake[3]: Leaving directory `/home/postgres/postgresql-7.3b5/src/backend/bootstrap' /usr/local/bin/gmake -C catalog all gmake[3]: Entering directory `/home/postgres/postgresql-7.3b5/src/backend/catalog' gmake[3]: Nothing to be done for `all'. gmake[3]: Leaving directory
Re: [PORTS] [HACKERS] PostgreSQL supported platform report and a
I see the latter in both b4 and b5! I've just relaunched my mirroring procedure and it did'nt pick another b4 or b5! What happens?? Regards, On Thu, 7 Nov 2002, Tom Lane wrote: Date: Thu, 07 Nov 2002 11:26:42 -0500 From: Tom Lane [EMAIL PROTECTED] To: [EMAIL PROTECTED] Cc: Larry Rosenman [EMAIL PROTECTED], Billy G. Allie [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED] Subject: Re: [PORTS] [HACKERS] PostgreSQL supported platform report and a Olivier PRENANT [EMAIL PROTECTED] writes: *WHAT??** this directory has hust been created by de-taring postgresql-7.3b5.tar.gz from my own mirror dated nov 6 20:04... Well, there's something darn weird here. Is src/backend/utils/sort/tuplesort.c version 1.28 or 1.29? At line 1838, do you see inline int32 ApplySortFunction(FmgrInfo *sortFunction, SortFunctionKind kind, or static inline int32 inlineApplySortFunction(FmgrInfo *sortFunction, SortFunctionKind kind, regards, tom lane -- Olivier PRENANT Tel:+33-5-61-50-97-00 (Work) Quartier d'Harraud Turrou +33-5-61-50-97-01 (Fax) 31190 AUTERIVE +33-6-07-63-80-64 (GSM) FRANCE Email: [EMAIL PROTECTED] -- Make your life a dream, make your dream a reality. (St Exupery) ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
[HACKERS] CREATE TABLE/AS does not allow WITH OIDS?
... and the same for SELECT/INTO Also, the hasoids (or equivalent) attribute is not picked up from the source table which would be another way to push this property into the target table. One or both of these mechanisms (I'd think both should be available) would seem to be required to make these constructs useful in environments requiring OIDs. This seems to be a trivial but serious omission for this release. Comments and suggestions? - Thomas From a syntax PoV, CREATE TABLE name WITH OIDS AS ... works. Haven't worked out how to do the same for SELECT/INTO. ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [PORTS] [HACKERS] PostgreSQL supported platform report and a
It **LOOKS** right. I'm about to double check it on 7.1.3. Olivier, is this the 7.1.1b FS Compiler? I wonder if a bug fix made it in... Wierd. --On Thursday, November 07, 2002 17:34:49 +0100 Olivier PRENANT [EMAIL PROTECTED] wrote: I see the latter in both b4 and b5! I've just relaunched my mirroring procedure and it did'nt pick another b4 or b5! What happens?? Regards, On Thu, 7 Nov 2002, Tom Lane wrote: Date: Thu, 07 Nov 2002 11:26:42 -0500 From: Tom Lane [EMAIL PROTECTED] To: [EMAIL PROTECTED] Cc: Larry Rosenman [EMAIL PROTECTED], Billy G. Allie [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED] Subject: Re: [PORTS] [HACKERS] PostgreSQL supported platform report and a Olivier PRENANT [EMAIL PROTECTED] writes: *WHAT??** this directory has hust been created by de-taring postgresql-7.3b5.tar.gz from my own mirror dated nov 6 20:04... Well, there's something darn weird here. Is src/backend/utils/sort/tuplesort.c version 1.28 or 1.29? At line 1838, do you see inline int32 ApplySortFunction(FmgrInfo *sortFunction, SortFunctionKind kind, or static inline int32 inlineApplySortFunction(FmgrInfo *sortFunction, SortFunctionKind kind, regards, tom lane -- Olivier PRENANT Tel: +33-5-61-50-97-00 (Work) Quartier d'Harraud Turrou +33-5-61-50-97-01 (Fax) 31190 AUTERIVE +33-6-07-63-80-64 (GSM) FRANCE Email: [EMAIL PROTECTED] - - Make your life a dream, make your dream a reality. (St Exupery) -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 972-414-9812 E-Mail: [EMAIL PROTECTED] US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749 ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [PORTS] [HACKERS] PostgreSQL supported platform report and a
FS== Feature Supplement. I've got a compile running with the 7.3b5 tarball on my 7.1.3 system (with the newer compiler). We'll see. :-) --On Thursday, November 07, 2002 17:40:24 +0100 Olivier PRENANT [EMAIL PROTECTED] wrote: What's FS, it(s the 7.1.1b compiler yes. I don't mind having CFLAGS=-Xb though, done it for php already... By everyone says this should go off so.. Regards On Thu, 7 Nov 2002, Larry Rosenman wrote: Date: Thu, 07 Nov 2002 10:37:36 -0600 From: Larry Rosenman [EMAIL PROTECTED] To: [EMAIL PROTECTED], Tom Lane [EMAIL PROTECTED] Cc: Billy G. Allie [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED] Subject: Re: [PORTS] [HACKERS] PostgreSQL supported platform report and a It **LOOKS** right. I'm about to double check it on 7.1.3. Olivier, is this the 7.1.1b FS Compiler? I wonder if a bug fix made it in... Wierd. --On Thursday, November 07, 2002 17:34:49 +0100 Olivier PRENANT [EMAIL PROTECTED] wrote: I see the latter in both b4 and b5! I've just relaunched my mirroring procedure and it did'nt pick another b4 or b5! What happens?? Regards, On Thu, 7 Nov 2002, Tom Lane wrote: Date: Thu, 07 Nov 2002 11:26:42 -0500 From: Tom Lane [EMAIL PROTECTED] To: [EMAIL PROTECTED] Cc: Larry Rosenman [EMAIL PROTECTED], Billy G. Allie [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED] Subject: Re: [PORTS] [HACKERS] PostgreSQL supported platform report and a Olivier PRENANT [EMAIL PROTECTED] writes: *WHAT??** this directory has hust been created by de-taring postgresql-7.3b5.tar.gz from my own mirror dated nov 6 20:04... Well, there's something darn weird here. Is src/backend/utils/sort/tuplesort.c version 1.28 or 1.29? At line 1838, do you see inline int32 ApplySortFunction(FmgrInfo *sortFunction, SortFunctionKind kind, or static inline int32 inlineApplySortFunction(FmgrInfo *sortFunction, SortFunctionKind kind, regards, tom lane -- Olivier PRENANT Tel: +33-5-61-50-97-00 (Work) Quartier d'Harraud Turrou +33-5-61-50-97-01 (Fax) 31190 AUTERIVE +33-6-07-63-80-64 (GSM) FRANCE Email: [EMAIL PROTECTED] -- --- - Make your life a dream, make your dream a reality. (St Exupery) -- Olivier PRENANT Tel: +33-5-61-50-97-00 (Work) Quartier d'Harraud Turrou +33-5-61-50-97-01 (Fax) 31190 AUTERIVE +33-6-07-63-80-64 (GSM) FRANCE Email: [EMAIL PROTECTED] - - Make your life a dream, make your dream a reality. (St Exupery) -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 972-414-9812 E-Mail: [EMAIL PROTECTED] US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749 ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [PORTS] [HACKERS] PostgreSQL supported platform report and a
What's FS, it(s the 7.1.1b compiler yes. I don't mind having CFLAGS=-Xb though, done it for php already... By everyone says this should go off so.. Regards On Thu, 7 Nov 2002, Larry Rosenman wrote: Date: Thu, 07 Nov 2002 10:37:36 -0600 From: Larry Rosenman [EMAIL PROTECTED] To: [EMAIL PROTECTED], Tom Lane [EMAIL PROTECTED] Cc: Billy G. Allie [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED] Subject: Re: [PORTS] [HACKERS] PostgreSQL supported platform report and a It **LOOKS** right. I'm about to double check it on 7.1.3. Olivier, is this the 7.1.1b FS Compiler? I wonder if a bug fix made it in... Wierd. --On Thursday, November 07, 2002 17:34:49 +0100 Olivier PRENANT [EMAIL PROTECTED] wrote: I see the latter in both b4 and b5! I've just relaunched my mirroring procedure and it did'nt pick another b4 or b5! What happens?? Regards, On Thu, 7 Nov 2002, Tom Lane wrote: Date: Thu, 07 Nov 2002 11:26:42 -0500 From: Tom Lane [EMAIL PROTECTED] To: [EMAIL PROTECTED] Cc: Larry Rosenman [EMAIL PROTECTED], Billy G. Allie [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED] Subject: Re: [PORTS] [HACKERS] PostgreSQL supported platform report and a Olivier PRENANT [EMAIL PROTECTED] writes: *WHAT??** this directory has hust been created by de-taring postgresql-7.3b5.tar.gz from my own mirror dated nov 6 20:04... Well, there's something darn weird here. Is src/backend/utils/sort/tuplesort.c version 1.28 or 1.29? At line 1838, do you see inline int32 ApplySortFunction(FmgrInfo *sortFunction, SortFunctionKind kind, or static inline int32 inlineApplySortFunction(FmgrInfo *sortFunction, SortFunctionKind kind, regards, tom lane -- Olivier PRENANT Tel:+33-5-61-50-97-00 (Work) Quartier d'Harraud Turrou +33-5-61-50-97-01 (Fax) 31190 AUTERIVE +33-6-07-63-80-64 (GSM) FRANCE Email: [EMAIL PROTECTED] - - Make your life a dream, make your dream a reality. (St Exupery) -- Olivier PRENANT Tel:+33-5-61-50-97-00 (Work) Quartier d'Harraud Turrou +33-5-61-50-97-01 (Fax) 31190 AUTERIVE +33-6-07-63-80-64 (GSM) FRANCE Email: [EMAIL PROTECTED] -- Make your life a dream, make your dream a reality. (St Exupery) ---(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: [PORTS] [HACKERS] PostgreSQL supported platform report and a
cc -O -g -I../../../../src/include -I/usr/local/include -c -o tuplesort.o tuplesort.c UX:cc: WARNING: debugging and optimization mutually exclusive; -O disabled It still passes here. I really wonder if they fixed something in the 4.1 compiler. IIRC the 7.1.1b compiler is 4.0. Truly wierd. LER --On Thursday, November 07, 2002 17:40:24 +0100 Olivier PRENANT [EMAIL PROTECTED] wrote: What's FS, it(s the 7.1.1b compiler yes. I don't mind having CFLAGS=-Xb though, done it for php already... By everyone says this should go off so.. Regards On Thu, 7 Nov 2002, Larry Rosenman wrote: Date: Thu, 07 Nov 2002 10:37:36 -0600 From: Larry Rosenman [EMAIL PROTECTED] To: [EMAIL PROTECTED], Tom Lane [EMAIL PROTECTED] Cc: Billy G. Allie [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED] Subject: Re: [PORTS] [HACKERS] PostgreSQL supported platform report and a It **LOOKS** right. I'm about to double check it on 7.1.3. Olivier, is this the 7.1.1b FS Compiler? I wonder if a bug fix made it in... Wierd. --On Thursday, November 07, 2002 17:34:49 +0100 Olivier PRENANT [EMAIL PROTECTED] wrote: I see the latter in both b4 and b5! I've just relaunched my mirroring procedure and it did'nt pick another b4 or b5! What happens?? Regards, On Thu, 7 Nov 2002, Tom Lane wrote: Date: Thu, 07 Nov 2002 11:26:42 -0500 From: Tom Lane [EMAIL PROTECTED] To: [EMAIL PROTECTED] Cc: Larry Rosenman [EMAIL PROTECTED], Billy G. Allie [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED] Subject: Re: [PORTS] [HACKERS] PostgreSQL supported platform report and a Olivier PRENANT [EMAIL PROTECTED] writes: *WHAT??** this directory has hust been created by de-taring postgresql-7.3b5.tar.gz from my own mirror dated nov 6 20:04... Well, there's something darn weird here. Is src/backend/utils/sort/tuplesort.c version 1.28 or 1.29? At line 1838, do you see inline int32 ApplySortFunction(FmgrInfo *sortFunction, SortFunctionKind kind, or static inline int32 inlineApplySortFunction(FmgrInfo *sortFunction, SortFunctionKind kind, regards, tom lane -- Olivier PRENANT Tel: +33-5-61-50-97-00 (Work) Quartier d'Harraud Turrou +33-5-61-50-97-01 (Fax) 31190 AUTERIVE +33-6-07-63-80-64 (GSM) FRANCE Email: [EMAIL PROTECTED] -- --- - Make your life a dream, make your dream a reality. (St Exupery) -- Olivier PRENANT Tel: +33-5-61-50-97-00 (Work) Quartier d'Harraud Turrou +33-5-61-50-97-01 (Fax) 31190 AUTERIVE +33-6-07-63-80-64 (GSM) FRANCE Email: [EMAIL PROTECTED] - - Make your life a dream, make your dream a reality. (St Exupery) -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 972-414-9812 E-Mail: [EMAIL PROTECTED] US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749 ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [PORTS] [HACKERS] PostgreSQL supported platform report and a
Haha!!! It passes (b4) on 800 and not on uw 711.. Larry, should I install 800 SDK on 711? On Thu, 7 Nov 2002, Larry Rosenman wrote: Date: Thu, 07 Nov 2002 10:45:13 -0600 From: Larry Rosenman [EMAIL PROTECTED] To: [EMAIL PROTECTED] Cc: Tom Lane [EMAIL PROTECTED], Billy G. Allie [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED] Subject: Re: [PORTS] [HACKERS] PostgreSQL supported platform report and a cc -O -g -I../../../../src/include -I/usr/local/include -c -o tuplesort.o tuplesort.c UX:cc: WARNING: debugging and optimization mutually exclusive; -O disabled It still passes here. I really wonder if they fixed something in the 4.1 compiler. IIRC the 7.1.1b compiler is 4.0. Truly wierd. LER --On Thursday, November 07, 2002 17:40:24 +0100 Olivier PRENANT [EMAIL PROTECTED] wrote: What's FS, it(s the 7.1.1b compiler yes. I don't mind having CFLAGS=-Xb though, done it for php already... By everyone says this should go off so.. Regards On Thu, 7 Nov 2002, Larry Rosenman wrote: Date: Thu, 07 Nov 2002 10:37:36 -0600 From: Larry Rosenman [EMAIL PROTECTED] To: [EMAIL PROTECTED], Tom Lane [EMAIL PROTECTED] Cc: Billy G. Allie [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED] Subject: Re: [PORTS] [HACKERS] PostgreSQL supported platform report and a It **LOOKS** right. I'm about to double check it on 7.1.3. Olivier, is this the 7.1.1b FS Compiler? I wonder if a bug fix made it in... Wierd. --On Thursday, November 07, 2002 17:34:49 +0100 Olivier PRENANT [EMAIL PROTECTED] wrote: I see the latter in both b4 and b5! I've just relaunched my mirroring procedure and it did'nt pick another b4 or b5! What happens?? Regards, On Thu, 7 Nov 2002, Tom Lane wrote: Date: Thu, 07 Nov 2002 11:26:42 -0500 From: Tom Lane [EMAIL PROTECTED] To: [EMAIL PROTECTED] Cc: Larry Rosenman [EMAIL PROTECTED], Billy G. Allie [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED] Subject: Re: [PORTS] [HACKERS] PostgreSQL supported platform report and a Olivier PRENANT [EMAIL PROTECTED] writes: *WHAT??** this directory has hust been created by de-taring postgresql-7.3b5.tar.gz from my own mirror dated nov 6 20:04... Well, there's something darn weird here. Is src/backend/utils/sort/tuplesort.c version 1.28 or 1.29? At line 1838, do you see inline int32 ApplySortFunction(FmgrInfo *sortFunction, SortFunctionKind kind, or static inline int32 inlineApplySortFunction(FmgrInfo *sortFunction, SortFunctionKind kind, regards, tom lane -- Olivier PRENANT Tel:+33-5-61-50-97-00 (Work) Quartier d'Harraud Turrou +33-5-61-50-97-01 (Fax) 31190 AUTERIVE +33-6-07-63-80-64 (GSM) FRANCE Email: [EMAIL PROTECTED] -- --- - Make your life a dream, make your dream a reality. (St Exupery) -- Olivier PRENANT Tel:+33-5-61-50-97-00 (Work) Quartier d'Harraud Turrou +33-5-61-50-97-01 (Fax) 31190 AUTERIVE +33-6-07-63-80-64 (GSM) FRANCE Email: [EMAIL PROTECTED] - - Make your life a dream, make your dream a reality. (St Exupery) -- Olivier PRENANT Tel:+33-5-61-50-97-00 (Work) Quartier d'Harraud Turrou +33-5-61-50-97-01 (Fax) 31190 AUTERIVE +33-6-07-63-80-64 (GSM) FRANCE Email: [EMAIL PROTECTED] -- Make your life a dream, make your dream a reality. (St Exupery) ---(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: [PORTS] [HACKERS] PostgreSQL supported platform report and a
--On Thursday, November 07, 2002 18:02:51 +0100 Olivier PRENANT [EMAIL PROTECTED] wrote: Haha!!! It passes (b4) on 800 and not on uw 711.. Larry, should I install 800 SDK on 711? Yes. On Thu, 7 Nov 2002, Larry Rosenman wrote: Date: Thu, 07 Nov 2002 10:45:13 -0600 From: Larry Rosenman [EMAIL PROTECTED] To: [EMAIL PROTECTED] Cc: Tom Lane [EMAIL PROTECTED], Billy G. Allie [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED] Subject: Re: [PORTS] [HACKERS] PostgreSQL supported platform report and a cc -O -g -I../../../../src/include -I/usr/local/include -c -o tuplesort.o tuplesort.c UX:cc: WARNING: debugging and optimization mutually exclusive; -O disabled It still passes here. I really wonder if they fixed something in the 4.1 compiler. IIRC the 7.1.1b compiler is 4.0. Truly wierd. LER --On Thursday, November 07, 2002 17:40:24 +0100 Olivier PRENANT [EMAIL PROTECTED] wrote: What's FS, it(s the 7.1.1b compiler yes. I don't mind having CFLAGS=-Xb though, done it for php already... By everyone says this should go off so.. Regards On Thu, 7 Nov 2002, Larry Rosenman wrote: Date: Thu, 07 Nov 2002 10:37:36 -0600 From: Larry Rosenman [EMAIL PROTECTED] To: [EMAIL PROTECTED], Tom Lane [EMAIL PROTECTED] Cc: Billy G. Allie [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED] Subject: Re: [PORTS] [HACKERS] PostgreSQL supported platform report and a It **LOOKS** right. I'm about to double check it on 7.1.3. Olivier, is this the 7.1.1b FS Compiler? I wonder if a bug fix made it in... Wierd. --On Thursday, November 07, 2002 17:34:49 +0100 Olivier PRENANT [EMAIL PROTECTED] wrote: I see the latter in both b4 and b5! I've just relaunched my mirroring procedure and it did'nt pick another b4 or b5! What happens?? Regards, On Thu, 7 Nov 2002, Tom Lane wrote: Date: Thu, 07 Nov 2002 11:26:42 -0500 From: Tom Lane [EMAIL PROTECTED] To: [EMAIL PROTECTED] Cc: Larry Rosenman [EMAIL PROTECTED], Billy G. Allie [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED] Subject: Re: [PORTS] [HACKERS] PostgreSQL supported platform report and a Olivier PRENANT [EMAIL PROTECTED] writes: *WHAT??** this directory has hust been created by de-taring postgresql-7.3b5.tar.gz from my own mirror dated nov 6 20:04... Well, there's something darn weird here. Is src/backend/utils/sort/tuplesort.c version 1.28 or 1.29? At line 1838, do you see inline int32 ApplySortFunction(FmgrInfo *sortFunction, SortFunctionKind kind, or static inline int32 inlineApplySortFunction(FmgrInfo *sortFunction, SortFunctionKind kind, regards, tom lane -- Olivier PRENANT Tel: +33-5-61-50-97-00 (Work) Quartier d'Harraud Turrou +33-5-61-50-97-01 (Fax) 31190 AUTERIVE +33-6-07-63-80-64 (GSM) FRANCE Email: [EMAIL PROTECTED] --- --- --- - Make your life a dream, make your dream a reality. (St Exupery) -- Olivier PRENANT Tel: +33-5-61-50-97-00 (Work) Quartier d'Harraud Turrou +33-5-61-50-97-01 (Fax) 31190 AUTERIVE +33-6-07-63-80-64 (GSM) FRANCE Email: [EMAIL PROTECTED] -- --- - Make your life a dream, make your dream a reality. (St Exupery) -- Olivier PRENANT Tel: +33-5-61-50-97-00 (Work) Quartier d'Harraud Turrou +33-5-61-50-97-01 (Fax) 31190 AUTERIVE +33-6-07-63-80-64 (GSM) FRANCE Email: [EMAIL PROTECTED] - - Make your life a dream, make your dream a reality. (St Exupery) ---(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 -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 972-414-9812 E-Mail: [EMAIL PROTECTED] US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749 ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] protocol change in 7.4
Is exists patch for 7.4devel ? regards Haris Peco On Tuesday 05 November 2002 01:14 am, Satoshi Nagayasu wrote: Hi all, Mike Mascari [EMAIL PROTECTED] wrote: Is there any thought about changing the protocol to support two-phase commit? Not that 2PC and distributed transactions would be implemented in 7.4, but to prevent another protocol change in the future? I'm now implementing 2PC replication and distributed transaction. My 2PC needs some support in startup packet to establish a replication session and a recovery session. BTW, 2PC replication is working, and I'm implementing 2PC recovery now. ---(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] RC1 on Friday?
On Thu, 7 Nov 2002, Tom Lane wrote: Marc G. Fournier [EMAIL PROTECTED] writes: Tom, my understanding is that CONVERT stuff required an initdb, and was also the only thing 'critical' that went in ... correct? What impact does that have? For instance, could it cause one of the regression tests to fail, or is it something that is relatively benign? I would like to think it's a pretty safe change, but that's why we do betas ;-). More seriously, we are still attacking various portability issues, and there is still some undone docs work. I doubt we can make a tarball tomorrow that is an honest release candidate. Maybe Monday? 'K, let me announce beta5 tonight, and let's talk about RC1 on Monday (not plan for it, just plan to talk about it) ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] RC1 on Friday?
On Thu, 7 Nov 2002, Bruce Momjian wrote: I am loosing tolerance for these last-minute changes. We should not You might be, I'm not ... when we finally release v7.3, it will be *as solid* as our previous releases ... *shrug* ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] RC1 on Friday?
On Thu, 7 Nov 2002, Bruce Momjian wrote: Tom Lane wrote: Bruce Momjian [EMAIL PROTECTED] writes: I am loosing tolerance for these last-minute changes. We should not hold up release to support some obscure platform. As long as the docs are unfinished, I don't feel any particular compunction about not applying portability fixes. If you want RC1 tomorrow, when are you going to update the release history? That takes 5 minutes. I will do it now. I am not pushing Friday, but I am saying we need to have some urgency to get to RC1 or we will drag. I haven't noticed any 'drag' so far this release ... we had a long beta between 2 and 3, but 3-4 and 4-5 have been really short (so short that 4 didn't exist) ... ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] PL/Perl and Perl 5.8
Peter Eisentraut [EMAIL PROTECTED] writes: Tom Lane writes: I'm guessing that what we need to do is -D_GNU_SOURCE somewhere in the Makefiles; the $64 question is exactly where The simplest choice would be to just define it unconditionally in linux.h. Since it is not supposed to change any interfaces, just add new ones, this should be safe. That works for me. The main issue in my mind is not to define it on platforms that aren't glibc-based, but linux.h should be safe. Any objections out there? I see another potential problem BTW: pg_config.h has #ifndef HAVE_INET_ATON # include sys/types.h # include netinet/in.h # include arpa/inet.h extern int inet_aton(const char *cp, struct in_addr * addr); #endif which it does *before* pulling in the port-specific config file. While this won't break Linux since it has inet_aton(), I could see problems arising on platforms without. I am inclined to move all the substitute extern declarations in pg_config.h to the bottom of the file. regards, tom lane ---(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] Outstanding patches
On Thu, Nov 07, 2002 at 12:27:05AM -0500, Tom Lane wrote: CLUSTER ALL patch: I have a problem with this, specifically the fact that it changes CLUSTER into a multi-transaction operation. That was your suggestion... That renders CLUSTER non-rollbackable and not callable from functions. After all the work we went to to make CLUSTER rollbackable, this seems like a giant step backward. Well, CLUSTER ALL is now non-rollbackable. But why is it useful to rollback a CLUSTER operation? I think I can make the one-table-only version rollbackable again (and keep the ALL version multitransaction). Is that a good tradeoff? Note that the clusterdb script to appear in 7.3 is horribly broken for concurrent cases, and is much worse than the outstanding CLUSTER ALL patch. -- Alvaro Herrera (alvherre[a]dcc.uchile.cl) Saca el libro que tu religion considere como el indicado para encontrar la oracion que traiga paz a tu alma. Luego rebootea el computador y ve si funciona (Carlos Duclos) ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] Outstanding patches
Alvaro Herrera [EMAIL PROTECTED] writes: On Thu, Nov 07, 2002 at 12:27:05AM -0500, Tom Lane wrote: CLUSTER ALL patch: I have a problem with this, specifically the fact that it changes CLUSTER into a multi-transaction operation. That was your suggestion... Well, it'd be okay (IMHO anyway) if it only happened for CLUSTER ALL. You've built it in a way that the restriction applies to single-table CLUSTERs, which is an unnecessary step backwards. What I think I'd like to see is CLUSTER index ON table -- does not hack transactions CLUSTER table -- recluster a table, does not hack transactions CLUSTER -- recluster all tables, works like VACUUM This would allow people to build functions that do selective CLUSTERing, at the price of holding more exclusive locks. regards, tom lane ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [HACKERS] CREATE TABLE/AS does not allow WITH OIDS?
Thomas Lockhart [EMAIL PROTECTED] writes: ... and the same for SELECT/INTO Also, the hasoids (or equivalent) attribute is not picked up from the source table which would be another way to push this property into the target table. How would we make use of 'hasoids' in the case of multiple source tables, or a source table defined by an SRF? Unless we can define some consistent semantics for when we use the hasoids of the source table(s), I'd say we should just add the WITH/WITHOUT OIDS syntax. Cheers, Neil -- Neil Conway [EMAIL PROTECTED] || PGP Key ID: DB3C29FC ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [HACKERS] Outstanding patches
On Thu, Nov 07, 2002 at 01:44:21PM -0500, Tom Lane wrote: Alvaro Herrera [EMAIL PROTECTED] writes: On Thu, Nov 07, 2002 at 12:27:05AM -0500, Tom Lane wrote: CLUSTER ALL patch: I have a problem with this, specifically the fact that it changes CLUSTER into a multi-transaction operation. That was your suggestion... Well, it'd be okay (IMHO anyway) if it only happened for CLUSTER ALL. You've built it in a way that the restriction applies to single-table CLUSTERs, which is an unnecessary step backwards. Ok, I'll rework the patch. It never ocurred to me that it'd be an issue. -- Alvaro Herrera (alvherre[a]dcc.uchile.cl) Crear es tan dificil como ser libre (Elsa Triolet) ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] [PORTS] openbsd 3.2, postgresql 7.3beta3 and openssl 'e_os.h' include
I said: Anyway, get_last_socket_error() seems exactly equivalent to our macro SOCK_ERRNO in libpq/libpq-int.h. AFAICT, the uses of it in our code are these: /home/postgres/pgsql/src/backend/libpq/be-secure.c: errno = get_last_socket_error(); /home/postgres/pgsql/src/backend/libpq/be-secure.c: errno = get_last_socket_error(); /home/postgres/pgsql/src/interfaces/libpq/fe-secure.c: SOCK_ERRNO = get_last_socket_error(); /home/postgres/pgsql/src/interfaces/libpq/fe-secure.c: SOCK_ERRNO = get_last_socket_error(); and I think every one of these is bogus and should be removed. At best they're no-ops. If that is the only use of e_os.h stuff then we can stop including the file ... These were indeed the only uses of e_os.h symbols. I have removed them and the #includes. regards, tom lane ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] RC1 on Friday?
Marc G. Fournier wrote: On Thu, 7 Nov 2002, Bruce Momjian wrote: I am loosing tolerance for these last-minute changes. We should not You might be, I'm not ... when we finally release v7.3, it will be *as solid* as our previous releases ... *shrug* All I am saying is that I would like to generate some urgency to get people focused on resolving the open issues so we can get this done. -- 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: [HACKERS] 7.3b5 contrib compile problem
FYI: I easily updated to 1.75 and all is well. Thanks for all the help, L. On Thu, 7 Nov 2002, Tom Lane wrote: I said: It's interesting that bison 1.28's output is sufficiently different to cause a problem, but we are not going to worry about supporting use of old bisons. Well, it turned out to be reasonably easy to fix this, so I did. It seems that bison 1.28 generates a .h file that cannot be included into the .c file it generates :-(. Experimentation shows this is fixed in bison 1.35, possibly earlier; but it's easy enough to just not include the .h file. regards, tom lane -- Laurette Cisneros The Database Group (510) 420-3137 NextBus Information Systems, Inc. www.nextbus.com -- My other vehicle is my imagination. - bumper sticker ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] CREATE TABLE/AS does not allow WITH OIDS?
Thomas Lockhart [EMAIL PROTECTED] writes: What would be required to have OIDs for all SELECT/INTO product tables for this release? It *might* work to just reverse the default assumption in ExecAssignResultTypeFromTL(). But I will vote against making such a change at this late hour. Quite possibly we'd introduce bugs in features that are much more critical than whether a table created by SELECT INTO has OIDs or not. regards, tom lane ---(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] RC1 on Friday?
On Thu, Nov 07, 2002 at 13:44:11 -0400, Marc G. Fournier [EMAIL PROTECTED] wrote: I haven't noticed any 'drag' so far this release ... we had a long beta between 2 and 3, but 3-4 and 4-5 have been really short (so short that 4 didn't exist) ... I managed to be running beta 4 for a day. At least I didn't need to do an initdb to upgrade to beta 5. ---(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] Too late for translation updates?
Serguei Mokhov writes: Can I still send in translation patches so that they get into 7.4 or is it too late already? If it's not late, what would be the 'deadline' then? Send them rather soon. -- Peter Eisentraut [EMAIL PROTECTED] ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [PORTS] [HACKERS] PostgreSQL supported platform report and a
Olivier PRENANT writes: I don't mind having CFLAGS=-Xb though, done it for php already... By everyone says this should go off so.. The idea of the platform testing is not to determine whether you can compile PostgreSQL after performing a secret dance. If it doesn't compile with the default options, please don't report it as supported. -- Peter Eisentraut [EMAIL PROTECTED] ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [PORTS] [HACKERS] PostgreSQL supported platform report and a
Bruce Momjian writes: I am fine with this because it only touches unixware-specific stuff, This is an entirely new feature, so it's inappropriate to do now. And if we do it, we should do it for all platforms. -- Peter Eisentraut [EMAIL PROTECTED] ---(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: [PORTS] [HACKERS] PostgreSQL supported platform report and a
--On Thursday, November 07, 2002 22:21:56 +0100 Peter Eisentraut [EMAIL PROTECTED] wrote: Olivier PRENANT writes: I don't mind having CFLAGS=-Xb though, done it for php already... By everyone says this should go off so.. The idea of the platform testing is not to determine whether you can compile PostgreSQL after performing a secret dance. If it doesn't compile with the default options, please don't report it as supported. It DOES compile out of the box now on 8.0.0(7.1.2) and 7.1.3. Apparently a compiler fix between the 7.1.1b FS and 7.1.2. The -Xb switch is NOT a secret dance. It's needed for LOTS of open source stuff. See the discussion from the Caldera folks last week. Tom's fix fixed the defaults for 7.1.2+ -- Peter Eisentraut [EMAIL PROTECTED] -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 972-414-9812 E-Mail: [EMAIL PROTECTED] US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749 ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [PORTS] [HACKERS] PostgreSQL supported platform report and a
Larry Rosenman [EMAIL PROTECTED] writes: It DOES compile out of the box now on 8.0.0(7.1.2) and 7.1.3. Apparently a compiler fix between the 7.1.1b FS and 7.1.2. Well, this is what the REMARKS column is for in the supported-platform list. Seems we need a comment like for older compiler versions, you may need to add -Xb to CFLAGS. Can anyone provide a short and accurate description of when to do this? regards, tom lane ---(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: [PORTS] [HACKERS] PostgreSQL supported platform report and a
For compilers earlier than the one released with OpenUNIX 8.0.0(UnixWare 7.1.2), Including the 7.1.1b Feature Supplement, you may need to specify -Xb in CFLAGS or the CC environment variable. --On Thursday, November 07, 2002 16:34:12 -0500 Tom Lane [EMAIL PROTECTED] wrote: Larry Rosenman [EMAIL PROTECTED] writes: It DOES compile out of the box now on 8.0.0(7.1.2) and 7.1.3. Apparently a compiler fix between the 7.1.1b FS and 7.1.2. Well, this is what the REMARKS column is for in the supported-platform list. Seems we need a comment like for older compiler versions, you may need to add -Xb to CFLAGS. Can anyone provide a short and accurate description of when to do this? regards, tom lane -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 972-414-9812 E-Mail: [EMAIL PROTECTED] US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749 ---(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] Outstanding patches
Peter Eisentraut [EMAIL PROTECTED] writes: I concur, but do we have some sort of commitment that the rest of the SQL200x sequence machinery will be supported eventually? Otherwise, adding some irrelevant syntax variations in limited places doesn't seem fruitful. Yes, I'll implement the rest of the SQL200x sequence stuff eventually. However, if you'd rather wait for me to finish it all and then commit it at that point, that's fine with me. Cheers, Neil -- Neil Conway [EMAIL PROTECTED] || PGP Key ID: DB3C29FC ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [PORTS] [HACKERS] PostgreSQL supported platform report and a
We do point to the FAQ_SCO file for specifics. Would you send a diff for that file? --- Larry Rosenman wrote: For compilers earlier than the one released with OpenUNIX 8.0.0(UnixWare 7.1.2), Including the 7.1.1b Feature Supplement, you may need to specify -Xb in CFLAGS or the CC environment variable. --On Thursday, November 07, 2002 16:34:12 -0500 Tom Lane [EMAIL PROTECTED] wrote: Larry Rosenman [EMAIL PROTECTED] writes: It DOES compile out of the box now on 8.0.0(7.1.2) and 7.1.3. Apparently a compiler fix between the 7.1.1b FS and 7.1.2. Well, this is what the REMARKS column is for in the supported-platform list. Seems we need a comment like for older compiler versions, you may need to add -Xb to CFLAGS. Can anyone provide a short and accurate description of when to do this? regards, tom lane -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 972-414-9812 E-Mail: [EMAIL PROTECTED] US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749 ---(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 -- 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: [PORTS] [HACKERS] PostgreSQL supported platform report and a
With or withou Billie's update(s)? (I haven't looked at them) LER --On Thursday, November 07, 2002 17:08:04 -0500 Bruce Momjian [EMAIL PROTECTED] wrote: We do point to the FAQ_SCO file for specifics. Would you send a diff for that file? - -- Larry Rosenman wrote: For compilers earlier than the one released with OpenUNIX 8.0.0(UnixWare 7.1.2), Including the 7.1.1b Feature Supplement, you may need to specify -Xb in CFLAGS or the CC environment variable. --On Thursday, November 07, 2002 16:34:12 -0500 Tom Lane [EMAIL PROTECTED] wrote: Larry Rosenman [EMAIL PROTECTED] writes: It DOES compile out of the box now on 8.0.0(7.1.2) and 7.1.3. Apparently a compiler fix between the 7.1.1b FS and 7.1.2. Well, this is what the REMARKS column is for in the supported-platform list. Seems we need a comment like for older compiler versions, you may need to add -Xb to CFLAGS. Can anyone provide a short and accurate description of when to do this? regards, tom lane -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 972-414-9812 E-Mail: [EMAIL PROTECTED] US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749 ---(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 -- 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 -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 972-414-9812 E-Mail: [EMAIL PROTECTED] US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749 ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [PORTS] [HACKERS] PostgreSQL supported platform report and a
His updates deal only with the LDLIBRARY path issue, which I think we are keeping for 7.4: *** ./doc/FAQ_SCO.orig Wed Nov 6 21:35:46 2002 --- ./doc/FAQ_SCO Wed Nov 6 21:40:44 2002 *** *** 71,76 --- 71,79 configure --with-libs=/usr/local/lib --with-includes=/usr/local/include + You will also need to set LD_LIBRARY_PATH to '/usr/local/lib' (or add it to + LD_LIBRARY_PATH, if LD_LIBRARY_PATH already exists) before running config- + ure or the test for readline will fail. --- Larry Rosenman wrote: With or withou Billie's update(s)? (I haven't looked at them) LER --On Thursday, November 07, 2002 17:08:04 -0500 Bruce Momjian [EMAIL PROTECTED] wrote: We do point to the FAQ_SCO file for specifics. Would you send a diff for that file? - -- Larry Rosenman wrote: For compilers earlier than the one released with OpenUNIX 8.0.0(UnixWare 7.1.2), Including the 7.1.1b Feature Supplement, you may need to specify -Xb in CFLAGS or the CC environment variable. --On Thursday, November 07, 2002 16:34:12 -0500 Tom Lane [EMAIL PROTECTED] wrote: Larry Rosenman [EMAIL PROTECTED] writes: It DOES compile out of the box now on 8.0.0(7.1.2) and 7.1.3. Apparently a compiler fix between the 7.1.1b FS and 7.1.2. Well, this is what the REMARKS column is for in the supported-platform list. Seems we need a comment like for older compiler versions, you may need to add -Xb to CFLAGS. Can anyone provide a short and accurate description of when to do this? regards, tom lane -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 972-414-9812 E-Mail: [EMAIL PROTECTED] US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749 ---(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 -- 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 -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 972-414-9812 E-Mail: [EMAIL PROTECTED] US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749 ---(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 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [PORTS] [HACKERS] PostgreSQL supported platform report and a
OK, I'll try and do up a diff to B5's tonite (probably late, my Daughter's elementary school honors choir has a performance tonite). LER --On Thursday, November 07, 2002 17:44:37 -0500 Bruce Momjian [EMAIL PROTECTED] wrote: His updates deal only with the LDLIBRARY path issue, which I think we are keeping for 7.4: *** ./doc/FAQ_SCO.orig Wed Nov 6 21:35:46 2002 --- ./doc/FAQ_SCO Wed Nov 6 21:40:44 2002 *** *** 71,76 --- 71,79 configure --with-libs=/usr/local/lib --with-includes=/usr/local/include + You will also need to set LD_LIBRARY_PATH to '/usr/local/lib' (or add it to + LD_LIBRARY_PATH, if LD_LIBRARY_PATH already exists) before running config- + ure or the test for readline will fail. - -- Larry Rosenman wrote: With or withou Billie's update(s)? (I haven't looked at them) LER --On Thursday, November 07, 2002 17:08:04 -0500 Bruce Momjian [EMAIL PROTECTED] wrote: We do point to the FAQ_SCO file for specifics. Would you send a diff for that file? -- --- -- Larry Rosenman wrote: For compilers earlier than the one released with OpenUNIX 8.0.0(UnixWare 7.1.2), Including the 7.1.1b Feature Supplement, you may need to specify -Xb in CFLAGS or the CC environment variable. --On Thursday, November 07, 2002 16:34:12 -0500 Tom Lane [EMAIL PROTECTED] wrote: Larry Rosenman [EMAIL PROTECTED] writes: It DOES compile out of the box now on 8.0.0(7.1.2) and 7.1.3. Apparently a compiler fix between the 7.1.1b FS and 7.1.2. Well, this is what the REMARKS column is for in the supported-platform list. Seems we need a comment like for older compiler versions, you may need to add -Xb to CFLAGS. Can anyone provide a short and accurate description of when to do this? regards, tom lane -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 972-414-9812 E-Mail: [EMAIL PROTECTED] US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749 ---(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 -- 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 -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 972-414-9812 E-Mail: [EMAIL PROTECTED] US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749 ---(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 -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 972-414-9812 E-Mail: [EMAIL PROTECTED] US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749 ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [HACKERS] [GENERAL] Database replication... - Mission Critica
Mikheev, Vadim [EMAIL PROTECTED] writes: My presumption would be that if you initialize 2 databases to a known identical start, have all the same triggers and rules on both, then send all queries to both databases, you will have 2 identical databases at the end. This is wrong assumption. Agreed. Another simple example is: INSERT INTO foo VALUES (random()); Also, what about if the two servers get the 'begin' command at marginally different times, then even: INSERT INTO foo VALUES (CURRENT_TIMESTAMP); Will be different on each different machine. In fact, how is this usually handled in 2PC? You'd have to have the current time go along with the commit command when it's sent to each server... Even nastier, what about if the different postgres servers in the cluster run on different architectures! That way you'd get different floating point results on each machine... Chris ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] PostgreSQL supported platform report and a patch.
Larry Rosenman wrote: Tom Lane [EMAIL PROTECTED] wrote: Larry Rosenman [EMAIL PROTECTED] writes: I don't believe your changes are necessary. The static-inline change was obsoleted by a recent fix, per discussion. But the rpath changes seem possibly useful (or maybe my thoughts are just colored by the fact that I'm currently trying to persuade OpenSSL to build with a non-broken rpath setup on HPUX...) Do you have an objection to the rpath part of Billy's patch? Not necessarily. I was just concerned about the tuplesort one, and the fact that mine builds and passes without the changes. Larry, You probably have /usr/local/lib LD_LIBRARY_PATH. On my system LD_LIBRARY_PATH defaults to /usr/X/lib:/lib and LD_RUN_PATH are not set, and I prefer it that way. The rpath related changes allow me to specify the additional library search paths by using the configure --with-libraries option and have those paths placed into the executable so that the executables can run without having to the default setting of LD_LIBRARY_PATH. After reading the discussions, I can think of another enhancement to the rpath changes: have the contents of LD_LIBRARY_PATH added to the -R (or -rpath) option inside the port specific makefile. That way, if you add the additional search paths to LD_LIBRARY_PATH you won't have to use the --with-libraries and the executable(s) will have the runtime search paths in them so they will execute without having to change the default LD_LIBRARY_PATH setting. -- | Billy G. Allie| Domain: [EMAIL PROTECTED] | /| | 7436 Hartwell | MSN...: [EMAIL PROTECTED] |-/-|- | Dearborn, MI 48126| |/ |LLIE | (313) 582-1540| msg24907/pgp0.pgp Description: PGP signature
Re: [HACKERS] [GENERAL] Database replication... - Mission Critica
Christopher Kings-Lynne [EMAIL PROTECTED] writes: Also, what about if the two servers get the 'begin' command at marginally different times, then even: INSERT INTO foo VALUES (CURRENT_TIMESTAMP); Will be different on each different machine. Yeah -- and gettimeofday() will be inconsistent for a slightly different reason. In fact, if a function depends on anything other than its arguments, you're probably going to have problems replicating it in a sane manner if you send the query string alone. One possible solution would be to dump the idea of sending query strings, and just send tuple-level changes. The basic idea is to execute a data-modifying txn locally, determine the tuple-level changes that it makes, rollback the txn locally, and then broadcast the tuple modifications to all the nodes in the cluster. Of course, it's a bit more complex than that (read the Postgres-R paper for more details), but that's the gist of it. ... which makes me think that rather than wasting our time discussing a more-or-less solved problem, we'd be better off helping to implement Postgres-R. Even nastier, what about if the different postgres servers in the cluster run on different architectures! That way you'd get different floating point results on each machine... IMHO, that falls into the category of: Dr., it hurts when I do this! -- Well, don't do it then :-) Cheers, Neil -- Neil Conway [EMAIL PROTECTED] || PGP Key ID: DB3C29FC ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [PORTS] [HACKERS] PostgreSQL supported platform report and a
Peter Eisentraut wrote: Bruce Momjian writes: I am fine with this because it only touches unixware-specific stuff, This is an entirely new feature, so it's inappropriate to do now. And if we do it, we should do it for all platforms. I disagree that it's a new feature. The code to add the -rpath (-R) option was already there. My patch made it more useful in that the additional search libraries are now placed in the -rpath (-R) option. As to doing it on all platforms, that would be a decision for the maintainers of that platforms port. It may not be necessary for it to occur on a particular platform. The patch to Makefile.global.in provides the means by which the individual ports can add the additional search paths. It's up to the port maintainers to decide if it's needed for their port, IMHO. -- | Billy G. Allie| Domain: [EMAIL PROTECTED] | /| | 7436 Hartwell | MSN...: [EMAIL PROTECTED] |-/-|- | Dearborn, MI 48126| |/ |LLIE | (313) 582-1540| msg24909/pgp0.pgp Description: PGP signature
Re: [HACKERS] PostgreSQL supported platform report and a patch.
Billy, so your rpath changes are for handling customization you made to
your OS. Sounds like a feature addition to me, which will go into 7.4
only.
---
Billy G. Allie wrote:
-- Start of PGP signed section.
Larry Rosenman wrote:
Tom Lane [EMAIL PROTECTED] wrote:
Larry Rosenman [EMAIL PROTECTED] writes:
I don't believe your changes are necessary.
The static-inline change was obsoleted by a recent fix, per discussion.
But the rpath changes seem possibly useful (or maybe my thoughts are
just colored by the fact that I'm currently trying to persuade OpenSSL
to build with a non-broken rpath setup on HPUX...) Do you have an
objection to the rpath part of Billy's patch?
Not necessarily. I was just concerned about the tuplesort one, and the fact
that mine builds and passes without the changes.
Larry,
You probably have /usr/local/lib LD_LIBRARY_PATH. On my system
LD_LIBRARY_PATH defaults to /usr/X/lib:/lib and LD_RUN_PATH are not set, and I
prefer it that way. The rpath related changes allow me to specify the
additional library search paths by using the configure --with-libraries option
and have those paths placed into the executable so that the executables can
run without having to the default setting of LD_LIBRARY_PATH.
After reading the discussions, I can think of another enhancement to the rpath
changes: have the contents of LD_LIBRARY_PATH added to the -R (or -rpath)
option inside the port specific makefile. That way, if you add the additional
search paths to LD_LIBRARY_PATH you won't have to use the --with-libraries and
the executable(s) will have the runtime search paths in them so they will
execute without having to change the default LD_LIBRARY_PATH setting.
--
| Billy G. Allie| Domain: [EMAIL PROTECTED]
| /| | 7436 Hartwell | MSN...: [EMAIL PROTECTED]
|-/-|- | Dearborn, MI 48126|
|/ |LLIE | (313) 582-1540|
-- End of PGP section, PGP failed!
--
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 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] float output precision questions
Added to TODO: * Add GUC variables extra_float_digits and extra_double_digits to control output digits --- Tom Lane wrote: Pedro M. Ferreira [EMAIL PROTECTED] writes: Have two parameters, say DOUBLE_OUTPUT and EXTRA_DIGITS. DOUBLE_OUTPUT would select from decimal output or normalized output. EXTRA_DIGITS would add the required extra digits, from 0 (default) to 3, when output is decimal. I'm not happy with adding the hex-output option, since it's not very portable and doesn't seem necessary to solve the problem anyway. But I think an EXTRA_DIGITS setting might be interesting. In particular, suppose we allowed EXTRA_DIGITS to be negative? Setting it to -1 or -2 would go a long way towards eliminating our problems with platform variations in the geometry regression test. Perhaps something like extra_float_digitsint range -2 to 2, default 0 extra_float_digits adjusts the number of digits displayed for float4 and float8 output; the base value of 0 means we output FLT_DIG or DBL_DIG digits respectively. Per discussion, there's no reason to allow a value greater than 2, but I'm not as sure what the lower limit should be --- maybe there's some use in setting it less than -2? regards, tom lane ---(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 -- 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: [HACKERS] Concerns about statement-timeout patch
Added to TODO: * Research interaction of setitimer() and sleep() used by statement_timeout --- Tom Lane wrote: I've been trying to do some code review of the recent statement-timeout feature addition, and I've got some fairly serious concerns about it. One problem that needs discussion is that the enable_sig_alarm and disable_sig_alarm calls were dropped into postgres.c at rather randomly chosen places. The disable in particular is wrong because in the normal case it will occur after we have done transaction commit. This creates a window between committing a command and reaching the disable call wherein the timeout interrupt could happen. If it does happen, the net result will be that the client receives an error message, making it look like the command failed --- when in fact it was committed. The simplest solution would be to move the calls into start_xact_command and finish_xact_command respectively. However that would affect the semantics a little, in that for a querystring containing BEGIN and/or COMMIT commands, the timeout would be measured across subsets of the query string, not the whole string as now. I am not sure if this is a problem or not; the existing semantics don't exactly match my idea of a statement timeout anyway. Another possible objection is that end-of-transaction cleanup would not be counted in the statement timeout. This does not bother me, since the cleanup should be quick, but maybe it would bother someone. (I would place the disable after DeferredTriggerEndQuery(), so that RI triggers are run before we disable the timeout.) I am also concerned about the fact that the feature requires assuming that setitimer(ITIMER_REAL) plays nicely with sleep(). The documents I have say that on some platforms sleep() destroys any pending ITIMER_REAL setting. We could perhaps fix that by adding a call to reset the end-of-statement timeout after every sleep() in the backend ... but that's obviously a fragile way to proceed. Comments? regards, tom lane ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html -- 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: [HACKERS] Win32 port
Hello Katie, Thursday, November 7, 2002, 7:08:20 PM, you wrote: KW Hi, all. KW I just wanted to give you an update on where my company (PeerDirect) is with KW regards to our native Windows port. KW We are planning on contributing the code for the native port sometime next KW month (in December). We would have liked to contribute it earlier, but our KW work schedules here didn't allow it. KW The state of the port is that it passes all postgres regression tests. It's KW been in BETA since early August with about 27 beta customers. The beta KW customers came from a post made to the cygwin mailing list KW (http://archives.postgresql.org/pgsql-cygwin/2002-08/msg00012.php). The KW BETA has proven successful and several problems were found and fixed. KW At this point you are welcome to run the latest version of this BETA. There KW is no installer, but there is a setenv.bat script to help setup the KW environment. The beta can be downloaded at: KW ftp://209.61.187.152/postgres/postgres_beta4.zip KW This version has its own catalog version which is slightly different than KW 7.2.1, so you'll need to do a pg_dump and pg_restore. If you find any KW issues, please don't mail me directly. Instead, please send emails to KW [EMAIL PROTECTED] Several people monitor this address and the KW issue will get resolved more quickly. KW There is still some cleanup work to do, such as migrating from 7.2.1 to 7.4, KW but my company is committed to contributing this port to the community by KW the end of the year. I have tried this version and it seems to work well on preliminary tests. Bruce, this probably is a good start for the port and I wonder if it worths having all that patching trouble you mentioned, specially when they offered to do it... I think you probably have a lot of work to do on other areas too... To Katie: does it compile with Mingw too ? - Best regards, Steve Howe mailto:howe;carcass.dhs.org ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] Float output formatting options
I am confused about this patch. I don't see extra_float_digits defined
anywhere. Am I missing a patch?
---
Pedro M. Ferreira wrote:
Pedro M. Ferreira wrote:
Tom Lane wrote:
Perhaps P_MAXLEN now needs to be (2*(DBL_DIG+2+7)+1), considering
that we'll allow extra_float_digits to be up to 2. What's it used for?
Yes. I guess so, because it is used in what I think is a memory
allocation function. P_MAXLEN is only used twice:
...
I will do the changes tomorrow and send in the appropriate diff's.
Ok. Its done now.
Only one file changed: src/backend/utils/adt/geo_ops.c
All the geometric types should now account for float_extra_digits on output.
A diff -u is attached.
Best reagards,
Pedro
Regards,
Pedro
---(end of broadcast)---
TIP 2: you can get off all lists at once with the unregister command
(send unregister YourEmailAddressHere to [EMAIL PROTECTED])
--
--
Pedro Miguel Frazao Fernandes Ferreira
Universidade do Algarve
Faculdade de Ciencias e Tecnologia
Campus de Gambelas
8000-117 Faro
Portugal
Tel./Fax: (+351) 289 800950 / 289 819403
http://w3.ualg.pt/~pfrazao
--- old/postgresql-7.2.1/src/backend/utils/adt/geo_ops.c Mon Nov 4 12:01:39
2002
+++ postgresql-7.2.1/src/backend/utils/adt/geo_ops.c Tue Nov 5 10:47:56 2002
@@ -80,11 +80,11 @@
#define RDELIM_C ''
/* Maximum number of output digits printed */
-#define P_MAXDIG DBL_DIG
-#define P_MAXLEN (2*(P_MAXDIG+7)+1)
-
-static int digits8 = P_MAXDIG;
+/* ...+2+7 : 2 accounts for extra_float_digits max value */
+#define P_MAXLEN (2*(DBL_DIG+2+7)+1)
+/* Extra digits in float output formatting (in float.c) */
+extern int extra_float_digits;
/*
* Geometric data types are composed of points.
@@ -139,7 +139,12 @@
static int
single_encode(float8 x, char *str)
{
- sprintf(str, %.*g, digits8, x);
+ int ndig = DBL_DIG + extra_float_digits;
+
+ if (ndig 1)
+ ndig=1;
+
+ sprintf(str, %.*g, ndig, x);
return TRUE;
}/* single_encode() */
@@ -190,7 +195,12 @@
static int
pair_encode(float8 x, float8 y, char *str)
{
- sprintf(str, %.*g,%.*g, digits8, x, digits8, y);
+ int ndig = DBL_DIG + extra_float_digits;
+
+ if (ndig 1)
+ ndig=1;
+
+ sprintf(str, %.*g,%.*g, ndig, x, ndig, y);
return TRUE;
}
@@ -974,7 +984,7 @@
#endif
#ifdef GEODEBUG
printf(line_construct_pts- line is neither vertical nor horizontal
(diffs x=%.*g, y=%.*g\n,
-digits8, (pt2-x - pt1-x), digits8, (pt2-y - pt1-y));
+DBL_DIG, (pt2-x - pt1-x), DBL_DIG, (pt2-y - pt1-y));
#endif
}
}
@@ -1180,8 +1190,8 @@
#ifdef GEODEBUG
printf(line_interpt- lines are A=%.*g, B=%.*g, C=%.*g, A=%.*g, B=%.*g,
C=%.*g\n,
-digits8, l1-A, digits8, l1-B, digits8, l1-C, digits8, l2-A,
digits8, l2-B, digits8, l2-C);
- printf(line_interpt- lines intersect at (%.*g,%.*g)\n, digits8, x, digits8,
y);
+DBL_DIG, l1-A, DBL_DIG, l1-B, DBL_DIG, l1-C, DBL_DIG, l2-A,
DBL_DIG, l2-B, DBL_DIG, l2-C);
+ printf(line_interpt- lines intersect at (%.*g,%.*g)\n, DBL_DIG, x, DBL_DIG,
y);
#endif
return result;
@@ -2390,14 +2400,14 @@
p = line_interpt_internal(tmp, line);
#ifdef GEODEBUG
printf(interpt_sl- segment is (%.*g %.*g) (%.*g %.*g)\n,
-digits8, lseg-p[0].x, digits8, lseg-p[0].y, digits8,
lseg-p[1].x, digits8, lseg-p[1].y);
+DBL_DIG, lseg-p[0].x, DBL_DIG, lseg-p[0].y, DBL_DIG,
lseg-p[1].x, DBL_DIG, lseg-p[1].y);
printf(interpt_sl- segment becomes line A=%.*g B=%.*g C=%.*g\n,
-digits8, tmp.A, digits8, tmp.B, digits8, tmp.C);
+DBL_DIG, tmp.A, DBL_DIG, tmp.B, DBL_DIG, tmp.C);
#endif
if (PointerIsValid(p))
{
#ifdef GEODEBUG
- printf(interpt_sl- intersection point is (%.*g %.*g)\n, digits8,
p-x, digits8, p-y);
+ printf(interpt_sl- intersection point is (%.*g %.*g)\n, DBL_DIG,
p-x, DBL_DIG, p-y);
#endif
if (on_ps_internal(p, lseg))
{
---(end of broadcast)---
TIP 6: Have you searched our list archives?
http://archives.postgresql.org
--
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
Re: [HACKERS] PostgreSQL supported platform report and a patch.
This has been saved for the 7.4 release:
http:/momjian.postgresql.org/cgi-bin/pgpatches2
I will not apply the _inline_ part.
---
Billy G. Allie wrote:
-- Start of PGP signed section.
I am including a set of 4 small patches that enable PostgreSQL 7.3b3 to build
successfully on OpenUnix 8.0. These same patches should also work for UnixWare
7.x. I will confirm that tomorrow (Nov 7, 2002).
Here is an explanation of the patches:
1. An update of the FAQ_SCO file.
2. This patch removes a static declaration of a in-line function in
src/backend/utils/sort/tuplesort.c
3. This patch to src/makefiles/Makefile.unixware, together with the patch to
src/Makefile.global.in allows any addition library search directories (added
with the configure --with-libraries option) to be added to the rpath option
sent to the linker. The use of a different variable to pass the addition
search paths was necessary to avoid a circular reference to LDFLAGS.
4. This patch creates the variable (trpath) used by the patch to
Makefile.unixware. This patch would also be for other platforms that would
have to add the additional library search paths to the rpath linker option.
See Makefile.unixware for an example of how to do this.
After applying these patches, PostgreSQL successfully compiled on OpenUnix 8
and it passed all the regression tests.
Content-Description: ou8.patch.20021106
[ Attachment, skipping... ]
| Billy G. Allie| Domain: [EMAIL PROTECTED]
| /| | 7436 Hartwell | MSN...: [EMAIL PROTECTED]
|-/-|- | Dearborn, MI 48126|
|/ |LLIE | (313) 582-1540|
-- End of PGP section, PGP failed!
--
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 5: Have you checked our extensive FAQ?
http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] Float output formatting options
Bruce Momjian [EMAIL PROTECTED] writes: I am confused about this patch. I don't see extra_float_digits defined anywhere. Am I missing a patch? Evidently. I have the patch and was planning to apply it myself as soon as Pedro does something with the geometry types... regards, tom lane ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
[HACKERS] Problem: Referential Integrity Constraints lost
Hi i think a hit a major problem on 7.2.1. I run 3 systems with postgresql 7.2.1. Its a redhat 7.1 for development, a redhat 7.3 for production and a FreeBSD 4.6.1RC2 for testing. After long runs (with periodic (daily) vacuum analyze's) i noticed that some of the triggers that implement referential integrity constraints just disapeared. Some of these triggers were still present on the FreeBSD system (which has been idle for a month or so), whereas on the linux systems they were absent. Has any one have a clue?? Any comment would be really valuable at this moment of darkness. Thanx. == Achilleus Mantzios S/W Engineer IT dept Dynacom Tankers Mngmt Nikis 4, Glyfada Athens 16610 Greece tel:+30-10-8981112 fax:+30-10-8981877 email: [EMAIL PROTECTED] [EMAIL PROTECTED] ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [HACKERS] [SQL] Problem: Referential Integrity Constraints lost: Correction
I was wrong about parent side triggers only having disappeared. Triggers of both sides are missing. == Achilleus Mantzios S/W Engineer IT dept Dynacom Tankers Mngmt Nikis 4, Glyfada Athens 16610 Greece tel:+30-10-8981112 fax:+30-10-8981877 email: [EMAIL PROTECTED] [EMAIL PROTECTED] ---(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] [SQL] Problem: Referential Integrity Constraints lost
Also i must that these lost triggers implement the parent table
side of the constraint, e.g.
CREATE TABLE VslSections(
id serial NOT NULL UNIQUE PRIMARY KEY,
name varchar(20) NOT NULL UNIQUE);
CREATE TABLE MachClasses(
id serial NOT NULL UNIQUE PRIMARY KEY,
name varchar(20) NOT NULL UNIQUE,
vslsecid int4 NOT NULL,
FOREIGN KEY (vslsecid) REFERENCES VslSections (id));
Then the triggers created are :
1)
CREATE CONSTRAINT TRIGGER unnamed AFTER INSERT OR UPDATE ON
machclasses FROM vslsections NOT DEFERRABLE INITIALLY IMMEDIATE FOR
EACH ROW EXECUTE PROCEDURE RI_FKey_check_ins ('unnamed',
'machclasses', 'vslsections', 'UNSPECIFIED', 'vslsecid', 'id');
2)
CREATE CONSTRAINT TRIGGER unnamed AFTER DELETE ON vslsections FROM
machclasses NOT DEFERRABLE INITIALLY IMMEDIATE FOR EACH ROW EXECUTE
PROCEDURE RI_FKey_noaction_del ('unnamed', 'machclasses',
'vslsections', 'UNSPECIFIED', 'vslsecid', 'id');
3)
CREATE CONSTRAINT TRIGGER unnamed AFTER UPDATE ON vslsections FROM
machclasses NOT DEFERRABLE INITIALLY IMMEDIATE FOR EACH ROW EXECUTE
PROCEDURE RI_FKey_noaction_upd ('unnamed', 'machclasses',
'vslsections', 'UNSPECIFIED', 'vslsecid', 'id');
The *LOST* triggers are 2 and 3.
==
Achilleus Mantzios
S/W Engineer
IT dept
Dynacom Tankers Mngmt
Nikis 4, Glyfada
Athens 16610
Greece
tel:+30-10-8981112
fax:+30-10-8981877
email: [EMAIL PROTECTED]
[EMAIL PROTECTED]
---(end of broadcast)---
TIP 6: Have you searched our list archives?
http://archives.postgresql.org
