Re: [HACKERS] cvsignore
Dennis Bjorklund wrote: Would it be okay if I add some .cvsignore files to cvs? So we don't need to get rows like ? po/tr.mo ? po/zh_CN.mo ? po/zh_TW.mo ? utils/mb/conversion_procs/euc_jp_and_sjis/libeuc_jp_and_sjis.so.0.0 ? utils/mb/conversion_procs/euc_kr_and_mic/libeuc_kr_and_mic.so.0.0 ? utils/mb/conversion_procs/euc_tw_and_big5/libeuc_tw_and_big5.so.0.0 when we do cvs diff. I order to achieve that you would have to add *all* built files to cvsignore. Surely you don't plan that? ---(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] cvsignore
Dennis Bjorklund wrote: One advantage of this is that you can do cvs diff foo.patch and get a patch file without a lot of garbage. Maybe you would be happier if you build outside the source tree. Do cd .. mkdir pgbuild cd pgbuild ../pgsql/configure --prefix... make make install Then to make a diff, go back cd ../pgsql cvs diff and you won't have any built files in your way. ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [HACKERS] cvsignore
On Sat, 24 Jan 2004, Peter Eisentraut wrote: Dennis Bjorklund wrote: One advantage of this is that you can do cvs diff foo.patch and get a patch file without a lot of garbage. Maybe you would be happier if you build outside the source tree. Do Sure, one can do that. Still, if it doesn't bother anyone and it does help me, then I don't see why not. I just noticed that there already are some .cvsignore files in the cvs tree. -- /Dennis Björklund ---(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] What's planned for 7.5?
-COMMENT ON [ CAST | CONVERSION | OPERATOR CLASS | LARGE OBJECT | LANGUAGE ] (Christopher) Hey Bruce, You probably should add 'Dump LOB comments in custom dump format' to the todo. That's the last part of that task above which I haven't done yet, and for various reasons probably won't have time to try for a while. Just so we don't forget it. Chris ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [HACKERS] [pgsql-advocacy] PostgreSQL installation CD based on Morphix
On Sat, 24 Jan 2004, Robert Bernier wrote: I recompiled the kernel to get the 'elephant' (does it have a name??) Slonik ... Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email: [EMAIL PROTECTED] Yahoo!: yscrappy ICQ: 7615664 ---(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] Disaster!
Gavin Sherry [EMAIL PROTECTED] writes: It seems that by adding the following to SlruPhysicalReadPage() we can recover in a reasonable way here. Instead of: [ add non-error check to lseek() ] But it's not the lseek() that's gonna fail. What we'll actually see, and did see in Chris' report, is a read() that returns zero bytes, or possibly an incomplete page. So actually this change is needed in the next step, not the lseek. BUT: after looking at the code more, I'm confused again about exactly how Chris' failure happened. The backtrace he sent this morning shows that the panic occurs while replaying a transaction-commit WAL entry --- it's trying to set the commit status bit for that transaction number, and finding that the clog page containing that bit doesn't exist. But there should have been a previous WAL entry recording the ZeroCLOGPage() action for that clog page. The only way that wouldn't have got replayed too is if there was a checkpoint in between ... but a checkpoint should not have been able to complete without flushing the clog buffer to disk. If there wasn't disk space enough to hold the clog page, the checkpoint attempt should have failed. So it may be that allowing a short read in slru.c would be patching the symptom of a bug that is really elsewhere. We need to understand the sequence of events in more detail. Chris, you said you'd saved a copy of the data directory at the time of the failure, right? Could you send me the pg_control file and the active segments of pg_xlog? (It should be sufficient to send the ones with file mod times within five minutes of the crash.) regards, tom lane ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [HACKERS] cvsignore
Dennis Bjorklund wrote: Still, if it doesn't bother anyone and it does help me, then I don't see why not. Well, I think a lot of people would be bothered by the idea of you maintaining a copy of what will amount to a list of all files. Even more people will be bothered by the idea that they would have to help maintaining it if they add or remove files. I just noticed that there already are some .cvsignore files in the cvs tree. The files listed in those files have to be built in the source tree for various reasons even if you configure a separate build directory. So the .cvsignore files serve to get clean cvs diffs if you use a separate build directory. ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: vpath build (was Re: [HACKERS] cvsignore)
Alvaro Herrera [EMAIL PROTECTED] writes: I am currently building outside the source tree so that I don't have these problems. It works fine, except that some files are created in the source tree anyway. I think it's mostly output from bison and flex: That's intentional, although it might not be necessary to do it that way (when building a distribution tarball, we do or can build within the source tree). One advantage of doing it like this in a vpath build is that those files are the same across all architectures and so you don't need to build them again for each one ... but of course, if you're not using vpath to handle multiple architecture builds then you don't care. Personally I don't use vpath much and don't really care if we change that behavior --- any other opinions out there? Also, the regression tests can be run fine with make installcheck, but if I want to run the parallel schedule, I have to point pg_regress to the source dir. Maybe the file could be copied to the build dir ... That's an oversight, surely; but ISTM it worked last time I tried it. regards, tom lane ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: vpath build (was Re: [HACKERS] cvsignore)
On Sat, Jan 24, 2004 at 02:46:06PM -0500, Tom Lane wrote: Alvaro Herrera [EMAIL PROTECTED] writes: I am currently building outside the source tree so that I don't have these problems. It works fine, except that some files are created in the source tree anyway. I think it's mostly output from bison and flex: [...] Personally I don't use vpath much and don't really care if we change that behavior --- any other opinions out there? Maybe I just need to teach diff how to use the .cvsignore files. Also, the regression tests can be run fine with make installcheck, but if I want to run the parallel schedule, I have to point pg_regress to the source dir. Maybe the file could be copied to the build dir ... That's an oversight, surely; but ISTM it worked last time I tried it. Checking the makefile, I see that make installcheck uses the serial schedule, while make check uses the parallel one. Is this intentional? I see this dates to the time those rules were invented, GNUmakefile 1.24 ... Maybe there should be rules to do a install-parallel and install-serial, and others to do temp-install-parallel and temp-install-serial ... or maybe just use some envvar to select the schedule to use. -- Alvaro Herrera (alvherre[a]dcc.uchile.cl) I personally became interested in Linux while I was dating an English major who wouldn't know an operating system if it walked up and bit him. (Val Henson) ---(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] Disaster!
Christopher Kings-Lynne [EMAIL PROTECTED] writes: FreeBSD 4.7/4.9 and the UFS filesystem Hm, okay, I'm pretty sure that that combination wouldn't report ENOSPC at close(). We need to fix the code to check close's return value, probably, but it seems we still lack a clear explanation of what happened to your database. That request to look at your WAL files is still open ... 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] [patch] jdbc build fix when ./configure is run in separate
[EMAIL PROTECTED] wrote: When ./configure is run outside the source directory (to keep the build files separate from the source files), make fails for the jdbc target because ant is not informed of the configure/build directory location. This patch fixes this, but could you please review it for portability, etc. For example, I am not sure that `pwd` is the best way to find the configure/build dir. JDBC is moving to gborg for 7.5 so this patch isn't required. -- 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] Getting the results columns before execution
Tom Lane wrote: Shachar Shemesh [EMAIL PROTECTED] writes: Tom Lane wrote: Sure it is, if you are using the V3 protocol (new in 7.4). See the Describe message types. Are those exposed through the libpq interface? No, because libpq doesn't really have any concept of prepared statements. It would probably make sense to add some more API to libpq to allow creation and interrogation of prepared statements, but no one's got around to that yet. Uh, if libpq doesn't know about it, how is that information accessed? -- 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]
[HACKERS] compile failure on xmalloc()
I am seeing the following compile failure in currrent CVS. Seems there is a conflict between readline and psql's use of the xmalloc function name. --- gcc -O2 -fno-strict-aliasing -Wall -Wmissing-prototypes -Wmissing-declarations -O1 -Wall -Wmissing-prototypes -Wmissing-declarations -Wpointer-arith -Wcast-align command.o common.o help.o input.o stringutils.o mainloop.o copy.o startup.o prompt.o variables.o large_obj.o print.o describe.o tab-complete.o mbprint.o -L../../../src/interfaces/libpq -lpq -L../../../src/port -L/usr/local/lib -L/usr/contrib/lib -Wl,-rpath,/usr/local/pgsql/lib -O1 -Wall -Wmissing-prototypes -Wmissing-declarations -Wpointer-arith -Wcast-align -lssl -lcrypto -lz -lreadline -ltermcap -lgetopt -lcompat -lipc -ldl -lm -lutil -lpgport -o psql /usr/local/lib/libreadline.a(xmalloc.o): In function `xmalloc': /u/src/lib/readline/readline-2.2.1/xmalloc.c:51: multiple definition of `xmalloc' common.o(.text+0x5c): first defined here ld: Warning: size of symbol `xmalloc' changed from 54 to 47 in xmalloc.o --- It seems it is from these commits: --- revision 1.82 date: 2004/01/25 03:07:22; author: neilc; state: Exp; lines: +7 -8 More fallout from the recent psql patch: rename xmalloc and friends to pg_malloc, to avoid linker failures on same platforms. revision 1.81 date: 2004/01/24 19:38:49; author: neilc; state: Exp; lines: +39 -7 This patch makes some of the memory manipulation performed by psql a little more sane. Some parts of the code was using a static function xmalloc() that did safe memory allocation (where safe means bail out on OOM), but most of it was just invoking calloc() or malloc() directly. Now almost everything invokes xmalloc() or xcalloc(). -- 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] Regarding development and the submittal of patches
Bill Moran wrote: Hey all, I hope this isn't off-topic or inapropriate to this list ... I'm not familiar with the PostgreSQL patch-submittal/development cycle. I recently submitted a patch regarding \copy syntax in psql, and I'd like to keep an eye on it to see that it gets comitted, or respond if there are concerns that would prevent it from being comitted. I sent the patch to [EMAIL PROTECTED] two days ago, and have heard nothing in reply. Is this typical lag? Is there anywhere I can monitor whether this patch is being reviewed or not? Is there anything else _I_ should do to assist the comitter? Direct suggestions, or links to information would be equally welcome. I was away during the past week. I will review it and get it into the patches queue. -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] Disaster!
Tom Lane [EMAIL PROTECTED] writes: Christopher Kings-Lynne [EMAIL PROTECTED] writes: FreeBSD 4.7/4.9 and the UFS filesystem Hm, okay, I'm pretty sure that that combination wouldn't report ENOSPC at close(). We need to fix the code to check close's return value, probably, but it seems we still lack a clear explanation of what happened to your database. The traditional Unix filesystems certainly don't return errors at close. Even NFS doesn't traditionally do so. I think NFSv3 can if the server disappears after the client obtains a lease on a piece of the file, but I'm not sure if ENOSPC is a possible failure mode. I do know that AFS returns quota failures on close. This was unusual enough that when AFS was deployed at school unix tools failed left and right over precisely this issue. Though it mostly just meant they returned the wrong exit status. -- greg ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Disaster!
That request to look at your WAL files is still open ... I've sent you it privately - let me know how it goes. Chris ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
