Re: [PATCHES] Minor recovery changes

2007-09-27 Thread Simon Riggs
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 w

Re: [PATCHES] Hash Index Build Patch

2007-09-27 Thread Simon Riggs
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 thou

Re: [PATCHES] Warning is adjusted of pgbench.

2007-09-27 Thread Magnus Hagander
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 t

Re: [PATCHES] Eliminate more detoast copies for packed varlenas

2007-09-27 Thread Brendan Jurd
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 the

Re: [PATCHES] Warning is adjusted of pgbench.

2007-09-27 Thread Tom Lane
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 hap

Re: [PATCHES] Warning is adjusted of pgbench.

2007-09-27 Thread Tom Lane
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

Re: [PATCHES] Eliminate more detoast copies for packed varlenas

2007-09-27 Thread Tom Lane
"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.

Re: [PATCHES] Warning is adjusted of pgbench.

2007-09-27 Thread Hiroshi Saito
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 e

Re: [PATCHES] Warning is adjusted of pgbench.

2007-09-27 Thread Hiroshi Saito
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 t

[PATCHES] Various ecpg cleanup

2007-09-27 Thread ITAGAKI Takahiro
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

[PATCHES] ecpg thead-safe memory management + cleanup

2007-09-27 Thread ITAGAKI Takahiro
Here is a patch to get memory management to thread-safe. The auto_allocs global variable is split into per-thread variables and accessed separately in each thread. This patch is including the previous cleanup patch I sent because I found pthread_once() for Win32 has a bug; it was not thread-safe.