Re: [HACKERS] cygwin build failure
Tom Lane schrieb: Dunno about the optarg business; it sounds like a DLLIMPORT is needed someplace, but maybe that is a bug in the Cygwin headers rather than our bug? No, that's no bug, just diagnostic messages with the new linker. gcc -O2 -Wall -Wmissing-prototypes -Wpointer-arith -Wendif-labels -fno-strict-aliasing -g pg_dump.o common.o pg_dump_sort.o pg_backup_archiver.o pg_backup_db.o pg_backup_custom.o pg_backup_files.o pg_backup_null.o pg_backup_tar.o dumputils.o ../../../src/backend/parser/keywords.o -L../../../src/interfaces/libpq -lpq -L../../../src/port -L/usr/local/lib -lpgport -lcrypt -o pg_dump.exe ... Info: resolving _optarg by linking to __imp__optarg (auto-import) Info: resolving _optind by linking to __imp__optind (auto-import) collect2: ld returned 1 exit status make[3]: *** [pg_dump] Error 1 I'll check how to get rid of that if you want to get rid of it without grep -v :) But I don't think that is is easily possible to turn off these purely diagnostic messages, without cluttering the source with those __DLL_IMPORT declarations. And I found no easy ld cmdline override solution. But I'll backcheck. #ifdef BUILDING_DLL # ifndef __GNUC__ # define __DLL_IMPORT __declspec(dllimport) # else # define __DLL_IMPORT __attribute__((dllimport)) extern # endif #else # define __DLL_IMPORT #endif -- Reini Urban http://xarch.tu-graz.ac.at/home/rurban/ ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] Proposal for Recover mode in pg_ctl (in 8.0)
On Sun, 2004-11-07 at 00:16, Tom Lane wrote: I wrote: A possibly more reliable interlock would involve having the postmaster probe during normal startup to see if there is already an archived WAL segment for what it thinks is the current segment. Another and simpler way is to recommend that people use archive_command strings that won't overwrite an existing archive file. Yes, exactly what I meant by saying I'd document the warning. -- Best Regards, Simon Riggs ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [HACKERS] Proposal for Recover mode in pg_ctl (in 8.0)
On Sun, 2004-11-07 at 00:54, Mark Kirkwood wrote: While this is nice, it will not help you if the restoration directory is different from your archive directory. That is : restore_command in recovery.conf fetches from somewhere other than where archive_command in postgresql.conf copied. ...hmmm, this doesn't look like an issue to me. If the archive is protected when it's written, then it will be safe to use later for restoration. The path to the archive may differ, but the archive itself *needs* to be the same archive. -- Best Regards, Simon Riggs ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Proposal for Recover mode in pg_ctl (in 8.0)
On Sat, 2004-11-06 at 23:29, Tom Lane wrote: Simon Riggs [EMAIL PROTECTED] writes: If a further pg_ctl mode, recover, were implemented, this would allow a fail safe mode for recovery. e.g.pg_ctl -D datadir recover pg_ctl could then check for the existence of a recovery.conf file and return an error if none were found. ... A possibly more reliable interlock would involve having the postmaster probe during normal startup to see if there is already an archived WAL segment for what it thinks is the current segment. However there are several issues here: one is that if you're doing partial-log-file shipping, that isn't necessarily an error condition; another is that we don't know how to do such a probe unless more information is added to postgresql.conf. We could imagine adding another shell command string (something like test -f ... perhaps) but if the user gets it wrong he may still be left with no protection. Yes, checking the archive is the safe way, but we don't know how to do that unless restore_command has been successfully read in (currently from recovery.conf). Putting it in postgresql.conf is the wrong place, because that will likely be wrongly set when we restore, and I'm against editing that file as part of a recovery...once edited, you could lose all context and thus completely screw the recovery. All the suggested change is about is trying to find a safe way to fail if restore_command has not been set because recovery.conf is missing for whatever reason. I can't get very excited about this approach, because it only protects those people who (a) use pg_ctl to start the postmaster (not everyone) and (b) carefully follow the recovery directions (which the people you are worried about are very bad at, by hypothesis). Well, I was trying to find a least-risk approach. Touching pg_ctl code at this stage of beta-ness seemed more reliable than touching postmaster code. pg_ctl doesn't catch everyone. Placing the test in postmaster is the natural place for it, yes. This additional keyword should never be placed in any startup script, so the commonly used interface would not change, just the one used at recovery time. Documentation changes are one thing - and as you point out, if they miss one thing in the manual, they'll miss three. I'm not expecting many people to actually use an archive created by using copy or cp. I'm with Mark on this: you need all the help you can get at 2am when you just got called out of bed with a phone call from your boss *requesting* you to recover your incredibly important production system. I'll cut the doc changes first, then produce a slim patch on postmaster. Best Regards, Simon Riggs ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
[HACKERS] pgxs under Win32 for PL/Java
Dear Thomas, I'm trying to change the Makefile system for PL/Java so that it uses PGXS instead of compiling using a complete PostgreSQL source tree. As it turns out, the directory include/port/win32 is not present in the PostgreSQL binary installation. Without it, it's not possible to compile on win32. Please find enclosed a patch which attempts to fix your use of pgxs under win32: - install port/* includes - install libpostgres.a by default (it seems to require MAKE_DLL=true) - fix include path under win32 portname The specific win32 fixes are performed in the Makefile.win32 file. I have no mean to test that on a win32 machine. Could you do it? I'm wondering whether the MAKE_DLL fix should also be done under cygwin. Any opinion? Thanks in advance, -- Fabien Coelho - [EMAIL PROTECTED]*** ./src/include/Makefile.orig Wed Nov 3 10:32:29 2004 --- ./src/include/Makefile Sun Nov 7 11:14:52 2004 *** *** 18,24 # Subdirectories containing headers for server-side dev SUBDIRS = access bootstrap catalog commands executor lib libpq mb \ ! nodes optimizer parser port regex rewrite storage tcop utils # Install all headers install: all installdirs remove-old-headers --- 18,25 # Subdirectories containing headers for server-side dev SUBDIRS = access bootstrap catalog commands executor lib libpq mb \ ! nodes optimizer parser port regex rewrite storage tcop utils \ ! port port/win32 port/win32/arpa port/win32/netinet port/win32/sys # Install all headers install: all installdirs remove-old-headers *** ./src/makefiles/Makefile.win32.orig Thu Oct 28 08:24:17 2004 --- ./src/makefiles/Makefile.win32 Sun Nov 7 10:44:58 2004 *** *** 35,37 --- 35,48 ifneq (,$(findstring src/pl/plpython,$(subdir))) override CPPFLAGS+= -DUSE_DL_IMPORT endif + + # special win32 headers are provided here + ifdef PGXS + override CPPFLAGS+= $(includedir_server)/port/win32 + endif + + # it is better to install shared-libraries anyway? + # may be overriden with make MAKE_DLL=false install + ifndef MAKE_DLL + MAKE_DLL = true + endif ---(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] pgxs under Win32 for PL/Java
Fabien COELHO wrote: I have no mean to test that on a win32 machine. Could you do it? Sure, I'll test it sometime tomorrow or the day after. I'll get back to you. I'm wondering whether the MAKE_DLL fix should also be done under cygwin. Any opinion? I can test cygwin too. But just out of curiosity; why would anyone want to use cygwin with 8.0? Regards, Thomas Hallgren ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Documentation on PITR still scarce
On Sat, Nov 06, 2004 at 07:17:29PM +, Simon Riggs wrote: Once you have brought up a database in timeline N+1, you can't use it as the base to recover to a point in timeline N because the data file contents cannot be trusted to be identical to the way they were in timeline N. You mean in timeline N ... to a point in timeline N+1, don't you? Specifically not. The point is: you can't go back in time. Recovery is a rollforward operation, so you must start at an earlier point and rollforwards from there. Ok, that seems to be pretty intuitive. But could one extend the recovery mechanism such that one can go from PIT t_0 to PIT t_1 with t_1 t_0 without re-restoring the original backup? Joachim ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [HACKERS] [PATCHES] pgxs under Win32 for PL/Java
I can test cygwin too. But just out of curiosity; why would anyone want to use cygwin with 8.0? It runs on 9x, native requires NT. There are still a lot of ppl on 9x. I wouldn't expect a production server on 9x (indeed not a server at all), but certainly some desktops that are using it. //Magnus ---(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] Documentation on PITR still scarce
On Sun, 2004-11-07 at 11:15, Joachim Wieland wrote: On Sat, Nov 06, 2004 at 07:17:29PM +, Simon Riggs wrote: Once you have brought up a database in timeline N+1, you can't use it as the base to recover to a point in timeline N because the data file contents cannot be trusted to be identical to the way they were in timeline N. You mean in timeline N ... to a point in timeline N+1, don't you? Specifically not. The point is: you can't go back in time. Recovery is a rollforward operation, so you must start at an earlier point and rollforwards from there. Ok, that seems to be pretty intuitive. But could one extend the recovery mechanism such that one can go from PIT t_0 to PIT t_1 with t_1 t_0 without re-restoring the original backup? Same question, just restated. When you stop recovery at point in time, t_0 is now in timeline N+1, though it does also still exist in timeline N. In the new timeline there is no such thing (yet) as a time/transaction t_0. In timeline N only, you can go from t_0 to t_1, but not starting from where you are now, because you are now at t_0 in timeline N+1. That's the general case. ...and you can see why Tom described it as like science fiction. Anyway, you're trying to optimize re-recovery, which would be slightly lower on the priority list than optimizing recovery itself. General readers should just remember this: if you recover, and you decide you've done it wrong, you can re-recover to a different place. You don't need to understand all of that complexity to use the PITR facilities. -- Best Regards, Simon Riggs ---(end of broadcast)--- TIP 8: explain analyze is your friend
[HACKERS] adding and compiling new code
Hi all I've just started writing code to PostgreSQL 7.4.2 and I wand to recompile the new source code that I added in some .c files. I suspect that there must be a quicker way to compile those files than executing the commands: ./configure, gmake, gmake install... . Could I use only some Makefiles (the correspodent ones) that there are in each directory? If yes, how should I use them? Thanks, regards Martha ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] adding and compiling new code
On Sun, 7 Nov 2004, Martha Chronopoulou wrote: recompile the new source code that I added in some .c files. I suspect that there must be a quicker way to compile those files than executing the commands: ./configure, gmake, gmake install... . Could I use only some Makefiles (the correspodent ones) that there are in each directory? If yes, how should I use them? After one have made the first compile and install, it's usually enough to just compile and install a part of pg. For example if you have changed something in psql then you run make followed by make install in the psql subdirectory of the source. Some changes demand a full new compile (make clean and sometimes make distclean) and some changes demand that you do initdb again, but in most cases one can just compile a part of pg. Then install that part and restart the server. I have a fairly slow computer (800 MHz) and I use ccache which make it much faster to rebuild pg then without. A big difference. I still want a faster computer, but we don't get all we want I'm afraid :-) -- /Dennis Björklund ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [HACKERS] cygwin build failure
Reini Urban schrieb: Tom Lane schrieb: Dunno about the optarg business; it sounds like a DLLIMPORT is needed someplace, but maybe that is a bug in the Cygwin headers rather than our bug? No, that's no bug, just diagnostic messages with the new linker. gcc -O2 -Wall -Wmissing-prototypes -Wpointer-arith -Wendif-labels -fno-strict-aliasing -g pg_dump.o common.o pg_dump_sort.o pg_backup_archiver.o pg_backup_db.o pg_backup_custom.o pg_backup_files.o pg_backup_null.o pg_backup_tar.o dumputils.o ../../../src/backend/parser/keywords.o -L../../../src/interfaces/libpq -lpq -L../../../src/port -L/usr/local/lib -lpgport -lcrypt -o pg_dump.exe ... Info: resolving _optarg by linking to __imp__optarg (auto-import) Info: resolving _optind by linking to __imp__optind (auto-import) collect2: ld returned 1 exit status make[3]: *** [pg_dump] Error 1 I'll check how to get rid of that if you want to get rid of it without grep -v :) But I don't think that is is easily possible to turn off these purely diagnostic messages, without cluttering the source with those __DLL_IMPORT declarations. And I found no easy ld cmdline override solution. But I'll backcheck. ok, i'm sure now. there's no way to ignore those diagnostics on the ld side. -- Reini Urban http://xarch.tu-graz.ac.at/home/rurban/ ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] pgxs under Win32 for PL/Java
Fabien, Seems you forgot to put a -I before the include directive in src/makefiles/Makefile.win32, i.e. change: override CPPFLAGS+= $(includedir_server)/port/win32 to: override CPPFLAGS+= -I$(includedir_server)/port/win32 but in other respects, the patch seems to work fine on win32. I'll test Cygwin next. Regards, Thomas Hallgren ---(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] use of IDE's an tools
Gevik Babakhani schrieb: Would you please be so kind to help me with some pointers about which IDEs you use in order to compile and take a look at the sources? Any comment is appreciated. my windows IDE: cmd.exe, 4nt.exe or rxvt.exe terms with bash or cmd as shells, XEmacs, TotalCommander coLinux to crosscheck on a linux image (faster than vmware, in fact much faster than windows) compile: make + gcc, or nmake + msvc cl.exe look at the sources: XEmacs or TotalCommander f3 or $ less src -- Reini Urban http://xarch.tu-graz.ac.at/home/rurban/ ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [HACKERS] cygwin build failure
Reini Urban wrote: ... Info: resolving _optarg by linking to __imp__optarg (auto-import) Info: resolving _optind by linking to __imp__optind (auto-import) ok, i'm sure now. there's no way to ignore those diagnostics on the ld side. It's a minor annoyance at worst. Not worth spending effort on. The issue in these lines is the important one: ccache gcc -O2 -Wall -Wmissing-prototypes -Wpointer-arith -Wendif-labels -fno-strict-aliasing -g pg_dump.o common.o pg_dump_sort.o pg_backup_archiver.o pg_backup_db.o pg_backup_custom.o pg_backup_files.o pg_backup_null.o pg_backup_tar.o dumputils.o ../../../src/backend/parser/keywords.o -L../../../src/interfaces/libpq -lpq -L../../../src/port -L/usr/local/lib -lpgport -lz -lreadline -lcrypt -o pg_dump.exe ../../../src/port/libpgport.a(pgstrcasecmp.o)(.text+0x1b0): In function `pg_tolower': /home/adunstan/pgbf/root/HEAD/pgsql.4040/src/port/pgstrcasecmp.c:119: multiple definition of `_pg_tolower' ../../../src/interfaces/libpq/libpq.a(dqgds00145.o)(.text+0x0): first defined here cheers andrew ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
[HACKERS] Memory Context problems...
Hi everybody, I have some problems with management of memory contexts (at least I thing so). I'll try to describe my problem in a few lines: I've written some code based on spi.c. I've created my_spi.c (and my_spi.h) which provide some more features I wanted (did not alter spi itself to keep code clear). Anyway, I've managed to get them into the backend and call some of the functions from a user defined function. The problem is that I experience some problems during the transition from one memory context to another. More precisely,when I call (my_)SPI_prepare the following message comes exactly at the point where (my_)SPI_end_call(true) is called: WARNING: problem in alloc set my_SPI Exec: detected write past chunk end in block 0x830b7e8, chunk 0x830c058 WARNING: problem in alloc set my_SPI Exec: detected write past chunk end in block 0x8307720, chunk 0x830b6cc Moreover, when I true to call (my_)SPI_finish the server crashes. Note, that the results expected from the my_SPI calls are returned correctly. Any ideas? I think it is something with the memory contexts but obviously this is not enough to solve the problem. Thank you in advance! Ntinos Katsaros ---(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] pg_arch.c call to sleep()
We have the following warning on Windows: pgarch.c:349: warning: implicit declaration of function `sleep' To fix it we could include the right header (which appears to be stdlib.h in the Windows/Mingw case), or we could replace the call by a call to pg_usleep(). I'm inclined to do the latter, on grounds of consistency, but want to be sure that it will get the signal handling right. Unless I hear squawks of objection I will supply a patch for that soon. cheers andrew ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] pgxs under Win32 for PL/Java
Fabien, The problem described in the recent thread cygwin build failure prevents me from building on Cygwin at present. I'll await a patch for that. Regards, Thomas Hallgren ---(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] Documentation on PITR still scarce
Simon Riggs [EMAIL PROTECTED] writes: On Sun, 2004-11-07 at 11:15, Joachim Wieland wrote: Ok, that seems to be pretty intuitive. But could one extend the recovery mechanism such that one can go from PIT t_0 to PIT t_1 with t_1 t_0 without re-restoring the original backup? Same question, just restated. When you stop recovery at point in time, t_0 is now in timeline N+1, though it does also still exist in timeline N. In the new timeline there is no such thing (yet) as a time/transaction t_0. The real point is that as soon as you do anything, you are most definitely not in timeline N anymore; you are executing transactions in a new history of the database (new timeline). The reason we need a re-restore is that there's no other way to undo whatever you have done in timeline N+1. I suppose it might be useful to have some kind of suspended animation behavior where you could bring up a backend and look at the database in a strict read-only fashion, not really executing transactions at all, just to see what you had. Then you could end the recovery and go to normal operations, or allow the recovery to proceed further if you decided this wasn't where you wanted to be yet. However that would require a great deal of mechanism we haven't got (yet). In particular there is no such thing as strict read-only examination of the database. regards, tom lane ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] Proposal for Recover mode in pg_ctl (in 8.0)
Simon Riggs [EMAIL PROTECTED] writes: On Sat, 2004-11-06 at 23:29, Tom Lane wrote: A possibly more reliable interlock would involve having the postmaster probe during normal startup to see if there is already an archived WAL segment for what it thinks is the current segment. Yes, checking the archive is the safe way, but we don't know how to do that unless restore_command has been successfully read in (currently from recovery.conf). Putting it in postgresql.conf is the wrong place, Agreed; we left it out of postgresql.conf for good reasons. I was thinking in terms of adding a third command string, perhaps like test_archive_file = 'test -f /mnt/server/archive/%f' But it's probably best just to tell people to write their archive_commands in a non-overwrite style. regards, tom lane ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] pg_arch.c call to sleep()
Andrew Dunstan [EMAIL PROTECTED] writes: We have the following warning on Windows: pgarch.c:349: warning: implicit declaration of function `sleep' To fix it we could include the right header (which appears to be stdlib.h in the Windows/Mingw case), or we could replace the call by a call to pg_usleep(). stdlib.h is included automatically by c.h, so that surely won't fix it. I have some recollection that we invented pg_usleep in part because we wanted to not use sleep() at all in the backend, but I don't recall why (and the reasoning might not apply to the archiver process, anyway). 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] Memory Context problems...
Katsaros Kwn/nos [EMAIL PROTECTED] writes: More precisely,when I call (my_)SPI_prepare the following message comes exactly at the point where (my_)SPI_end_call(true) is called: WARNING: problem in alloc set my_SPI Exec: detected write past chunk end in block 0x830b7e8, chunk 0x830c058 WARNING: problem in alloc set my_SPI Exec: detected write past chunk end in block 0x8307720, chunk 0x830b6cc Any ideas? I think it is something with the memory contexts but obviously this is not enough to solve the problem. I'd bet on buffer-overrun problems. Check your allocation request sizes against what's actually being used. regards, tom lane ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [HACKERS] pg_arch.c call to sleep()
Tom Lane wrote: Andrew Dunstan [EMAIL PROTECTED] writes: We have the following warning on Windows: pgarch.c:349: warning: implicit declaration of function `sleep' To fix it we could include the right header (which appears to be stdlib.h in the Windows/Mingw case), or we could replace the call by a call to pg_usleep(). stdlib.h is included automatically by c.h, so that surely won't fix it. Now I look closer I see that it declares _sleep() rather than sleep(). I have some recollection that we invented pg_usleep in part because we wanted to not use sleep() at all in the backend, but I don't recall why (and the reasoning might not apply to the archiver process, anyway). I thought we invented pg_usleep so we could remove the calls to select(0,NULL,NULL,NULL,timeout) which don't work on Windows. cheers andrew ---(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] cygwin build failure
Andrew Dunstan wrote: Reini Urban wrote: ... Info: resolving _optarg by linking to __imp__optarg (auto-import) Info: resolving _optind by linking to __imp__optind (auto-import) ok, i'm sure now. there's no way to ignore those diagnostics on the ld side. It's a minor annoyance at worst. Not worth spending effort on. The issue in these lines is the important one: ccache gcc -O2 -Wall -Wmissing-prototypes -Wpointer-arith -Wendif-labels -fno-strict-aliasing -g pg_dump.o common.o pg_dump_sort.o pg_backup_archiver.o pg_backup_db.o pg_backup_custom.o pg_backup_files.o pg_backup_null.o pg_backup_tar.o dumputils.o ../../../src/backend/parser/keywords.o -L../../../src/interfaces/libpq -lpq -L../../../src/port -L/usr/local/lib -lpgport -lz -lreadline -lcrypt -o pg_dump.exe ../../../src/port/libpgport.a(pgstrcasecmp.o)(.text+0x1b0): In function `pg_tolower': /home/adunstan/pgbf/root/HEAD/pgsql.4040/src/port/pgstrcasecmp.c:119: multiple definition of `_pg_tolower' ../../../src/interfaces/libpq/libpq.a(dqgds00145.o)(.text+0x0): first defined here Agreed. What could be the solution? I know it is caused by calling pg_strcasecmp in exec.c. I think I see it now. I added this to pg_dump/Makefile: # Not sure why MinGW needs this but it prevents a link failure # of duplicate definitions for pg_tolower(). 2004-10-06 ifeq ($(PORTNAME), win32) EXTRA_OBJS += $(top_builddir)/src/port/exec.o endif Now, the big question is if you remove this from the Makefile, does Cygwin compile OK, and if not, why does that fail? I am thinking we need to run ranlib on Cygwin to fix this properly. My BSD ranlib manual page has: --- ranlib [-v|-V] archive DESCRIPTION ranlib generates an index to the contents of an archive, and stores it in the archive. The index lists each symbol defined by a member of an archive that is a relocatable object file. An archive with such an index speeds up linking to the li- brary, and allows routines in the library to call each other without regard to their placement in the archive. The GNU ranlib program is another form of GNU ar; running ranlib is completely equivalent to executing `ar -s'. -- 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/docs/faqs/FAQ.html
Re: [HACKERS] pg_arch.c call to sleep()
Tom Lane wrote: Andrew Dunstan [EMAIL PROTECTED] writes: We have the following warning on Windows: pgarch.c:349: warning: implicit declaration of function `sleep' To fix it we could include the right header (which appears to be stdlib.h in the Windows/Mingw case), or we could replace the call by a call to pg_usleep(). stdlib.h is included automatically by c.h, so that surely won't fix it. I have some recollection that we invented pg_usleep in part because we wanted to not use sleep() at all in the backend, but I don't recall why (and the reasoning might not apply to the archiver process, anyway). I think usleep was so we could accept signals during the sleep. -- 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] pg_resetxlog options
Why does pg_resetxlog seem top be the only one of our programs that has no long form options (or at least the only one that calls getopt rather than getopt_long)? Should we make it consistent with everything else? I noticed this when examining a compile warning about implicit declaration of getopt(). cheers andrew ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] Documentation on PITR still scarce
Tom Lane [EMAIL PROTECTED] writes: I suppose it might be useful to have some kind of suspended animation behavior where you could bring up a backend and look at the database in a strict read-only fashion, not really executing transactions at all, just to see what you had. Then you could end the recovery and go to normal operations, or allow the recovery to proceed further if you decided this wasn't where you wanted to be yet. However that would require a great deal of mechanism we haven't got (yet). In particular there is no such thing as strict read-only examination of the database. That would be a great thing to have one day for other reasons aside from the ability to test out a recovered database. It makes warm standby databases much more useful. A warm standby is when you keep a second machine constantly up to date by applying the archived PITR logs as soon as they come off your server. You're ready to switch over at the drop of a hat and don't have to go through the whole recovery process, you just switch the database from recovery mode to active mode and make it your primary database. But in the until then the backup hardware languishes, completely useless. Oracle has had a feature for a long time that you can actually open the standby database in a strict read-only mode and run queries. This is great for a data warehouse situation where you want to run long batch jobs against recent data. -- greg ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [HACKERS] cygwin build failure
I am all wrong on the following. It turns out we need a special linker flag on Cygwin to allow the linker to link to the first available symbol in the library (like Unix), and MinGW has a similar flag that we can use to prevent the pg_dump/Makefile hack on MinGW too! Working on a patch now. --- Bruce Momjian wrote: Andrew Dunstan wrote: Reini Urban wrote: ... Info: resolving _optarg by linking to __imp__optarg (auto-import) Info: resolving _optind by linking to __imp__optind (auto-import) ok, i'm sure now. there's no way to ignore those diagnostics on the ld side. It's a minor annoyance at worst. Not worth spending effort on. The issue in these lines is the important one: ccache gcc -O2 -Wall -Wmissing-prototypes -Wpointer-arith -Wendif-labels -fno-strict-aliasing -g pg_dump.o common.o pg_dump_sort.o pg_backup_archiver.o pg_backup_db.o pg_backup_custom.o pg_backup_files.o pg_backup_null.o pg_backup_tar.o dumputils.o ../../../src/backend/parser/keywords.o -L../../../src/interfaces/libpq -lpq -L../../../src/port -L/usr/local/lib -lpgport -lz -lreadline -lcrypt -o pg_dump.exe ../../../src/port/libpgport.a(pgstrcasecmp.o)(.text+0x1b0): In function `pg_tolower': /home/adunstan/pgbf/root/HEAD/pgsql.4040/src/port/pgstrcasecmp.c:119: multiple definition of `_pg_tolower' ../../../src/interfaces/libpq/libpq.a(dqgds00145.o)(.text+0x0): first defined here Agreed. What could be the solution? I know it is caused by calling pg_strcasecmp in exec.c. I think I see it now. I added this to pg_dump/Makefile: # Not sure why MinGW needs this but it prevents a link failure # of duplicate definitions for pg_tolower(). 2004-10-06 ifeq ($(PORTNAME), win32) EXTRA_OBJS += $(top_builddir)/src/port/exec.o endif Now, the big question is if you remove this from the Makefile, does Cygwin compile OK, and if not, why does that fail? I am thinking we need to run ranlib on Cygwin to fix this properly. My BSD ranlib manual page has: --- ranlib [-v|-V] archive DESCRIPTION ranlib generates an index to the contents of an archive, and stores it in the archive. The index lists each symbol defined by a member of an archive that is a relocatable object file. An archive with such an index speeds up linking to the li- brary, and allows routines in the library to call each other without regard to their placement in the archive. The GNU ranlib program is another form of GNU ar; running ranlib is completely equivalent to executing `ar -s'. -- 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/docs/faqs/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 8: explain analyze is your friend
Re: [HACKERS] pg_resetxlog options
Andrew Dunstan [EMAIL PROTECTED] writes: Why does pg_resetxlog seem top be the only one of our programs that has no long form options (or at least the only one that calls getopt rather than getopt_long)? Should we make it consistent with everything else? I think just laziness on my part when I first wrote it --- it only had one or two options anyway, and didn't seem to need long options. But if converting to getopt_long is the easy way to avoid a porting problem, do it. regards, tom lane ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [HACKERS] Increasing the length of pg_stat_activity.current_query...
Tom Lane [EMAIL PROTECTED] writes: I'd vote in favour of relaxing the limit entirely, as Sean suggests. The choice is not between limit and no limit, it is between limit and broken. What do you think is broken about fragmented UDP packets? Once Upon a Time fragmented UDP packets basically didn't work at all. But that's going on 20 years now. These days you can reliably send large packets up to 32k certainly over local connections and even over long-haul connections when you don't have packet loss problems. Even when you do the worst case scenario is your packet doesn't make it, so what's the harm in at least trying to send it? I'm assuming the packets aren't a fixed size. As long as we aren't bumping up the other packets to 8k then there's no danger to sending the occasional 8k packet. The reason people don't like fragmented UDP packets is that there's no retransmission facility and a packet is lost if a single fragment is lost. So if you're sending an 8k packet with an MTU of 1500 you'll have 5 fragments. With 10% packet loss that gives your 8k fragmented packet a 50/50 chance of getting through. But if you're having 10% packet loss on your local area network you already have a problem. Even then you're losing 10% of your smaller queries and 50% of your larger queries whereas currently you would be losing 10% of your smaller queries and 100% of your larger queries... -- greg ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
[HACKERS] Bittorrent
Hi all, it seems that the tracker is down or at least not reachable. Regards Gaetano Mendola ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] Bittorrent
On Sun, Nov 07, 2004 at 10:53:22PM +0100, Gaetano Mendola wrote: Hi all, it seems that the tracker is down or at least not reachable. Started again. Thanks for the notice. :) BTW, do you have some (semi-)automated way to monitor this? Cheers, D -- David Fetter [EMAIL PROTECTED] http://fetter.org/ phone: +1 510 893 6100 mobile: +1 415 235 3778 Remember to vote! ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] Bittorrent
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 David Fetter wrote: | On Sun, Nov 07, 2004 at 10:53:22PM +0100, Gaetano Mendola wrote: | |Hi all, |it seems that the tracker is down or at least not reachable. | | | Started again. Thanks for the notice. :) Indeed now it's working. | BTW, do you have some (semi-)automated way to monitor this? I do not, today I was developing a sort of bittorrent gateway and in order to test it I was tryng it with the postgres one and I just noticed that the tracker was not responding; however is not that difficult to monitor it from another computer, but I think that the easiest way is to test localy if the tracker is up and running and accepting connections. Regards Gaetano Mendola -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.5 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFBjq3O7UpzwH2SGd4RApndAKCZdOmhGybSYGHaE4ze8efoxnbRuwCg0iiw BqvjqMeC28hUFtpAifec+9g= =Cnln -END PGP SIGNATURE- ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [HACKERS] Increasing the length of
On Sun, 2004-11-07 at 20:59, Greg Stark wrote: Tom Lane [EMAIL PROTECTED] writes: I'd vote in favour of relaxing the limit entirely, as Sean suggests. The choice is not between limit and no limit, it is between limit and broken. What do you think is broken about fragmented UDP packets? ...probably that pgstat.c doesn't handle them at all, so if they occur then you've lost data. Until that is fixed, we have a limit. -- Best Regards, Simon Riggs ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
[HACKERS] Error: set log_error_verbosity to verbose fails
Looks like a minor oversight. rbt=# set log_error_verbosity to terse; SET rbt=# set log_error_verbosity to default; SET rbt=# set log_error_verbosity to verbose; ERROR: syntax error at or near verbose at character 28 LINE 1: set log_error_verbosity to verbose; ^ rbt=# set log_error_verbosity to 'terse'; SET rbt=# set log_error_verbosity to 'verbose'; SET rbt=# set log_error_verbosity to 'verboset'; ERROR: invalid value for parameter log_error_verbosity: verboset ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] UPDATE is not allowed in a non-volatile function
Tom Lane wrote: Gaetano Mendola [EMAIL PROTECTED] writes: The fact that a non-volatile function can not perform update is a good improvement but on the other side will limit too much if I know what I'm doing. I've got zero sympathy for this argument. It's been documented right along that functions with side-effects must be marked volatile. You don't have a lot of room to complain because 8.0 started to enforce that. In practice you can circumvent the restriction by splitting the function in two (ie, there is no check that a nonvolatile function doesn't call any volatile functions). So if you insist on sticking with an unsafe application design, you can do it with relatively localized changes. I do not consider my design as unsafe, this is for example how a cache works: expose a read without side effect but updating internal statistics. After all the read will not alter the data that it expose but other data that the user even don't know the existence. However I think that that missing check is unsafe and jeopardize the effort to avoid a wrong user design. Having say that I'm happy to know that what I did will continue to work splitting the function in two parts. Regards Gaetano Mendola ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
[HACKERS] NoMovementScanDirection
In the context of an index scan, what does NoMovementScanDirection indicate? On the one hand, relation.h comments: * 'indexscandir' is one of: *ForwardScanDirection: forward scan of an ordered index *BackwardScanDirection: backward scan of an ordered index *NoMovementScanDirection: scan of an unordered index, or don't care * (The executor doesn't care whether it gets ForwardScanDirection or * NoMovementScanDirection for an indexscan, but the planner wants to * distinguish ordered from unordered indexes for building pathkeys.) But ExecutorRun() does not invoke ExecutePlan() if the scan direction is NoMovementScanDirection (and IndexNext() derives its scan direction from the scan direction that ExecutePlan() sets in the EState). Are there any situations in which, as the relation.h comment seems to suggest, an index scan will be invoked with NoMovementScanDirection? (I ask because gistscancache() is a no-op unless the index scan is invoked with the NoMovementScanDirection, so it seems of dubious value...) -Neil ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [HACKERS] Error: set log_error_verbosity to verbose fails
Rod Taylor [EMAIL PROTECTED] writes: rbt=# set log_error_verbosity to verbose; ERROR: syntax error at or near verbose at character 28 VERBOSE is a reserved word, unfortunately. regards, tom lane ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
[HACKERS] Contribute to the development of PostgreSQL
Dear Folks, Sometime ago I posted a message regarding learning to develop and contribute to the development of PostgreSQL. I started my journey with downloading the sources and take a look at the bits and pieces of the code. As I was expecting it to be, my journey was and still is ponderous one. I can image the same for other newbies like myself and the fact that some like myself come from a windows development world than *nix. Therefore I was thinking to build a website concerning a how to contribute and develop to PostgreSQL. The idea is to show the following: 1. How to configure the compiler tools for windows and *nix 2. How to make changes, compile and debug 3. Where to start the learning curve in the source code. 4. If requested by any to document the code as I advance. 5. etc.. etc.. I would like to hear your opinion and whether anyone is interested in helping. Regards, Gevik.
Re: [HACKERS] Contribute to the development of PostgreSQL
I suggest that you document your journey as you go, possibly in a blog or something similar, and meanwhile actually get down to contributing. I know from experience that you will find things look very different once you start getting down and dirty with the code. Oncwe you have that all captured, you can go back and put your website together. At least, that's how I'd do it if I had time and it weren't too late :-) cheers andrew Gevik Babakhani wrote: Dear Folks, Sometime ago I posted a message regarding learning to develop and contribute to the development of PostgreSQL. I started my journey with downloading the sources and take a look at the bits and pieces of the code. As I was expecting it to be, my journey was and still is ponderous one. I can image the same for other newbies like myself and the fact that some like myself come from a windows development world than *nix. Therefore I was thinking to build a website concerning a how to contribute and develop to PostgreSQL. The idea is to show the following: 1. How to configure the compiler tools for windows and *nix 2. How to make changes, compile and debug 3. Where to start the learning curve in the source code. 4. If requested by any to document the code as I advance. 5. etc.. etc.. I would like to hear your opinion and whether anyone is interested in helping. Regards, Gevik. ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [HACKERS] CVS should die
Tom, (I'm rather interested to know whether any other SCMs have a better solution to this problem, and if so what it is. It's not obvious how to do better.) I've been working with a few SCM's and IMHO only one of them really handles this really well. That's ClearCase. I'm well aware that ClearCase is not an option but I though it could still be interesting to know how this can be managed when done right. In ClearCase everything (both files and directories) are elements. A directory is a version of an element and it contains versions of other elements. It's not very different from Unix and I-nodes although everything is of course versioned. Subversion claims they handle moves pretty well. When I checked it out, it turns out that a move is a copy (versions and all) followed by a delete, thus maintaining version history at both locations. I'd recommend anyone who think CVS is insufficient due to file moves to investigate subversion. Regards, Thomas Hallgren ---(end of broadcast)--- TIP 8: explain analyze is your friend
[HACKERS] Romanian translation
Hello, I'd like to translate postgres in Romanian, if nobody's doing this already. Thank you, Alin Vaida ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [HACKERS] [PATCHES] CVS should die
Ian Barwick wrote: flat-file based backend ... and the docs mention possible issues with scalability. My impression from being on the Subversion mailing lists: The FSFS backend (flat-file system) scalability issues remain largely theoretical. In practice, it appears to work at least as well as BDB. Some performance issues with having many small files as part of the back-end repository implementation (which FSFS does) are more likely to manifest themselves on some filesystems that have trouble with that condition. Such filesystems seem to mainly exist for Windows. Unix systems seem much more immune to that type of degradation. Heikki Linnakangas wrote: Interestingly, the subversion repository is 585MB, and the CVS repository is only 260MB, BDB or FSFS back-end? FSFS seems to require less space. (The BDB backend tends to pre-allocate space though, so maybe there was a big jump, but then growth will slow markedly, so making a comparison for a repository that will continue to grow is difficult.) If you are interested in some significant-sized projects that are known to use Subversion, some are listed on the testimonials page: http://subversion.tigris.org/propaganda.html I'm just a happy user of both Subversion and PosgreSQL. -Travis ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] Minor TODO list changes
Bruce, Just to chime in. I also agree that fillfactor is useful. I have been investigating different index variants and different fill factors can greatly influence the performance of the index. I also think it may play a key role in minimizing the small table/ many inserts/updates performance problem. --Ken On Thu, Nov 04, 2004 at 11:51:15AM -0500, Bruce Momjian wrote: OK, I updated all your items. I removed fillfactor because I thought I was the only one who thought it was valuable and as I remember it was mostly useful for ISAM, which we don't support. Can you think of a use for a non-100% fillfactor? --- Simon Riggs wrote: A few minor typos/notes: INDEXES 1. On 2nd bullet... The main difficulty with this item is the problem of creating an index that can spam more than one table. should be span, not spam 2. On 6th bullet * Use index to restrict rows returned by multi-key index when used with non-consecutive keys to reduce heap accesses For an index on col1,col2,col3, and a WHERE clause of col1 = 5 and col3 = 9, spin though the index checking for col1 and col3 matches, rather than just col1 This is also known as skip-scanning, so it would be good to use that phrase in the TODO 3. Whatever happened to the FILLFACTOR todo item? AFAICS it disappeared sometime at the beginning of August, but I'm not sure why? REF INTEGRITY ...Didn't we just get rid of deferred triggers?? Perhaps I read that wrong. CACHE 1. 1st bulletprefix it with Use posix_fadvise() API to let OS know how files will be used by PostgreSQL. This would allow, for example, a... (replacing the word add). -- Best Regards, Simon Riggs ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere 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 8: explain analyze is your friend ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] Romanian translation
I'd like to translate postgres in Romanian, if nobody's doing this already. If you like, we'd love it if you translate phpPgAdmin as well :) http://phppgadmin.sf.net/ Chris ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] NoMovementScanDirection
On Mon, 2004-11-08 at 13:56, Tom Lane wrote: However execMain.c uses NoMovementScanDirection to denote do nothing, and so es_direction will never have this value at runtime. Ah, okay. I'll remove gistscancache() then, as this seems to be dead code. Not sure if it's worth factoring the enum type into two (or more?) types to distinguish these shades of meaning. IMHO it would be worth doing. -Neil ---(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] NoMovementScanDirection
Neil Conway [EMAIL PROTECTED] writes: In the context of an index scan, what does NoMovementScanDirection indicate? ScanDirection is used in different ways in different places. The planner uses NoMovementScanDirection to denote an unordered index scan, and this propagates into the indxorderdir field of IndexScan plan nodes, However execMain.c uses NoMovementScanDirection to denote do nothing, and so es_direction will never have this value at runtime. I think pquery.c's use is aligned with the executor but it would take some closer looking to be completely sure. Not sure if it's worth factoring the enum type into two (or more?) types to distinguish these shades of meaning. 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] NoMovementScanDirection
Neil Conway [EMAIL PROTECTED] writes: Ah, okay. I'll remove gistscancache() then, as this seems to be dead code. Certainly none of the other index types have a concept of caching the previous tuple like that. I agree, zap it. 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] Using ALTER TABLESPACE in pg_dump
At 02:37 PM 6/11/2004, Tom Lane wrote: If you have a preliminary patch, you could pass it along and I'll finish it up. Attached. It has some trivial-looking rejects on current CVS. Let me know if you would prefer me to do the work, or want some testing done. It was tested (in terms of output validity) with 8.0b1. Philip Warner| __---_ Albatross Consulting Pty. Ltd. |/ - \ (A.B.N. 75 008 659 498) | /(@) __---_ Tel: (+61) 0500 83 82 81 | _ \ Fax: (+61) 03 5330 3172 | ___ | Http://www.rhyme.com.au |/ \| |---- PGP key available upon request, | / and from pgp.mit.edu:11371 |/ pg_dump_040820_patch_with_funcs.gz Description: Binary data ---(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] Increasing the length of pg_stat_activity.current_query...
Simon Riggs [EMAIL PROTECTED] writes: On Sun, 2004-11-07 at 20:59, Greg Stark wrote: What do you think is broken about fragmented UDP packets? ...probably that pgstat.c doesn't handle them at all, so if they occur then you've lost data. Until that is fixed, we have a limit. Fragmentation happens at the IP protocol level, the kernel is responsible for reassembly. There's nothing for the application level to handle. -- greg ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] cygwin build failure
OK, Andrew found the proper flag so Cygwin and MinGW linking will find the first matching library symbol (like Unix) and not error out because of multiple definitions. I have applied the following patch and removed the pg_dump Makefile hack we had before. --- Bruce Momjian wrote: I am all wrong on the following. It turns out we need a special linker flag on Cygwin to allow the linker to link to the first available symbol in the library (like Unix), and MinGW has a similar flag that we can use to prevent the pg_dump/Makefile hack on MinGW too! Working on a patch now. --- Bruce Momjian wrote: Andrew Dunstan wrote: Reini Urban wrote: ... Info: resolving _optarg by linking to __imp__optarg (auto-import) Info: resolving _optind by linking to __imp__optind (auto-import) ok, i'm sure now. there's no way to ignore those diagnostics on the ld side. It's a minor annoyance at worst. Not worth spending effort on. The issue in these lines is the important one: ccache gcc -O2 -Wall -Wmissing-prototypes -Wpointer-arith -Wendif-labels -fno-strict-aliasing -g pg_dump.o common.o pg_dump_sort.o pg_backup_archiver.o pg_backup_db.o pg_backup_custom.o pg_backup_files.o pg_backup_null.o pg_backup_tar.o dumputils.o ../../../src/backend/parser/keywords.o -L../../../src/interfaces/libpq -lpq -L../../../src/port -L/usr/local/lib -lpgport -lz -lreadline -lcrypt -o pg_dump.exe ../../../src/port/libpgport.a(pgstrcasecmp.o)(.text+0x1b0): In function `pg_tolower': /home/adunstan/pgbf/root/HEAD/pgsql.4040/src/port/pgstrcasecmp.c:119: multiple definition of `_pg_tolower' ../../../src/interfaces/libpq/libpq.a(dqgds00145.o)(.text+0x0): first defined here Agreed. What could be the solution? I know it is caused by calling pg_strcasecmp in exec.c. I think I see it now. I added this to pg_dump/Makefile: # Not sure why MinGW needs this but it prevents a link failure # of duplicate definitions for pg_tolower(). 2004-10-06 ifeq ($(PORTNAME), win32) EXTRA_OBJS += $(top_builddir)/src/port/exec.o endif Now, the big question is if you remove this from the Makefile, does Cygwin compile OK, and if not, why does that fail? I am thinking we need to run ranlib on Cygwin to fix this properly. My BSD ranlib manual page has: --- ranlib [-v|-V] archive DESCRIPTION ranlib generates an index to the contents of an archive, and stores it in the archive. The index lists each symbol defined by a member of an archive that is a relocatable object file. An archive with such an index speeds up linking to the li- brary, and allows routines in the library to call each other without regard to their placement in the archive. The GNU ranlib program is another form of GNU ar; running ranlib is completely equivalent to executing `ar -s'. -- 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/docs/faqs/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 8: explain analyze is your friend -- 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 Index: src/bin/pg_dump/Makefile === RCS file: /cvsroot/pgsql/src/bin/pg_dump/Makefile,v retrieving revision 1.57 diff -c -c -r1.57 Makefile *** src/bin/pg_dump/Makefile7 Oct 2004 13:45:48 - 1.57 --- src/bin/pg_dump/Makefile8 Nov 2004 04:56:52 - *** *** 22,33 EXTRA_OBJS = $(top_builddir)/src/backend/parser/keywords.o - # Not sure why MinGW needs this but it prevents a link failure - # of duplicate definitions for pg_tolower(). 2004-10-06 - ifeq ($(PORTNAME), win32) - EXTRA_OBJS += $(top_builddir)/src/port/exec.o -
Re: [HACKERS] Increasing the length of pg_stat_activity.current_query...
Greg Stark [EMAIL PROTECTED] writes: What do you think is broken about fragmented UDP packets? Fragmentation happens at the IP protocol level, the kernel is responsible for reassembly. There's nothing for the application level to handle. And, by the same token, on platforms where it is broken there is nothing we can do about it. regards, tom lane ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] pgxs under Win32 for PL/Java
Seems you forgot to put a -I before the include directive in src/makefiles/Makefile.win32, i.e. change: Indeed. but in other respects, the patch seems to work fine on win32. I'll test Cygwin next. Ok. Thanks for your test and debug. -- Fabien Coelho - [EMAIL PROTECTED] ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [HACKERS] Romanian translation
On Thu, 4 Nov 2004 11:26:50 +0200, Alin Vaida [EMAIL PROTECTED] wrote: Hello, I'd like to translate postgres in Romanian, if nobody's doing this already. Hello! I have done some translations of the press releases into Romanian before, and I'll translate the upcoming press release, too. I don't plan to translate the po files, so you are certainly welcome to work on them. If you happen to be unsure about translating some of the phrases and you want someone else's opinion, please do not hesitate to contact me. Cheers, Adrian Maier ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [HACKERS] cygwin build failure
Bruce Momjian schrieb: OK, Andrew found the proper flag so Cygwin and MinGW linking will find the first matching library symbol (like Unix) and not error out because of multiple definitions. I have applied the following patch and removed the pg_dump Makefile hack we had before. --- Bruce Momjian wrote: I am all wrong on the following. It turns out we need a special linker flag on Cygwin to allow the linker to link to the first available symbol in the library (like Unix), and MinGW has a similar flag that we can use to prevent the pg_dump/Makefile hack on MinGW too! Working on a patch now. --- Bruce Momjian wrote: Andrew Dunstan wrote: Reini Urban wrote: ... Info: resolving _optarg by linking to __imp__optarg (auto-import) Info: resolving _optind by linking to __imp__optind (auto-import) ok, i'm sure now. there's no way to ignore those diagnostics on the ld side. It's a minor annoyance at worst. Not worth spending effort on. The issue in these lines is the important one: ccache gcc -O2 -Wall -Wmissing-prototypes -Wpointer-arith -Wendif-labels -fno-strict-aliasing -g pg_dump.o common.o pg_dump_sort.o pg_backup_archiver.o pg_backup_db.o pg_backup_custom.o pg_backup_files.o pg_backup_null.o pg_backup_tar.o dumputils.o ../../../src/backend/parser/keywords.o -L../../../src/interfaces/libpq -lpq -L../../../src/port -L/usr/local/lib -lpgport -lz -lreadline -lcrypt -o pg_dump.exe ../../../src/port/libpgport.a(pgstrcasecmp.o)(.text+0x1b0): In function `pg_tolower': /home/adunstan/pgbf/root/HEAD/pgsql.4040/src/port/pgstrcasecmp.c:119: multiple definition of `_pg_tolower' ../../../src/interfaces/libpq/libpq.a(dqgds00145.o)(.text+0x0): first defined here Agreed. What could be the solution? I know it is caused by calling pg_strcasecmp in exec.c. I think I see it now. I added this to pg_dump/Makefile: # Not sure why MinGW needs this but it prevents a link failure # of duplicate definitions for pg_tolower(). 2004-10-06 ifeq ($(PORTNAME), win32) EXTRA_OBJS += $(top_builddir)/src/port/exec.o endif Now, the big question is if you remove this from the Makefile, does Cygwin compile OK, and if not, why does that fail? I am thinking we need to run ranlib on Cygwin to fix this properly. My BSD ranlib manual page has: --- ranlib [-v|-V] archive DESCRIPTION ranlib generates an index to the contents of an archive, and stores it in the archive. The index lists each symbol defined by a member of an archive that is a relocatable object file. An archive with such an index speeds up linking to the li- brary, and allows routines in the library to call each other without regard to their placement in the archive. The GNU ranlib program is another form of GNU ar; running ranlib is completely equivalent to executing `ar -s'. Index: src/bin/pg_dump/Makefile === RCS file: /cvsroot/pgsql/src/bin/pg_dump/Makefile,v retrieving revision 1.57 diff -c -c -r1.57 Makefile *** src/bin/pg_dump/Makefile 7 Oct 2004 13:45:48 - 1.57 --- src/bin/pg_dump/Makefile 8 Nov 2004 04:56:52 - *** *** 22,33 EXTRA_OBJS = $(top_builddir)/src/backend/parser/keywords.o - # Not sure why MinGW needs this but it prevents a link failure - # of duplicate definitions for pg_tolower(). 2004-10-06 - ifeq ($(PORTNAME), win32) - EXTRA_OBJS += $(top_builddir)/src/port/exec.o - endif - all: submake-libpq submake-libpgport submake-backend pg_dump pg_restore pg_dumpall pg_dump: pg_dump.o common.o pg_dump_sort.o $(OBJS) $(libpq_builddir)/libpq.a --- 22,27 Index: src/template/cygwin === RCS file: /cvsroot/pgsql/src/template/cygwin,v retrieving revision 1.4 diff -c -c -r1.4 cygwin *** src/template/cygwin 9 Oct 2003 14:40:36 - 1.4 --- src/template/cygwin 8 Nov 2004 04:56:55 - *** *** 1 --- 1,5 SRCH_LIB=/usr/local/lib + # This is required to link pg_dump because it finds pg_toupper() in + # libpq and pgport + LDFLAGS=-Wl,--allow-multiple-definition + Index: src/template/win32 === RCS file: /cvsroot/pgsql/src/template/win32,v retrieving revision 1.2 diff -c -c -r1.2 win32 *** src/template/win32 9 Oct 2003 03:20:34 - 1.2 --- src/template/win32 8 Nov 2004 04:56:56 - *** *** 0 --- 1,4 + # This is required to link pg_dump because it finds pg_toupper() in + # libpq and pgport + LDFLAGS=-Wl,--allow-multiple-definition + While we are here you could also add
