Re: [PATCHES] Warning is adjusted of pgbench.
Hi. To be clear: my thought is to put #define FRONTEND 1 into postgres_fe.h and then eliminate ad-hoc definitions of it from a boatload of Makefiles. A quick grep suggests that the only place this wouldn't work too well is src/port/, but that could keep on doing what it's doing. I tried it. and this is patch of test. Then, I still think that consideration is required to a slight degree involving port. However, This fully satisfied the following tests. (regression test is all pass) FreeBSD MinGW(gcc) MS-VC8 What do you think? Regards, Hiroshi Saito FRONTEND_PATCH Description: Binary data ---(end of broadcast)--- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate
Re: [PATCHES] Minor recovery changes
On Wed, 2007-09-26 at 18:38 -0400, Tom Lane wrote: Simon Riggs [EMAIL PROTECTED] writes: As discussed on -hackers and -admin... a few minor changes, rolled into a single patch. I've brought this up to speed with CVS HEAD and applied it. Many thanks. I was not, however, sure what your intention was with the files in test_warm_standby.tar.gz. That's not really intended to go into the contrib module, is it? Not really, especially since its not a portable piece of code. -- Simon Riggs 2ndQuadrant http://www.2ndQuadrant.com ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [PATCHES] Hash Index Build Patch
On Wed, 2007-09-26 at 16:06 -0400, Tom Lane wrote: Tom Raney [EMAIL PROTECTED] writes: Alvaro Herrera wrote: Just wondering, wouldn't it be enough to obtain a tuple count estimate by using reltuples / relpages * RelationGetNumberOfBlocks, like the planner does? We thought of that and the verdict is still out whether it is more costly to scan the entire relation to get the accurate count or use the estimate and hope for the best with the possibility of splits occurring during the build. If we use the estimate and it is completely wrong (with the actual tuple count being much higher) the sort will provide no benefit and it will behave as did the original code. I think this argument is *far* too weak to justify an extra pass over the relation. The planner-style calculation is quite unlikely to give a major underestimate of the rowcount. It might overestimate, eg if the relation is bloated by dead tuples, but an error in that direction won't kill you. Agreed. Given the uncertainty in the hashing, calculating an exact number of rows seems fruitless, whereas we know an extra scan will certainly hurt. It might not show up in tests, but it will on life-size tables. -- Simon Riggs 2ndQuadrant http://www.2ndQuadrant.com ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [PATCHES] Warning is adjusted of pgbench.
On Thu, Sep 27, 2007 at 03:21:59PM +0900, Hiroshi Saito wrote: Hi. To be clear: my thought is to put #define FRONTEND 1 into postgres_fe.h and then eliminate ad-hoc definitions of it from a boatload of Makefiles. A quick grep suggests that the only place this wouldn't work too well is src/port/, but that could keep on doing what it's doing. I tried it. and this is patch of test. Then, I still think that consideration is required to a slight degree involving port. However, This fully satisfied the following tests. (regression test is all pass) FreeBSD MinGW(gcc) MS-VC8 What do you think? I will be offline for most of the time for a couple of days, so it will probably be until early next week before I can look at this. Just a FYI, but I'll be happy to look at it as soon as I can. //Magnus ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [PATCHES] Eliminate more detoast copies for packed varlenas
On 9/22/07, Gregory Stark [EMAIL PROTECTED] wrote: Ok, this removes what should be most if not all of the call sites where we're detoasting text or byteas. In particular it gets all the regexp/like functions and all the trim/pad functions. It also gets hashtext and hash_any. Looks like there's some more of this in src/tutorial/funcs.c and funcs_new.c. On a related note, while I was trawling through header files trying to wrap my head around all this toast and varlena business, I found the following comment, in fmgr.h and reiterated in postgres.h: WARNING: It is only safe to use PG_DETOAST_DATUM_UNPACKED() and VARDATA_ANY() if you really don't care about the alignment. / Shouldn't this be PG_DETOAST_DATUM_PACKED()? I'm emboldened by the fact that there is no macro called PG_TOAST_DATUM_UNPACKED defined anywhere in postgres. Patch attached, in case I've got the right idea. Regards, BJ Index: src/include/fmgr.h === --- src/include/fmgr.h (revision 29144) +++ src/include/fmgr.h (working copy) @@ -158,11 +158,11 @@ * The resulting datum can be accessed using VARSIZE_ANY() and VARDATA_ANY() * (beware of multiple evaluations in those macros!) * - * WARNING: It is only safe to use PG_DETOAST_DATUM_UNPACKED() and - * VARDATA_ANY() if you really don't care about the alignment. Either because - * you're working with something like text where the alignment doesn't matter - * or because you're not going to access its constituent parts and just use - * things like memcpy on it anyways. + * WARNING: It is only safe to use PG_DETOAST_DATUM_PACKED() and VARDATA_ANY() + * if you really don't care about the alignment. Either because you're working + * with something like text where the alignment doesn't matter or because + * you're not going to access its constituent parts and just use things like + * memcpy on it anyways. * * Note: it'd be nice if these could be macros, but I see no way to do that * without evaluating the arguments multiple times, which is NOT acceptable. Index: src/include/postgres.h === --- src/include/postgres.h (revision 29144) +++ src/include/postgres.h (working copy) @@ -237,7 +237,7 @@ * code that specifically wants to work with still-toasted Datums. * * WARNING: It is only safe to use VARDATA_ANY() -- typically with - * PG_DETOAST_DATUM_UNPACKED() -- if you really don't care about the alignment. + * PG_DETOAST_DATUM_PACKED() -- if you really don't care about the alignment. * Either because you're working with something like text where the alignment * doesn't matter or because you're not going to access its constituent parts * and just use things like memcpy on it anyways. ---(end of broadcast)--- TIP 1: 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: [PATCHES] Warning is adjusted of pgbench.
Magnus Hagander [EMAIL PROTECTED] writes: On Thu, Sep 27, 2007 at 03:21:59PM +0900, Hiroshi Saito wrote: What do you think? I will be offline for most of the time for a couple of days, so it will probably be until early next week before I can look at this. Just a FYI, but I'll be happy to look at it as soon as I can. I like the FRONTEND solution, but not the EXEC_BACKEND stuff --- my objection there is that this formulation hard-wires EXEC_BACKEND to get defined only on a WIN32 build, which complicates testing that code on other platforms. (The whole point of the separate EXEC_BACKEND #define was to let non-Windows developers test that code path, remember.) My feeling is that we should continue to have EXEC_BACKEND driven by CPPFLAGS, since that's easily tweaked on all platforms. I'm still not clear on why anything needs to be done with NON_EXEC_STATIC --- AFAICS that symbol is only referenced in half a dozen backend-only .c files, so I think we can just leave it as it stands. In the interests of pushing 8.3beta forward, I'm going to go ahead and commit this patch with the above mods; the buildfarm will let us know if there's anything seriously wrong ... regards, tom lane ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [PATCHES] Warning is adjusted of pgbench.
Magnus Hagander [EMAIL PROTECTED] writes: On Tue, Aug 07, 2007 at 04:58:19PM +0900, Hiroshi Saito wrote: pgbench.c: In function `main': pgbench.c:1257: warning: implicit declaration of function `getopt' adjustment of some reference is required for this. Why do you need to #undef EXEC_BACKEND, and is there a specific reason for removing the include of win32.h? I've applied the attached modified version of this patch; it keeps win32.h in there (correctly re-marked as a system header). I think the fundamental issue must be that Hiroshi's system sets HAVE_GETOPT and HAVE_GETOPT_H. The former causes port.h to not supply a declaration of getopt(), so we'd better include getopt.h to declare it. Together with the changes for FRONTEND applied a little bit ago, I hope that this issue is fully resolved in CVS HEAD. Let me know if there's still a problem. regards, tom lane Index: pgbench.c === RCS file: /cvsroot/pgsql/contrib/pgbench/pgbench.c,v retrieving revision 1.71 retrieving revision 1.72 diff -c -r1.71 -r1.72 *** pgbench.c 25 Aug 2007 09:21:14 - 1.71 --- pgbench.c 27 Sep 2007 20:39:43 - 1.72 *** *** 24,33 #include ctype.h #ifdef WIN32 ! #include win32.h #else #include sys/time.h #include unistd.h #ifdef HAVE_GETOPT_H #include getopt.h --- 24,34 #include ctype.h #ifdef WIN32 ! #include win32.h #else #include sys/time.h #include unistd.h + #endif /* ! WIN32 */ #ifdef HAVE_GETOPT_H #include getopt.h *** *** 40,54 #ifdef HAVE_SYS_RESOURCE_H #include sys/resource.h /* for getrlimit */ #endif - #endif /* ! WIN32 */ extern char *optarg; extern intoptind; - #ifdef WIN32 - #undef select - #endif - / * some configurable parameters */ --- 41,50 ---(end of broadcast)--- TIP 1: 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: [PATCHES] Eliminate more detoast copies for packed varlenas
Brendan Jurd [EMAIL PROTECTED] writes: On 9/22/07, Gregory Stark [EMAIL PROTECTED] wrote: Ok, this removes what should be most if not all of the call sites where we're detoasting text or byteas. In particular it gets all the regexp/like functions and all the trim/pad functions. It also gets hashtext and hash_any. Looks like there's some more of this in src/tutorial/funcs.c and funcs_new.c. Well, those are just tutorial code, so I'd vote for keeping it simple. On a related note, while I was trawling through header files trying to wrap my head around all this toast and varlena business, I found the following comment, in fmgr.h and reiterated in postgres.h: WARNING: It is only safe to use PG_DETOAST_DATUM_UNPACKED() and VARDATA_ANY() if you really don't care about the alignment. Shouldn't this be PG_DETOAST_DATUM_PACKED()? Yup, good catch. In the context of fmgr.h, it seems like the comment is more sensible if it refers to the underlying function pg_detoast_datum_packed (which is what the preceding paragraph is speaking of), so I made it say that instead. regards, tom lane ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [PATCHES] Warning is adjusted of pgbench.
Hi. - Original Message - From: Tom Lane [EMAIL PROTECTED] Magnus Hagander [EMAIL PROTECTED] writes: On Thu, Sep 27, 2007 at 03:21:59PM +0900, Hiroshi Saito wrote: What do you think? I will be offline for most of the time for a couple of days, so it will probably be until early next week before I can look at this. Just a FYI, but I'll be happy to look at it as soon as I can. I like the FRONTEND solution, but not the EXEC_BACKEND stuff --- my objection there is that this formulation hard-wires EXEC_BACKEND to get defined only on a WIN32 build, which complicates testing that code on other platforms. (The whole point of the separate EXEC_BACKEND #define was to let non-Windows developers test that code path, remember.) Ah yes, I also worried that a little change might affect other platforms by the complexity of the action. we memorable it.. My feeling is that we should continue to have EXEC_BACKEND driven by CPPFLAGS, since that's easily tweaked on all platforms. I'm still not clear on why anything needs to be done with NON_EXEC_STATIC --- AFAICS that symbol is only referenced in half a dozen backend-only .c files, so I think we can just leave it as it stands. Although I am attached by the reason it happen the problem in a reference relation by windows, main() which it is called thinks in original that it is good by non static. I look at that non static ..main() fully operates by FreeBSD. Does it influence performance? In the interests of pushing 8.3beta forward, I'm going to go ahead and commit this patch with the above mods; the buildfarm will let us know if there's anything seriously wrong ... Yeah, since it becomes better. thanks! Regards, Hiroshi Saito ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [PATCHES] Warning is adjusted of pgbench.
Hi. From: Tom Lane [EMAIL PROTECTED] Magnus Hagander [EMAIL PROTECTED] writes: On Tue, Aug 07, 2007 at 04:58:19PM +0900, Hiroshi Saito wrote: pgbench.c: In function `main': pgbench.c:1257: warning: implicit declaration of function `getopt' adjustment of some reference is required for this. Why do you need to #undef EXEC_BACKEND, and is there a specific reason for removing the include of win32.h? I've applied the attached modified version of this patch; it keeps win32.h in there (correctly re-marked as a system header). I think the fundamental issue must be that Hiroshi's system sets HAVE_GETOPT and HAVE_GETOPT_H. The former causes port.h to not supply a declaration of getopt(), so we'd better include getopt.h to declare it. Together with the changes for FRONTEND applied a little bit ago, I hope that this issue is fully resolved in CVS HEAD. Let me know if there's still a problem. Yeah, I think that it felt it very refreshed.!:-) Though FRONTEND needs adjustment to consider carefully. Thanks. Regards, Hiroshi Saito ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
[PATCHES] Various ecpg cleanup
Hi, I'd cleaned up some codes in ecpg. * Release all prepared statements on disconnection to avoid memory leaks even if users forget to DEALLOCATE their statements before disconnection. * Remove memset(0) from ECPGalloc() because calloc() has already done it. * Add const to some global variables. * Make pthread_mutex_lock() for Win32 thread-safe. (It might be a paranoia...) * Add more pthread emulation codes for Win32 to reduce #ifdef WIN32. I'll try to fix thread-safe issues in memory management and SQL DESCRIPTOR based on this change. Regards, --- ITAGAKI Takahiro NTT Open Source Software Center ecpg-cleanup.patch Description: Binary data ---(end of broadcast)--- TIP 1: 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
