Re: [PATCHES] Exec statement logging

Tom Lane wrote: > Bruce Momjian writes: > > One thing you did was to log debug_query_string, but I don't see how > > that could be the right value. I assume it would be empty in a > > client-side execute, or be the previous query. I instead used "EXECUTE > > portal_name" because that is what we

[PATCHES] [Fwd: Re: [HACKERS] alternate regression dbs?]

Darn ... previously sent to wrong list Tom Lane wrote: Andrew Dunstan <[EMAIL PROTECTED]> writes: Currently the pg_regress script does "dbname=regression" and then does everything in terms of $dbname. Would there be any value in providing a --dbname=foo parameter so that different regression

Re: [PATCHES] [GENERAL] pgsql config flag update: apple rendezvous renamed bonjour

OpenMacNews wrote: > hi all, > > fyi: > > "Apple's Rendezvous renamed 'Bonjour'" > > > > since it's now official, might it be time to add a conditional for: > > --with-rendezvous || --with-bonjour

Re: [PATCHES] Exec statement logging

Bruce Momjian writes: > One thing you did was to log debug_query_string, but I don't see how > that could be the right value. I assume it would be empty in a > client-side execute, or be the previous query. I instead used "EXECUTE > portal_name" because that is what we are passed from the client

Re: [HACKERS] [PATCHES] plperl and pltcl installcheck targets

Tom Lane wrote: Andrew Dunstan <[EMAIL PROTECTED]> writes: I agree. That will also mean that buildfarm members will automatically start doing the checks (as long as they are set up to build the PLs), so it would be an extra bonus for me :-) The only argument I can think of against it is

Re: [PATCHES] Exec statement logging

Simon Riggs wrote: > Following patch is a minor addition to postgres.c that allows the two > existing statement logging techniques to work with V3 exec. This then > allows statement logging with PostgreSQL 8.0+ for JDBC and other V3 > connection types. > > The rationale of this patch is to add fun

Re: [HACKERS] [PATCHES] plperl and pltcl installcheck targets

Andrew Dunstan <[EMAIL PROTECTED]> writes: > I agree. That will also mean that buildfarm members will automatically > start doing the checks (as long as they are set up to build the PLs), so > it would be an extra bonus for me :-) The only argument I can think of against it is that the buildfarm

Re: [HACKERS] [PATCHES] plperl and pltcl installcheck targets

Peter Eisentraut wrote: Tom Lane wrote: It occurs to me that maybe we should just add src/pl to the toplevel installcheck target, which would make the whole thing pretty automatic. However, contrib isn't in that target, so maybe the PLs shouldn't be either. Thoughts? Contrib isn't built

Re: [HACKERS] [PATCHES] plperl and pltcl installcheck targets

Tom Lane wrote: > It occurs to me that maybe we should just add src/pl to the toplevel > installcheck target, which would make the whole thing pretty > automatic. However, contrib isn't in that target, so maybe the PLs > shouldn't be either. Thoughts? Contrib isn't built by default, so it isn't

Re: [HACKERS] [PATCHES] plperl and pltcl installcheck targets

Andrew Dunstan <[EMAIL PROTECTED]> writes: > OK, here's what I have. The tgz file contains the sql and expected > directories for the 3 PLs, plus there's a patch for the makefiles. Applied with minor editorialization to make it more like the contrib installcheck process. I added a "make installc

[Fwd: Re: [HACKERS] [PATCHES] plperl and pltcl installcheck targets]

I don't know what heppened to the original of this. Maybe it caught by some filter because of the .tgz file. So instead of including it again I have uploaded it to planetpostgresql. It can be got here: |http://people.planetpostgresql.org/andrew/wp-content/plregress.tgz cheers andrew | -

Re: [PATCHES] AllocSetReset improvement

a_ogawa <[EMAIL PROTECTED]> writes: > It is a reasonable idea. However, the majority part of MemSet was not > able to be avoided by this idea. Because the per-tuple contexts are used > at the early stage of executor. Drat. Well, what about changing that? We could introduce additional contexts or

Re: [PATCHES] AllocSetReset improvement

(BTom Lane <[EMAIL PROTECTED]> writes: (B> >> And I'm worried about adding even a small amount of overhead to (B> >> palloc/pfree --- on the vast majority of the profiles I look at, those (B> >> are more expensive than AllocSetReset. (B> (B> > I don't worry about palloc. Because overhead inc