[HACKERS] Stability problems
Hi, I have strange stability problems. I can't access a table (the table is different each time I get the problem, it could be a system table (pg_am), or a user defined one): Can't select * the whole table but can select * limit x offset y, so it appears that only a tuple is in bad status. I can't vacuum or pg_dump this table too. The error disappears after waiting some time. I get the following error in log when select the 'bad' line: 2002-11-05 11:26:42 [3062] DEBUG: server process (pid 4551) was terminated by signal 11 2002-11-05 11:26:42 [3062] DEBUG: terminating any other active server processes 2002-11-05 11:26:42 [4555] FATAL 1: The database system is in recovery mode 2002-11-05 11:26:42 [3062] DEBUG: all server processes terminated; reinitializing shared memory and semaphores 2002-11-05 11:26:42 [4557] DEBUG: database system was interrupted at 2002-11-05 11:23:00 CET I get the following error in log when vacuuming the 'bad' table: 2002-11-05 14:46:44 [5768] FATAL 2: failed to add item with len = 191 to page 150 (free space 4294967096, nusd 0, noff 0) 2002-11-05 14:46:44 [5569] DEBUG: server process (pid 5768) exited with exit code 2 2002-11-05 14:46:44 [5569] DEBUG: terminating any other active server processes 2002-11-05 14:46:44 [5771] NOTICE: Message from PostgreSQL backend: The Postmaster has informed me that some other backend died abnormally and possibly corrupted shared memory. I have rolled back the current transaction and am going to terminate your database system connection and exit. Please reconnect to the database system and repeat your query. 2002-11-05 14:46:44 [5772] NOTICE: Message from PostgreSQL backend: The Postmaster has informed me that some other backend died abnormally and possibly corrupted shared memory. I have rolled back the current transaction and am going to terminate your database system connection and exit. Please reconnect to the database system and repeat your query. 2002-11-05 14:46:44 [5569] DEBUG: all server processes terminated; reinitializing shared memory and semaphores 2002-11-05 14:46:44 [5774] DEBUG: database system was interrupted at 2002-11-05 14:46:40 CET template1=# select version(); PostgreSQL 7.2.1 on i686-pc-linux-gnu, compiled by GCC 2.96 Is it a lock problem? Is there a way to log it? Thanks for all making such a good job. Nicolas VERGER ---(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] Stability problems
Nicolas VERGER [EMAIL PROTECTED] writes:
2002-11-05 14:46:44 [5768] FATAL 2: failed to add item with len = 191
to page 150 (free space 4294967096, nusd 0, noff 0)
template1=# select version();
PostgreSQL 7.2.1 on i686-pc-linux-gnu, compiled by GCC 2.96
Hmm. This looks a lot like the bug I recently noted in vacuum's
free-space calculations --- but that bug only affects machines where
MAXALIGN 4, which I would not expect for an Intel machine. Anyway
you might try this patch:
*** pgsql-server/src/backend/commands/vacuum.c 2002/10/21 22:06:19 1.243
--- pgsql-server/src/backend/commands/vacuum.c 2002/10/31 19:25:29 1.244
***
*** 1753,1759
}
to_vacpage-free -= MAXALIGN(tlen);
if (to_vacpage-offsets_used =
to_vacpage-offsets_free)
! to_vacpage-free -=
MAXALIGN(sizeof(ItemIdData));
(to_vacpage-offsets_used)++;
if (free_vtmove == 0)
{
--- 1753,1759
}
to_vacpage-free -= MAXALIGN(tlen);
if (to_vacpage-offsets_used =
to_vacpage-offsets_free)
! to_vacpage-free -= sizeof(ItemIdData);
(to_vacpage-offsets_used)++;
if (free_vtmove == 0)
{
(Line numbers are for recent CVS tip and are off a little for 7.2, but
there's only one occurrence of MAXALIGN(sizeof(... in vacuum.c; you
can't miss it.)
While you are at it, be sure to update to 7.2.3. There are some
*critical* bug fixes in 7.2.3.
regards, tom lane
---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] a tiny question
Another tiny question: Is there a way to set more than one shared regions? Thanks and regards ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] a tiny question
Luis Alberto Amigo Navarro [EMAIL PROTECTED] writes: Is there a way to set more than one shared regions? No, there isn't. Cheers, Neil -- Neil Conway [EMAIL PROTECTED] || PGP Key ID: DB3C29FC ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] a tiny question
I supposed it, but I've not seen 7.3. A small patch for low performance on NUMA arquitectures could be the chance of using more than one shared region. Several months away there was a brief talk about low performance on IRIX, it was not real, it's low performance on Origin servers, they use ccNUMA architecture, so using a single shared segment allocated by only one proccess doesn't give IRIX planner a chance for attempting to optimize memory accesses, even thought page migration is almost impossible with DB memory accesses. With this scenario, IRIX uses a first-touch algorith for memory placement (all the memory is allocated on the node Postgres starts running). Due to high latency between local and remote memory accesses, if there is data modification, remote proccesors cache hit rate goes down, all of this makes that all the basis of high scalability on this systems(big cache, memory distribution, increasing bandwith and page migration) ar thrown to the earth. I suppose that making more than one shared segment it's not too difficult, but with this u can do that a long time Postgres running on a NUMA system achieve a good performance scenario. Is it so difficult? Thanks and regards. Luis Amigo ---(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] v7.3Beta4 Tag'd and Packaged ...
[EMAIL PROTECTED] (Marc G. Fournier) writes: On Tue, 5 Nov 2002, Thomas Lockhart wrote: ... to pull in those changes that were made to the REL7_3_STABLE branch ... Right. But, if I did: cvs checkout -rREL7_3_STABLE pgsql What would I use as BRANCHNAME in the -j to 'pull in' the changes we made to HEAD? Or is there where I'm misunderstanding something? Use HEAD for the tag from within the REL7_3_STABLE branch: cvs update -jHEAD pgsql The files will then show that they are modified, and you can then commit the changes to your branch. *groan* I figured I was restricted to that which shows as BRANCH/TAGs in a cvs log :( Noted for next release cycle ... thanks Some CVS commands have HEAD meaning head of the branch I'm currently on and not the 'real' head, so watch out for confusing results when using HEAD on a branch. (I'm quite sure this applies to 'cvs diff' but I don't remember if it affects 'cvs update -j' also.) This was explicitly added to CVS as a 'feature' a few years ago. (Why is beyond me since I find it incredibly stupid :-) _ Mats Lofkvist [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])
[HACKERS] Final Beta ... Hopefully?
Peter updated the man.tar.gz file for me, and I got Bruce to tag it as beta5 just so that there was no confusion ... Sizes all look right, in comparison to past betas ... can a few ppl download and take a peak at this one ... if all goes well, this should be the last beta, with RC1 out next week *cross fingers* ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] protocol change in 7.4
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. :-) I think the client should not act as the transaction master. But if it is needed, the client can talk to postgres servers with the extended 2PC FE/BE protocol. Because all postgres servers(master and slave) can understand both the normal FE/BE protocol and the extended 2PC FE/BE protocol. It is switched in the startup packet. Why is the protocol change neccessary ? 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. How the backend detect them in the multi-master replication? Detecting inside the start packet is a simple way. My implementation is working without protocol modification, because the session type information is embeded in the 'unused' field now. So the backend can understand both the normal FE/BE protocol and the extended 2PC FE/BE protocol. But if the unused field is removed in 7.4, my replication will not work. 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 it will confuse the application programmer. -- NAGAYASU Satoshi [EMAIL PROTECTED] ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
[HACKERS] Romanian version of the PostgreSQL Advocacy and Marketing site is ready
Hi everyone, Thanks to Adrian Maier [EMAIL PROTECTED], the Romanian translation of the PostgreSQL Advocacy and Marketing site is now completed and ready for public use: http://advocacy.postgresql.org/?lang=ro :-) Dutch is presently being worked upon, and will hopefully be ready soon. :) That'll make an even 10 languages! Regards and best wishes, Justin Clift -- My grandfather once told me that there are two kinds of people: those who work and those who take the credit. He told me to try to be in the first group; there was less competition there. - Indira Gandhi ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] Win32 port
Hannu Krosing wrote: Bruce Momjian kirjutas K, 06.11.2002 kell 08:19: I have copies of Peer Direct's (Jan's company) port of PostgreSQL to Win32, and SRA's port to Win32, and permission to generate a merged patch that can be applied to 7.4. Great! Now that 7.3 is almost complete, I am going to start work on that. I will post patches that deal with specific portability issues, like fork/exec and path separator handling, and once reviewed, apply them to the main CVS tree for 7.4. What C compiler will you be working with ? I hope that at least MingW should be supported ? Actually, I will be doing all the coding on BSD/OS. I am more merging patches than actual coding, though. This will guarantee that the patches will not affect the Unix platforms. I will need help from others to check the various Win32 compilers. -- 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] Win32 port
Bruce Momjian wrote: Hannu Krosing wrote: Bruce Momjian kirjutas K, 06.11.2002 kell 08:19: I have copies of Peer Direct's (Jan's company) port of PostgreSQL to Win32, and SRA's port to Win32, and permission to generate a merged patch that can be applied to 7.4. Great! Now that 7.3 is almost complete, I am going to start work on that. I will post patches that deal with specific portability issues, like fork/exec and path separator handling, and once reviewed, apply them to the main CVS tree for 7.4. What C compiler will you be working with ? I hope that at least MingW should be supported ? Actually, I will be doing all the coding on BSD/OS. I am more merging patches than actual coding, though. This will guarantee that the patches will not affect the Unix platforms. I will need help from others to check the various Win32 compilers. I was wondering about that. How will you be able to verify that you got a Win32 port that at least compiles, if you're merging two different Win32 approaches into the code on BSD? I don't expect that to work at all. To Hannu: the Windows port we did here depends on MS VC++ features like the ability to specify in the project to substitute header files. I don't know much about MingW and if you can do things like that with it. Our port is a real 100% pure Win32 one without any portability crap like cygwin. I don't think that's a big problem, since the binary results of a MS VC compile are redistributable AFAIK. And you'd need VC++ only if you want to do backend development under Windows, and who want's that (Katie for sure, but that's another story ;-P ) Jan -- #==# # It's easier to get forgiveness for being wrong than for being right. # # Let's break this rule - forgive me. # #== [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] Win32 port
Jan Wieck wrote: Actually, I will be doing all the coding on BSD/OS. I am more merging patches than actual coding, though. This will guarantee that the patches will not affect the Unix platforms. I will need help from others to check the various Win32 compilers. I was wondering about that. How will you be able to verify that you got a Win32 port that at least compiles, if you're merging two different Win32 approaches into the code on BSD? I don't expect that to work at all. It doesn't have to work on Win32 day 1. I will do all the work I can. I will also be buying a machine that can compile this but right now I want to get most of it in. -- 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] Win32 port
Bruce Momjian wrote: Jan Wieck wrote: Actually, I will be doing all the coding on BSD/OS. I am more merging patches than actual coding, though. This will guarantee that the patches will not affect the Unix platforms. I will need help from others to check the various Win32 compilers. I was wondering about that. How will you be able to verify that you got a Win32 port that at least compiles, if you're merging two different Win32 approaches into the code on BSD? I don't expect that to work at all. It doesn't have to work on Win32 day 1. I will do all the work I can. I will also be buying a machine that can compile this but right now I want to get most of it in. Bruce, I can compile on VC++ (VS .Net) for you. Let me know when you're ready with a patch. Joe ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Win32 port
Joe Conway wrote: Bruce Momjian wrote: Jan Wieck wrote: Actually, I will be doing all the coding on BSD/OS. I am more merging patches than actual coding, though. This will guarantee that the patches will not affect the Unix platforms. I will need help from others to check the various Win32 compilers. I was wondering about that. How will you be able to verify that you got a Win32 port that at least compiles, if you're merging two different Win32 approaches into the code on BSD? I don't expect that to work at all. It doesn't have to work on Win32 day 1. I will do all the work I can. I will also be buying a machine that can compile this but right now I want to get most of it in. Bruce, I can compile on VC++ (VS .Net) for you. Let me know when you're ready with a patch. Thanks. That will be a help. In fact, just running it through after I make few commits should fix things up. -- 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] Win32 port
Jan Wieck writes: To Hannu: the Windows port we did here depends on MS VC++ features like the ability to specify in the project to substitute header files. I don't know much about MingW and if you can do things like that with it. Before long someone will port the Windows port to MinGW, so we should resist attempts to use compiler-specific features in the same way that we tend not to use vendors specific features in other ports. -- 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: [HACKERS] Win32 port
Peter Eisentraut wrote: Jan Wieck writes: To Hannu: the Windows port we did here depends on MS VC++ features like the ability to specify in the project to substitute header files. I don't know much about MingW and if you can do things like that with it. Before long someone will port the Windows port to MinGW, so we should resist attempts to use compiler-specific features in the same way that we tend not to use vendors specific features in other ports. Absolutely. With the present push by over 30 governments of countries, and other large institutions around the world for adopting Open Source software in significant ways, we'd be kind of short-sighted to do things in a way that mostly limits people to using M$ products. :-) Regards and best wishes, Justin Clift -- 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 -- My grandfather once told me that there are two kinds of people: those who work and those who take the credit. He told me to try to be in the first group; there was less competition there. - Indira Gandhi ---(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] Win32 port
-Original Message- From: Joe Conway [mailto:mail;joeconway.com] Sent: 06 November 2002 16:16 To: Bruce Momjian Cc: Jan Wieck; Hannu Krosing; PostgreSQL-development; Tatsuo Ishii Subject: Re: [HACKERS] Win32 port Bruce, I can compile on VC++ (VS .Net) for you. Let me know when you're ready with a patch. Joe I can also help with VC++ 6, and .NET. Regards, Dave. ---(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] Win32 port
Here is a list of patch areas that I will address with the Win32 port: fork/exec loop rename test handle \r in COPY copydir for cp -r backslash tests rmdir not recursive for rm -r shared memory could map to new address in exec child compatibility defines file path separators root directory rename atomicity spinlock changes str[r]chr timeval for psql DWORD in help.c initdb -- 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] Win32 port
Bruce Momjian wrote: Peter Eisentraut wrote: Jan Wieck writes: To Hannu: the Windows port we did here depends on MS VC++ features like the ability to specify in the project to substitute header files. I don't know much about MingW and if you can do things like that with it. Before long someone will port the Windows port to MinGW, so we should resist attempts to use compiler-specific features in the same way that we tend not to use vendors specific features in other ports. Agreed. I will make as clean a patch as possible. I think it is doable. The thing with this particular feature was not to touch almost every source file in the whole tree. The headers to #include in a clean Win32 world are totally different from what you #include in Unix. Jan -- #==# # It's easier to get forgiveness for being wrong than for being right. # # Let's break this rule - forgive me. # #== [EMAIL PROTECTED] # ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Win32 port
Bruce Momjian wrote: Here is a list of patch areas that I will address with the Win32 port: fork/exec loop rename test handle \r in COPY copydir for cp -r backslash tests rmdir not recursive for rm -r shared memory could map to new address in exec child That's actually not done in the port yet. Thomas once overhauled the hashtable code and changed it from using offsets to pointers. This code is used for shared hashtables, so the mapping has to be done at a fixed address for now. Jan -- #==# # It's easier to get forgiveness for being wrong than for being right. # # Let's break this rule - forgive me. # #== [EMAIL PROTECTED] # ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] Win32 port
Jan Wieck wrote: Bruce Momjian wrote: Here is a list of patch areas that I will address with the Win32 port: fork/exec loop rename test handle \r in COPY copydir for cp -r backslash tests rmdir not recursive for rm -r shared memory could map to new address in exec child That's actually not done in the port yet. Thomas once overhauled the hashtable code and changed it from using offsets to pointers. This code is used for shared hashtables, so the mapping has to be done at a fixed address for now. OK, can we guarantee that fixed mapping will happen? -- 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] Win32 port
Jan Wieck wrote: Bruce Momjian wrote: Peter Eisentraut wrote: Jan Wieck writes: To Hannu: the Windows port we did here depends on MS VC++ features like the ability to specify in the project to substitute header files. I don't know much about MingW and if you can do things like that with it. Before long someone will port the Windows port to MinGW, so we should resist attempts to use compiler-specific features in the same way that we tend not to use vendors specific features in other ports. Agreed. I will make as clean a patch as possible. I think it is doable. The thing with this particular feature was not to touch almost every source file in the whole tree. The headers to #include in a clean Win32 world are totally different from what you #include in Unix. OK, I am looking at the SRA patch and I don't see a huge number of #include changes. Can you give an example? Also, isn't there a way to do this in a more centralized way, perhaps in c.h? -- 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] Stability problems
I would recommend checking your memory (look for memtest86 online somewhere. Good tool.) Anytime a machine seems to act flakely there's a better than even chance it has a bad bit of memory in it. On Wed, 6 Nov 2002, Nicolas VERGER wrote: Hi, I have strange stability problems. I can't access a table (the table is different each time I get the problem, it could be a system table (pg_am), or a user defined one): Can't select * the whole table but can select * limit x offset y, so it appears that only a tuple is in bad status. I can't vacuum or pg_dump this table too. The error disappears after waiting some time. I get the following error in log when select the 'bad' line: 2002-11-05 11:26:42 [3062] DEBUG: server process (pid 4551) was terminated by signal 11 2002-11-05 11:26:42 [3062] DEBUG: terminating any other active server processes 2002-11-05 11:26:42 [4555] FATAL 1: The database system is in recovery mode 2002-11-05 11:26:42 [3062] DEBUG: all server processes terminated; reinitializing shared memory and semaphores 2002-11-05 11:26:42 [4557] DEBUG: database system was interrupted at 2002-11-05 11:23:00 CET I get the following error in log when vacuuming the 'bad' table: 2002-11-05 14:46:44 [5768] FATAL 2: failed to add item with len = 191 to page 150 (free space 4294967096, nusd 0, noff 0) 2002-11-05 14:46:44 [5569] DEBUG: server process (pid 5768) exited with exit code 2 2002-11-05 14:46:44 [5569] DEBUG: terminating any other active server processes 2002-11-05 14:46:44 [5771] NOTICE: Message from PostgreSQL backend: The Postmaster has informed me that some other backend died abnormally and possibly corrupted shared memory. I have rolled back the current transaction and am going to terminate your database system connection and exit. Please reconnect to the database system and repeat your query. 2002-11-05 14:46:44 [5772] NOTICE: Message from PostgreSQL backend: The Postmaster has informed me that some other backend died abnormally and possibly corrupted shared memory. I have rolled back the current transaction and am going to terminate your database system connection and exit. Please reconnect to the database system and repeat your query. 2002-11-05 14:46:44 [5569] DEBUG: all server processes terminated; reinitializing shared memory and semaphores 2002-11-05 14:46:44 [5774] DEBUG: database system was interrupted at 2002-11-05 14:46:40 CET template1=# select version(); PostgreSQL 7.2.1 on i686-pc-linux-gnu, compiled by GCC 2.96 Is it a lock problem? Is there a way to log it? Thanks for all making such a good job. Nicolas VERGER ---(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 ---(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] problem building pg 7.3 beta 3 on solaris 8 -m64
make[2]: Entering directory `/data/aja96/postgresql-7.3b3/src/backend/utils/mb/conversion_procs' make[3]: Entering directory `/data/aja96/postgresql-7.3b3/src/backend/utils/mb/conversion_procs/ ascii_and_mic' gcc -shared -h libascii_and_mic.so.0 ascii_and_mic.o -L../../../../../../src/port -o libascii_and_mic.so.0.0 ld: fatal: library -lgcc_s: not found ld: fatal: library -lgcc_s: not found ld: fatal: File processing errors. No output written to libascii_and_mic.so.0.0 collect2: ld returned 1 exit status make[3]: *** [libascii_and_mic.so.0.0] Error 1 make[3]: Leaving directory `/data/aja96/postgresql-7.3b3/src/backend/utils/mb/conversion_procs/ ascii_and_mic' make[2]: *** [all] Error 2 make[2]: Leaving directory `/data/aja96/postgresql-7.3b3/src/backend/utils/mb/conversion_procs' make[1]: *** [all] Error 2 make[1]: Leaving directory `/data/aja96/postgresql-7.3b3/src' make: *** [all] Error 2 Darcy explained that it might be a problem with gcc 3.1, and that i should upgrade to 3.2. The compile line from the makefile is actually: gcc -shared -h libascii_and_mic.so.0 ascii_and_mic.o -L../../../../../../src/port -o libascii_and_mic.so.0.0 While attempting to compile gcc 3.2, I found a bug in the build process (which i have corrected, bug report to gcc folks on its way). I'll report back after that. I think however, this is a gcc bug (that will because of the bug I just found) be present in 3.2. The problem is that when gcc is built, the directory $build_dir/gcc/sparcv9 does not include the following two symlinks: lrwxrwxrwx 1 aja96atd 13 Nov 6 16:23 libgcc_s.so - libgcc_s.so.1 lrwxrwxrwx 1 aja96atd 13 Nov 6 16:25 libgcc_s_sparcv9.so - libgcc_s.so.1 (note: -rwxr-xr-x 1 aja96atd 512136 Nov 6 14:12 libgcc_s.so.1) creating those symlinks (and adding the dir to LD_LIBRARY_PATH, but in retrospect i think it was unnecessary) allows it to continue compiling (gcc). I havent figured out where those are fubar on the system yet, I'm sure somebody here does; I'm going to get gcc 3.2 built and see if this fix fixes the pg compile. Some sort of logic understanding this buggery should probably incorporated into the release. i've included my home address on CC, please maintain that CC. my contract here is up in a couple weeks, and i will have limited access to the address currently subscribed to hackers. thanks 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] PL/Perl and Perl 5.8
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 (can we restrict it to src/pl/plperl?) and what conditions should cause the Makefiles to add it? Do we want a configure test? 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. If you don't believe that, then we really need to test and define _GNU_SOURCE early in configure so the following tests can take it into account. In either case, the command line is not the place for it. -- Peter Eisentraut [EMAIL PROTECTED] ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Win32 port
Hello Bruce, Wednesday, November 6, 2002, 3:19:35 AM, you wrote: BM I have copies of Peer Direct's (Jan's company) port of PostgreSQL to BM Win32, and SRA's port to Win32, and permission to generate a merged BM patch that can be applied to 7.4. BM Now that 7.3 is almost complete, I am going to start work on that. I BM will post patches that deal with specific portability issues, like BM fork/exec and path separator handling, and once reviewed, apply them to BM the main CVS tree for 7.4. Just wondering, what compiler are they using ? Will it compile using Mingw ? - Best regards, Steve Howe mailto:howe;carcass.dhs.org ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Win32 port
Steve Howe wrote: Hello Bruce, Wednesday, November 6, 2002, 3:19:35 AM, you wrote: BM I have copies of Peer Direct's (Jan's company) port of PostgreSQL to BM Win32, and SRA's port to Win32, and permission to generate a merged BM patch that can be applied to 7.4. BM Now that 7.3 is almost complete, I am going to start work on that. I BM will post patches that deal with specific portability issues, like BM fork/exec and path separator handling, and once reviewed, apply them to BM the main CVS tree for 7.4. Just wondering, what compiler are they using ? Will it compile using Mingw ? I think the two projects are using MS C++, but it would be nice for Mingw to work too. -- 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
[HACKERS] 7.3b5 contrib compile problem
I saw this when compiling 7.3b4 as well and also with 7.3b5 cd contrib make ... make[1]: Leaving directory `/nfs/visor/u/software/postgres/postgresql-7.3b5/contrib/rtree_gist' make[1]: Entering directory `/nfs/visor/u/software/postgres/postgresql-7.3b5/contrib/seg' sed 's,MODULE_PATHNAME,$libdir/seg,g' seg.sql.in seg.sql gcc -O2 -g -Wall -Wmissing-prototypes -Wmissing-declarations -fpic -I. -I../../src/include -I/usr/local/include -c -o seg.o seg.c bison -y -d -p seg_yy segparse.y mv -f y.tab.c segparse.c mv -f y.tab.h segparse.h /usr/bin/flex -Pseg_yy -o'segscan.c' segscan.l gcc -O2 -g -Wall -Wmissing-prototypes -Wmissing-declarations -fpic -I. -I../../src/include -I/usr/local/include -c -o segparse.o segparse.c In file included from segscan.l:8, from segparse.y:182: segparse.h:2: redefinition of `struct BND' segparse.h:8: conflicting types for `YYSTYPE' segparse.y:48: previous declaration of `YYSTYPE' segparse.h:15: conflicting types for `seg_yylval' /usr/lib/bison.simple:138: previous declaration of `seg_yylval' make[1]: *** [segparse.o] Error 1 make[1]: Leaving directory `/nfs/visor/u/software/postgres/postgresql-7.3b5/contrib/seg' make: *** [all] Error 2 Any ideas? Thanks, -- 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 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Win32 port
Hello Bruce, Wednesday, November 6, 2002, 8:33:32 PM, you wrote: BM Steve Howe wrote: Hello Bruce, Wednesday, November 6, 2002, 3:19:35 AM, you wrote: BM I have copies of Peer Direct's (Jan's company) port of PostgreSQL to BM Win32, and SRA's port to Win32, and permission to generate a merged BM patch that can be applied to 7.4. BM Now that 7.3 is almost complete, I am going to start work on that. I BM will post patches that deal with specific portability issues, like BM fork/exec and path separator handling, and once reviewed, apply them to BM the main CVS tree for 7.4. Just wondering, what compiler are they using ? Will it compile using Mingw ? BM I think the two projects are using MS C++, but it would be nice for BM Mingw to work too. Or even (free) Borland C++ compiler, but I would be glad just to see it working with Mingw... It just makes no sense a free project like PostgreSQL to be compiled only with a commercial compiler. - Best regards, Steve Howe mailto:howe;carcass.dhs.org ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] 7.3b5 contrib compile problem
Wow, that is strange. I have bison 1.75 here and it compiles fine. What version of bison do you have? bison --version --- Laurette Cisneros wrote: I saw this when compiling 7.3b4 as well and also with 7.3b5 cd contrib make ... make[1]: Leaving directory `/nfs/visor/u/software/postgres/postgresql-7.3b5/contrib/rtree_gist' make[1]: Entering directory `/nfs/visor/u/software/postgres/postgresql-7.3b5/contrib/seg' sed 's,MODULE_PATHNAME,$libdir/seg,g' seg.sql.in seg.sql gcc -O2 -g -Wall -Wmissing-prototypes -Wmissing-declarations -fpic -I. -I../../src/include -I/usr/local/include -c -o seg.o seg.c bison -y -d -p seg_yy segparse.y mv -f y.tab.c segparse.c mv -f y.tab.h segparse.h /usr/bin/flex -Pseg_yy -o'segscan.c' segscan.l gcc -O2 -g -Wall -Wmissing-prototypes -Wmissing-declarations -fpic -I. -I../../src/include -I/usr/local/include -c -o segparse.o segparse.c In file included from segscan.l:8, from segparse.y:182: segparse.h:2: redefinition of `struct BND' segparse.h:8: conflicting types for `YYSTYPE' segparse.y:48: previous declaration of `YYSTYPE' segparse.h:15: conflicting types for `seg_yylval' /usr/lib/bison.simple:138: previous declaration of `seg_yylval' make[1]: *** [segparse.o] Error 1 make[1]: Leaving directory `/nfs/visor/u/software/postgres/postgresql-7.3b5/contrib/seg' make: *** [all] Error 2 Any ideas? Thanks, -- 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 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED] -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Win32 port
pgman wrote: I have copies of Peer Direct's (Jan's company) port of PostgreSQL to Win32, and SRA's port to Win32, and permission to generate a merged patch that can be applied to 7.4. Now that 7.3 is almost complete, I am going to start work on that. I will post patches that deal with specific portability issues, like fork/exec and path separator handling, and once reviewed, apply them to the main CVS tree for 7.4. I have talked to Jan, and PeerDirect wants to submit a complete working Win32 patch, rather than the piece-by-piece merged patch I was working on. They also have a newer version than the one they shared with me. They realize that their patch is very unlikely to be accepted in whole, but rather merged in and reworked to fit into our code cleanly. They also realize 7.4 will be a moving target as people make changes to CVS. Part of my goal was to get this in quickly while CVS was relatively stable, particularly hitting the portability issues that are spread throughout the code, and dealing with sticky issues like rename(). I believe they are in their right to determine how the patch is released to the community, so it seems we either have to wait for them to complete their mega-patch, which could take one month or more, or start working on a patch ourselves. Let me map out the calendar. I think we are very close on the point-in-time recovery patch. I am hoping to get that in during November, and I _was_ hoping for the Win32 port too, so we could have another two months of development, then start beta for 7.4. As it stands now, we could be adding Win32 at the end of December, pushing back 7.4. Comments? -- 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] 7.3b5 contrib compile problem
bison --version GNU Bison version 1.28 Should I update it? This just started with 7.3b4. Thanks, L. On Wed, 6 Nov 2002, Bruce Momjian wrote: Wow, that is strange. I have bison 1.75 here and it compiles fine. What version of bison do you have? bison --version --- Laurette Cisneros wrote: I saw this when compiling 7.3b4 as well and also with 7.3b5 cd contrib make ... make[1]: Leaving directory `/nfs/visor/u/software/postgres/postgresql-7.3b5/contrib/rtree_gist' make[1]: Entering directory `/nfs/visor/u/software/postgres/postgresql-7.3b5/contrib/seg' sed 's,MODULE_PATHNAME,$libdir/seg,g' seg.sql.in seg.sql gcc -O2 -g -Wall -Wmissing-prototypes -Wmissing-declarations -fpic -I. -I../../src/include -I/usr/local/include -c -o seg.o seg.c bison -y -d -p seg_yy segparse.y mv -f y.tab.c segparse.c mv -f y.tab.h segparse.h /usr/bin/flex -Pseg_yy -o'segscan.c' segscan.l gcc -O2 -g -Wall -Wmissing-prototypes -Wmissing-declarations -fpic -I. -I../../src/include -I/usr/local/include -c -o segparse.o segparse.c In file included from segscan.l:8, from segparse.y:182: segparse.h:2: redefinition of `struct BND' segparse.h:8: conflicting types for `YYSTYPE' segparse.y:48: previous declaration of `YYSTYPE' segparse.h:15: conflicting types for `seg_yylval' /usr/lib/bison.simple:138: previous declaration of `seg_yylval' make[1]: *** [segparse.o] Error 1 make[1]: Leaving directory `/nfs/visor/u/software/postgres/postgresql-7.3b5/contrib/seg' make: *** [all] Error 2 Any ideas? Thanks, -- 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 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED] -- 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 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [HACKERS] 7.3b5 contrib compile problem
I think bison 1.75 will fix it. I am just not sure why earlier releases fail that way. --- Laurette Cisneros wrote: bison --version GNU Bison version 1.28 Should I update it? This just started with 7.3b4. Thanks, L. On Wed, 6 Nov 2002, Bruce Momjian wrote: Wow, that is strange. I have bison 1.75 here and it compiles fine. What version of bison do you have? bison --version --- Laurette Cisneros wrote: I saw this when compiling 7.3b4 as well and also with 7.3b5 cd contrib make ... make[1]: Leaving directory `/nfs/visor/u/software/postgres/postgresql-7.3b5/contrib/rtree_gist' make[1]: Entering directory `/nfs/visor/u/software/postgres/postgresql-7.3b5/contrib/seg' sed 's,MODULE_PATHNAME,$libdir/seg,g' seg.sql.in seg.sql gcc -O2 -g -Wall -Wmissing-prototypes -Wmissing-declarations -fpic -I. -I../../src/include -I/usr/local/include -c -o seg.o seg.c bison -y -d -p seg_yy segparse.y mv -f y.tab.c segparse.c mv -f y.tab.h segparse.h /usr/bin/flex -Pseg_yy -o'segscan.c' segscan.l gcc -O2 -g -Wall -Wmissing-prototypes -Wmissing-declarations -fpic -I. -I../../src/include -I/usr/local/include -c -o segparse.o segparse.c In file included from segscan.l:8, from segparse.y:182: segparse.h:2: redefinition of `struct BND' segparse.h:8: conflicting types for `YYSTYPE' segparse.y:48: previous declaration of `YYSTYPE' segparse.h:15: conflicting types for `seg_yylval' /usr/lib/bison.simple:138: previous declaration of `seg_yylval' make[1]: *** [segparse.o] Error 1 make[1]: Leaving directory `/nfs/visor/u/software/postgres/postgresql-7.3b5/contrib/seg' make: *** [all] Error 2 Any ideas? Thanks, -- 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 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED] -- Laurette Cisneros The Database Group (510) 420-3137 NextBus Information Systems, Inc. www.nextbus.com -- My other vehicle is my imagination. - bumper sticker -- 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: [HACKERS] 7.3b5 contrib compile problem
Oh, I see it now, I think there was a change on November 1st to rule generation, but I can't see how that would cause your problem. If you 'patch -R' the attached patch, does it fix the problem? --- Bruce Momjian wrote: I think bison 1.75 will fix it. I am just not sure why earlier releases fail that way. --- Laurette Cisneros wrote: bison --version GNU Bison version 1.28 Should I update it? This just started with 7.3b4. Thanks, L. On Wed, 6 Nov 2002, Bruce Momjian wrote: Wow, that is strange. I have bison 1.75 here and it compiles fine. What version of bison do you have? bison --version --- Laurette Cisneros wrote: I saw this when compiling 7.3b4 as well and also with 7.3b5 cd contrib make ... make[1]: Leaving directory `/nfs/visor/u/software/postgres/postgresql-7.3b5/contrib/rtree_gist' make[1]: Entering directory `/nfs/visor/u/software/postgres/postgresql-7.3b5/contrib/seg' sed 's,MODULE_PATHNAME,$libdir/seg,g' seg.sql.in seg.sql gcc -O2 -g -Wall -Wmissing-prototypes -Wmissing-declarations -fpic -I. -I../../src/include -I/usr/local/include -c -o seg.o seg.c bison -y -d -p seg_yy segparse.y mv -f y.tab.c segparse.c mv -f y.tab.h segparse.h /usr/bin/flex -Pseg_yy -o'segscan.c' segscan.l gcc -O2 -g -Wall -Wmissing-prototypes -Wmissing-declarations -fpic -I. -I../../src/include -I/usr/local/include -c -o segparse.o segparse.c In file included from segscan.l:8, from segparse.y:182: segparse.h:2: redefinition of `struct BND' segparse.h:8: conflicting types for `YYSTYPE' segparse.y:48: previous declaration of `YYSTYPE' segparse.h:15: conflicting types for `seg_yylval' /usr/lib/bison.simple:138: previous declaration of `seg_yylval' make[1]: *** [segparse.o] Error 1 make[1]: Leaving directory `/nfs/visor/u/software/postgres/postgresql-7.3b5/contrib/seg' make: *** [all] Error 2 Any ideas? Thanks, -- 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 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED] -- Laurette Cisneros The Database Group (510) 420-3137 NextBus Information Systems, Inc. www.nextbus.com -- My other vehicle is my imagination. - bumper sticker -- 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 -- 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 ? seg.sql ? segscan.c ? segparse.c ? segparse.h ? libseg.so.0.0 Index: Makefile === RCS file: /cvsroot/pgsql-server/contrib/seg/Makefile,v retrieving revision 1.6 retrieving revision 1.7 diff -c -c -r1.6 -r1.7 *** Makefile16 Nov 2001 16:32:33 - 1.6 --- Makefile1 Nov 2002 22:52:33 - 1.7 *** *** 1,15 ! # $Header: /cvsroot/pgsql-server/contrib/seg/Makefile,v 1.6 2001/11/16 16:32:33 petere Exp $ subdir = contrib/seg top_builddir = ../.. include $(top_builddir)/src/Makefile.global MODULE_big = seg ! OBJS = seg.o segparse.o segscan.o buffer.o DATA_built = seg.sql DOCS = README.seg REGRESS = seg segparse.c: segparse.h ; --- 1,18 ! # $Header: /cvsroot/pgsql-server/contrib/seg/Makefile,v 1.7 2002/11/01 22:52:33 tgl Exp $ subdir = contrib/seg top_builddir = ../.. include $(top_builddir)/src/Makefile.global MODULE_big = seg ! OBJS = seg.o segparse.o buffer.o DATA_built = seg.sql DOCS = README.seg REGRESS = seg + + # segscan is compiled as part of segparse + segparse.o: segscan.c segparse.c: segparse.h ; Index: segparse.y === RCS file: /cvsroot/pgsql-server/contrib/seg/segparse.y,v retrieving revision 1.6 retrieving revision 1.7 diff -c -c -r1.6 -r1.7 *** segparse.y 22 Sep 2002 21:51:18 - 1.6
Re: [HACKERS] Win32 port
On Wed, Nov 06, 2002 at 08:20:16PM -0500, Bruce Momjian wrote: Let me map out the calendar. I think we are very close on the point-in-time recovery patch. I am hoping to get that in during November, and I _was_ hoping for the Win32 port too, so we could have another two months of development, then start beta for 7.4. As it stands now, we could be adding Win32 at the end of December, pushing back 7.4. What about patches that are in the pgpatches2 list? Are you going to merge that right now, or wait for each item to be reviewed? -- Alvaro Herrera (alvherre[a]dcc.uchile.cl) Pido que me den el Nobel por razones humanitarias (Nicanor Parra) ---(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
Alvaro Herrera wrote: On Wed, Nov 06, 2002 at 08:20:16PM -0500, Bruce Momjian wrote: Let me map out the calendar. I think we are very close on the point-in-time recovery patch. I am hoping to get that in during November, and I _was_ hoping for the Win32 port too, so we could have another two months of development, then start beta for 7.4. As it stands now, we could be adding Win32 at the end of December, pushing back 7.4. What about patches that are in the pgpatches2 list? Are you going to merge that right now, or wait for each item to be reviewed? Good question. Let's say I will apply them in two days unless someone objects to them. They all look pretty safe to me. -- 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
[HACKERS] PostgreSQL supported platform report and a patch.
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.
*** ./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.
***
*) Using the UDK on OpenServer
*** ./src/backend/utils/sort/tuplesort.c.orig Wed Nov 6 02:19:35 2002
--- ./src/backend/utils/sort/tuplesort.cWed Nov 6 02:21:14 2002
***
*** 1802,1808
/*
* Inline-able copy of FunctionCall2() to save some cycles in sorting.
*/
! static inline Datum
myFunctionCall2(FmgrInfo *flinfo, Datum arg1, Datum arg2)
{
FunctionCallInfoData fcinfo;
--- 1802,1808
/*
* Inline-able copy of FunctionCall2() to save some cycles in sorting.
*/
! inline Datum
myFunctionCall2(FmgrInfo *flinfo, Datum arg1, Datum arg2)
{
FunctionCallInfoData fcinfo;
*** ./src/makefiles/Makefile.unixware.orig Wed Nov 6 02:57:52 2002
--- ./src/makefiles/Makefile.unixware Wed Nov 6 21:33:20 2002
***
*** 7,15
ifeq ($(ld_R_works), yes)
ifeq ($(with_gnu_ld), yes)
! rpath = -Wl,-rpath,$(libdir)
else
! rpath = -Wl,-R$(libdir)
endif
endif
shlib_symbolic = -Wl,-Bsymbolic
--- 7,21
ifeq ($(ld_R_works), yes)
ifeq ($(with_gnu_ld), yes)
! # Convert the list of library search paths into -rpath options.
! # (i.e. -LpathA -LpathB - ,-rpath,pathA,-rpath,pathB
! tpath := $(shell echo $(trpath) | sed -e 's/ *-L/,-rpath,/g')
! rpath = -Wl,-rpath,$(libdir)$(trpath)
else
! # Convert the list of library search paths into a -R option path.
! # (i.e. -LpathA -LpathB - :pathA:pathB
! tpath := $(shell echo $(trpath) | sed -e 's/ *-L/:/g')
! rpath = -Wl,-R$(libdir)$(tpath)
endif
endif
shlib_symbolic = -Wl,-Bsymbolic
*** ./src/Makefile.global.in.orig Wed Nov 6 03:38:03 2002
--- ./src/Makefile.global.inWed Nov 6 04:22:34 2002
***
*** 189,194
--- 189,197
LD = @LD@
with_gnu_ld = @with_gnu_ld@
ld_R_works = @ld_R_works@
+ # Set trpath to a list of library paths included in LDFLAGS
+ # These paths can be added to rpath in the port specific makefiles if needed.
+ trpath = $(filter -L%,@LDFLAGS@)
LDFLAGS = @LDFLAGS@
LDREL = -r
LDOUT = -o
| Billy G. Allie| Domain: [EMAIL PROTECTED]
| /| | 7436 Hartwell | MSN...: [EMAIL PROTECTED]
|-/-|- | Dearborn, MI 48126|
|/ |LLIE | (313) 582-1540|
msg24783/pgp0.pgp
Description: PGP signature
[HACKERS] Outstanding patches
I will be applying outstanding 7.4 patches on Friday: http:/momjian.postgresql.org/cgi-bin/pgpatches2 If anyone wants those rejected/modified, please let me know. -- 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
[HACKERS] Too late for translation updates?
Hi, 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? Thanks, -- Serguei A. Mokhov ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Win32 port
Bruce Momjian [EMAIL PROTECTED] writes: I have talked to Jan, and PeerDirect wants to submit a complete working Win32 patch, rather than the piece-by-piece merged patch I was working on. Is there a reason you're doing the actual merging with CVS? ISTM it might be more straight-forward to just wait for PeerDirect to get their code in a state that can be committed straight to CVS, using the normal code review process. That would leave the ball in PeerDirect's code, as far as staying current with any changes made to CVS in the interim. BTW, what about the SRA stuff? i.e. could we begin work on a native Win32 port using their work, while at the same time waiting for PeerDirect? Let me map out the calendar. I think we are very close on the point-in-time recovery patch. I am hoping to get that in during November, and I _was_ hoping for the Win32 port too, so we could have another two months of development, then start beta for 7.4. As it stands now, we could be adding Win32 at the end of December, pushing back 7.4. You've mentioned the quickly release 7.4 plan before, but I'm not sure I agree with the reasoning behind it. PITR and Win32, while certainly important features, are not critical enough that they justify an entire release for themselves, IMHO. Plus, there's a definate downside to releasing quickly: users will still need to 'initdb' between major releases, no matter how quickly they are put out. It's also possible that a faster release cycle would mean a more rushed, less stable development process (and therefore more bugs). Cheers, Neil -- Neil Conway [EMAIL PROTECTED] || PGP Key ID: DB3C29FC ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] RC1 on Friday?
News to me ... On Wed, 6 Nov 2002, Bruce Momjian wrote: Are we still on schedule for RC1 on Friday? -- 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]) ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Win32 port
Neil Conway wrote: Bruce Momjian [EMAIL PROTECTED] writes: I have talked to Jan, and PeerDirect wants to submit a complete working Win32 patch, rather than the piece-by-piece merged patch I was working on. Is there a reason you're doing the actual merging with CVS? ISTM it might be more straight-forward to just wait for PeerDirect to get their code in a state that can be committed straight to CVS, using the normal code review process. That would leave the ball in PeerDirect's code, as far as staying current with any changes made to CVS in the interim. Clearly, it is better if Jan/PeerDirect does the job. The question is when it will happen. I figured if I got it started, they could then get involved when they have time. I recommend the port be submitted in pieces, meaning make one patch dealing with path names, another for initdb, etc. However, they want to do the work, and hopefully it will be done in a reasonable time, so I certainly can wait. BTW, what about the SRA stuff? i.e. could we begin work on a native Win32 port using their work, while at the same time waiting for PeerDirect? Yes, certainly I can. The problem there is that once I attack various areas, Jan's work becomes harder because he has to take his version and merge in into my changes. Let me map out the calendar. I think we are very close on the point-in-time recovery patch. I am hoping to get that in during November, and I _was_ hoping for the Win32 port too, so we could have another two months of development, then start beta for 7.4. As it stands now, we could be adding Win32 at the end of December, pushing back 7.4. You've mentioned the quickly release 7.4 plan before, but I'm not sure I agree with the reasoning behind it. PITR and Win32, while certainly important features, are not critical enough that they justify an entire release for themselves, IMHO. Plus, there's a definate downside to releasing quickly: users will still need to 'initdb' between major releases, no matter how quickly they are put out. It's also possible that a faster release cycle would mean a more rushed, less stable development process (and therefore more bugs). I have thrown out the idea and some felt that if we could get PITR and Win32, that would be enough for a release, even if we could get it done in a month or two. However, I see your point that releasing too often causes too many initdb's. What do others want, a regular 4-6 month cycle or a shorter one? -- 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] RC1 on Friday?
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. -- 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] PostgreSQL supported platform report and a patch.
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.
---
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
[HACKERS] Datetime type dropped from v7.3 ?
Hello all, Just wondering if the datetime type was dropped on purpose from PostgreSQL 7.3 ? This is not an issue of course, I'll be using timestamp, but it's weird having that dropped. --- -- On PostgreSQL 7.2: --- howe=# select version(); version --- PostgreSQL 7.2.1 on i386-portbld-freebsd4.6.2, compiled by GCC 2.95.3 (1 row) howe=# create table a(b datetime); CREATE howe=# \d a Table a Column |Type | Modifiers +-+--- b | timestamp without time zone | --- -- On PostgreSQL 7.3: --- howe=# select version (); version - PostgreSQL 7.3b3 on i386-unknown-freebsd4.4, compiled by GCC 2.95.3 (1 row) howe=# create table a(b datetime); ERROR: Type datetime does not exist - Best regards, Steve Howe mailto:howe;carcass.dhs.org ---(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
Bruce Momjian wrote: snip What do others want, a regular 4-6 month cycle or a shorter one? Whilst having a regular 4-6 month cycle (er... when was the last time THAT happened?) is alright, we should get the *Windows* native version out to the world ASAP. This (and secondly PITR) will greatly enhance the number of users we have. It's important to do this because companies and governments are looking to Open Source software in serious ways *now* so we need to be in place to meet that need as it starts to kick in. :) Regards and best wishes, Justin Clift -- 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]) -- My grandfather once told me that there are two kinds of people: those who work and those who take the credit. He told me to try to be in the first group; there was less competition there. - Indira Gandhi ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Datetime type dropped from v7.3 ?
Steve Howe [EMAIL PROTECTED] writes: Just wondering if the datetime type was dropped on purpose from PostgreSQL 7.3 ? Yes. Ad-hoc name translations in the parser create bogosities with respect to schemas --- I forget the details, but it was either drop datetime or make it a reserved keyword. Since datetime has been deprecated for a couple releases now, the choice seemed clear. 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] Datetime type dropped from v7.3 ?
Hello Tom, Thursday, November 7, 2002, 1:17:00 AM, you wrote: TL Steve Howe [EMAIL PROTECTED] writes: Just wondering if the datetime type was dropped on purpose from PostgreSQL 7.3 ? TL Yes. Ad-hoc name translations in the parser create bogosities with TL respect to schemas --- I forget the details, but it was either drop TL datetime or make it a reserved keyword. Since datetime has been TL deprecated for a couple releases now, the choice seemed clear. Oh. ok. I'm glad it was intended. Thanks :) - Best regards, Steve Howe mailto:howe;carcass.dhs.org ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] 7.3b5 contrib compile problem
Laurette Cisneros [EMAIL PROTECTED] writes: bison --version GNU Bison version 1.28 Should I update it? Yes. 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. regards, tom lane ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] 7.3b5 contrib compile problem
Laurette Cisneros [EMAIL PROTECTED] writes: bison --version GNU Bison version 1.28 Should I update it? Yes. 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. Do I have to install the CVS version of Bison to get the new compile to work? Chris ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Win32 port
Justin Clift [EMAIL PROTECTED] writes: Whilst having a regular 4-6 month cycle (er... when was the last time THAT happened?) is alright, we should get the *Windows* native version out to the world ASAP. We don't have a Windows native version, and it sounds like it'll be awhile before we have an offered set of patches to review. I think making any release schedule plans on the basis of (ahem) vaporware patches is a bit foolhardy. The quick 7.4 plan was based on the assumption that PITR and Windows patches would both be available almost immediately. If that doesn't come to pass then I see no reason not to go with a normal-length development cycle. 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] PostgreSQL supported platform report and a patch.
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 ---(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] 7.3b5 contrib compile problem
Christopher Kings-Lynne [EMAIL PROTECTED] writes: Do I have to install the CVS version of Bison to get the new compile to work? No, you can use their current release, 1.75. (Reportedly 1.50 works too, but I never tried it.) 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] protocol change in 7.4
Ross J. Reedstrom [EMAIL PROTECTED] wrote: 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. Yes. My current replication implementation is 'query based' replication, so all queries to the database (except SELECT command) are replicated. The database will be completely replicated, not partial. I know this 'query based' design can't be used for a distributed transaction. I think more internal communication between distributed servers is required. We need 'the partial transfer of tables', 'the bulk transfer of the index' or something like that for a distributed transaction. I'm working for it now. As I said, several connection types, a client application connection, an internal transfer connection or a recovery connection, will be required on replication and distributed transaction in near future. Embedding connection types in the startup packet is a good way to decide how the backend should behave. It is simple and extendable, isn't it? If the backend can't understand the incoming connection type, the backend will answer I can't understand. and need only disconnect it. 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. Yes. There are several implementation designs for replication. Sync or async, pre- or post-, full or partial, query-level or I/O-level or journal-level. I think there is no best way for replication, because applications have different requirements in different situations. So the protocol should be more extendable. 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'. After status is returned, what does the 'client' do? Should the client talk the 2PC protocol? For example, if the database is replicated in 8 servers, does the client application keep 8 connections for each server? Is this good? -- NAGAYASU Satoshi [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] 7.3b5 contrib compile problem
Tom Lane wrote: Laurette Cisneros [EMAIL PROTECTED] writes: bison --version GNU Bison version 1.28 Should I update it? Yes. 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. Just to clarify, do the tarballs for /contrib/seg have the pre-processed bison output, or are people required to have more current bisons to compile the code? -- 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] Outstanding patches
Bruce Momjian [EMAIL PROTECTED] writes: I will be applying outstanding 7.4 patches on Friday: http:/momjian.postgresql.org/cgi-bin/pgpatches2 If anyone wants those rejected/modified, please let me know. array upper/lower bound: missing doc updates, otherwise seems okay. \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. temp tables: difficult to comment on a message that does not include the proposed patch. CLUSTER ALL patch: I have a problem with this, specifically the fact that it changes CLUSTER into a multi-transaction operation. 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. CREATE SEQUENCE syntax changes: did we decide whether SQL99's notion of a sequence is close enough to ours that migrating to their syntax would be a good idea, and not just a source of confusion? I seem to recall some doubts being voiced about this (by Peter?), and I'm not sure we resolved them. regards, tom lane ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] Win32 port
Hello Bruce, Thursday, November 7, 2002, 12:56:57 AM, you wrote: BM I have thrown out the idea and some felt that if we could get PITR and BM Win32, that would be enough for a release, even if we could get it done BM in a month or two. BM However, I see your point that releasing too often causes too many BM initdb's. BM What do others want, a regular 4-6 month cycle or a shorter one? The initdb will be needed, no matter the release time is a month or six, right ? There is no point in holding technology that is ready. Those who don't need the release, can wait for the next one and avoid the initdb. Also, as a snapshot, the Win32 version won't get properly tested as it would be as a regular release, specially because most of the developers here work on UNIX. The best field testing would be deploying a regular release to the hundreds of Win32 users that wait for years for the Win32 version... ... just my thoughts, of course. - Best regards, Steve Howe mailto:howe;carcass.dhs.org ---(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.
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. -- 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] 7.3b5 contrib compile problem
Bruce Momjian [EMAIL PROTECTED] writes: Just to clarify, do the tarballs for /contrib/seg have the pre-processed bison output, or are people required to have more current bisons to compile the code? AFAIK we do not provide prebuilt bison or flex output for any of the contrib modules. regards, tom lane ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Outstanding patches
Tom Lane [EMAIL PROTECTED] writes: CREATE SEQUENCE syntax changes: did we decide whether SQL99's notion of a sequence is close enough to ours that migrating to their syntax would be a good idea, and not just a source of confusion? I seem to recall some doubts being voiced about this (by Peter?), and I'm not sure we resolved them. Last I heard, we had concluded that SQL2003's notion of a sequence is sufficiently close to ours that the differences are mostly syntax. (Note that SQL99 does not define sequences.) Cheers, Neil -- Neil Conway [EMAIL PROTECTED] || PGP Key ID: DB3C29FC ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] 7.3b5 contrib compile problem
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 ---(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] PostgreSQL supported platform report and a patch.
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). 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] [SQL] Problem: Referential Integrity Constraints lost
On Wed, 6 Nov 2002, Achilleus Mantzios wrote: 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?? Hmm, you haven't done anything like cluster or an incomplete dump and reload have you? ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
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 downloaded 7.3b5 and tested it. The problem with tuplesort.c has indeed been fixed. Bruce, ignore the patch to tuplesort.c that I sent in. The other three patches are still valid. Thanks. -- | Billy G. Allie| Domain: [EMAIL PROTECTED] | /| | 7436 Hartwell | MSN...: [EMAIL PROTECTED] |-/-|- | Dearborn, MI 48126| |/ |LLIE | (313) 582-1540| msg24810/pgp0.pgp Description: PGP signature
Re: [HACKERS] [GENERAL] CURRENT_TIME
...
In the long run, seems like it would be a good idea for type TIME
WITHOUT TIME ZONE's input converter to accept and ignore a timezone
field, just as type TIMESTAMP WITHOUT TIME ZONE does:
...
Thomas, what do you think --- was this behavior deliberate or an
oversight?
The behavior was deliberate, but predates the implementation of
TIMESTAMP WITHOUT TIME ZONE. The time zone is already ignored when
converting directly from TIME WITH TIME ZONE to TIME WITHOUT TIME ZONE:
lockhart=# select cast(time with time zone '2002-11-06
22:25:57.796141-05' as time);
time
-
22:25:57.796141
and one could claim that this should be allowed from string constants too:
thomas=# select cast('2002-11-06 22:25:57.796141-05' as time);
time
-
22:25:57.796141
Patch included to allow this latter case...
- Thomas
Index: date.c
===
RCS file: /home/thomas/cvs/repository/pgsql-server/src/backend/utils/adt/date.c,v
retrieving revision 1.73
diff -c -r1.73 date.c
*** date.c 21 Sep 2002 19:52:41 - 1.73
--- date.c 7 Nov 2002 06:32:05 -
***
*** 511,516
--- 511,517
fsec_t fsec;
struct tm tt,
*tm = tt;
+ int tz;
int nf;
charlowstr[MAXDATELEN + 1];
char *field[MAXDATEFIELDS];
***
*** 521,527
elog(ERROR, Bad time external representation (too long) '%s', str);
if ((ParseDateTime(str, lowstr, field, ftype, MAXDATEFIELDS, nf) != 0)
!|| (DecodeTimeOnly(field, ftype, nf, dtype, tm, fsec, NULL) != 0))
elog(ERROR, Bad time external representation '%s', str);
tm2time(tm, fsec, result);
--- 522,528
elog(ERROR, Bad time external representation (too long) '%s', str);
if ((ParseDateTime(str, lowstr, field, ftype, MAXDATEFIELDS, nf) != 0)
!|| (DecodeTimeOnly(field, ftype, nf, dtype, tm, fsec, tz) != 0))
elog(ERROR, Bad time external representation '%s', str);
tm2time(tm, fsec, result);
---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] PostgreSQL supported platform report and a patch.
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? regards, tom lane ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
