Re: [PATCHES] [pgsql-patches] Patch to avoid gprof profilingoverwrites

On Thu, 2007-02-01 at 00:59 -0500, Tom Lane wrote: > Is there a way to detect via #if that profiling is enabled? I wouldn't > expect a really portable answer, but maybe there's something that works > for gcc? What about a "--enable-gprof" (or "--enable-profiling"?) configure flag? This could add

Re: [PATCHES] [pgsql-patches] Patch to avoid gprof profilingoverwrites

Mark Kirkwood <[EMAIL PROTECTED]> writes: > Right - but LINUX_PROFILE was added to correct Linux specific oddities > with the time counter accumulation, whereas your patch is not Linux > specific at all. So I think a more representative symbol is required. Yeah, that was my problem with the patc

Re: [PATCHES] [pgsql-patches] Patch to avoid gprof profilingoverwrites

Mark Kirkwood wrote: [EMAIL PROTECTED] wrote: The name for the define variable could perhaps be better - feels silly adding -DLINUX_PROFILE on Freebsd! (maybe just PROFILE or GPROF_PROFILE?). That wasn't my choice, there is other code elsewhere that depends on that symbol, I just added a lit

Re: [PATCHES] [pgsql-patches] Patch to avoid gprof profilingoverwrites

[EMAIL PROTECTED] wrote: The name for the define variable could perhaps be better - feels silly adding -DLINUX_PROFILE on Freebsd! (maybe just PROFILE or GPROF_PROFILE?). That wasn't my choice, there is other code elsewhere that depends on that symbol, I just added a little bit more. Right

[PATCHES] Re: [HACKERS] Typo in pg_dump documentation and new suggestion for Release Notes

Sorry we forgot the list this incompatibility in the 8.2.0 release notes. I have applied the attached patch to list this item in the 8.2.0 documentation section. This will appear in the next 8.2.X release. --- Mike G wrote

Re: [PATCHES] [pgsql-patches] pg_dump missing arguments in docs

On Mon, 2007-01-29 at 13:58 +0100, Magnus Hagander wrote: > This patch adds documentation for the long-version parameters --username > and --password for pg_dump, pg_dumpall and pg_restore, per complaint by > Michael Schmidt. Applied, thanks for the patch. -Neil ---(end

Re: [PATCHES] Docs improvements

Your patch has been added to the PostgreSQL unapplied patches list at: http://momjian.postgresql.org/cgi-bin/pgpatches It will be applied as soon as one of the PostgreSQL committers reviews and approves it. --- Te

Re: [PATCHES] [pgsql-patches] Patch to avoid gprof profilingoverwrites

> Nice addition - tested on FreeBSD 6.2, works great! Cool - thanks for the quick feedback. > The name for the define variable could perhaps be better - feels silly > adding -DLINUX_PROFILE on Freebsd! (maybe just PROFILE or GPROF_PROFILE?). That wasn't my choice, there is other code elsewh

Re: [PATCHES] [pgsql-patches] Phantom Command IDs, updated patch

Your patch has been added to the PostgreSQL unapplied patches list at: http://momjian.postgresql.org/cgi-bin/pgpatches It will be applied as soon as one of the PostgreSQL committers reviews and approves it. --- He

Re: [pgsql-patches] [PATCHES] [HACKERS] [Fwd: Index Advisor]

Your patch has been added to the PostgreSQL unapplied patches list at: http://momjian.postgresql.org/cgi-bin/pgpatches It will be applied as soon as one of the PostgreSQL committers reviews and approves it. --- Gu

[PATCHES] Re: [pgsql-patches] Recalculating OldestXmin in a long-running vacuum

Have you gotten performance numbers on this yet? --- Gregory Stark wrote: > Heikki Linnakangas <[EMAIL PROTECTED]> writes: > > > Tom Lane wrote: > > > > > In any case I'd like to see some evidence of significant real-world

[PATCHES] Full page writes improvement

Here's an idea and a patch for full page writes improvement. Idea: (1) keep full page writes for ordinary WAL, make them available during the crash recovery, -> recovery from inconsistent pages which can be made at the crash, (2) Remove them from the archive log except for those written during onl

Re: [PATCHES] [pgsql-patches] Patch to avoid gprof profiling overwrites

[EMAIL PROTECTED] wrote: And the patch is where? You caught me; guess I'd better make something up fast, huh? Here it is, thanks. -- Korry --- [EMAIL PROTECTED] wrote: > It's dif

Re: [pgsql-patches] Patch to avoid gprof profiling overwrites

> And the patch is where? You caught me; guess I'd better make something up fast, huh? Here it is, thanks. -- Korry > > --- > > [EMAIL PROTECTED] wrote: > > It's difficult to profile a backend server process

[pgsql-patches] Patch to avoid gprof profiling overwrites

It's difficult to profile a backend server process (using gprof) because each process overwrites any earlier profile as it exits. It is especially tricky to nab a useful profile if you happen to have autovacuum enabled. This patch reduces the problem by forcing the backend to 'cd' to a new direc

Re: [pgsql-patches] uuid patch 3.0 (8.3devel)

On Wed, 2007-01-31 at 12:14 -0500, Tom Lane wrote: > Is anything happening with that? This code fails regression on my > primary development machine, and my annoyance level is rising rapidly. > I'll probably remove the uuid test from the schedule files as a > band-aid, if no fix is forthcoming soo

Re: [pgsql-patches] uuid patch 3.0 (8.3devel)

Neil Conway <[EMAIL PROTECTED]> writes: > On Sun, 2007-01-28 at 13:08 -0500, Kris Jurka wrote: >> This fails on Solaris 9 buildfarm members kudu and dragonfly because they >> do not support the "hh" scanf modifier using in UUID_FMTx. > Hmmm. I suppose the easiest thing to do would be to rewrite t

Re: [pgsql-patches] [HACKERS] pgsql: Fix for plpython functions; return true/false for boolean,

Tino Wildenhain <[EMAIL PROTECTED]> writes: > Bruce Momjian schrieb: >> I thought about suggesting that, but do we want plpython to have >> different result behavior based on the version of python used? I didn't >> think so. > Why not? Indeed --- the underlying language changed, so I should thin

[pgsql-patches] Re: [HACKERS] pgsql: Fix for plpython functions; return true/false for boolean,

Tino Wildenhain wrote: > Bruce Momjian schrieb: > > Hannu Krosing wrote: > >> Officially by who ? > >> > >> 2.3 was the first version to introduce bool as a subtype of int, in > >> 2.2.3 True and False were introduced as two variables pointing to > >> integers 1 and 0. > >> > >> So to make your pat

[pgsql-patches] Re: [HACKERS] pgsql: Fix for plpython functions; return true/false for boolean,

Bruce Momjian schrieb: Hannu Krosing wrote: Officially by who ? 2.3 was the first version to introduce bool as a subtype of int, in 2.2.3 True and False were introduced as two variables pointing to integers 1 and 0. So to make your patch ok on all python versions, just make it conditional on p

Re: [pgsql-patches] [HACKERS] pgsql: Fix for plpython functions; return true/false for boolean,

Bruce Momjian wrote: > Hannu Krosing wrote: > > Officially by who ? > > > > 2.3 was the first version to introduce bool as a subtype of int, in > > 2.2.3 True and False were introduced as two variables pointing to > > integers 1 and 0. > > > > So to make your patch ok on all python versions, just

[pgsql-patches] Re: [HACKERS] pgsql: Fix for plpython functions; return true/false for boolean,

Hannu Krosing wrote: > Officially by who ? > > 2.3 was the first version to introduce bool as a subtype of int, in > 2.2.3 True and False were introduced as two variables pointing to > integers 1 and 0. > > So to make your patch ok on all python versions, just make it > conditional on python vers

[pgsql-patches] Re: [HACKERS] pgsql: Fix for plpython functions; return true/false for boolean,

Ühel kenal päeval, T, 2007-01-30 kell 14:52, kirjutas Guido Goldstein: > I've checked the patch with postgres 8.1.3 and 8.2.1 > with python 2.4 and 2.5 on intel 32 bit and amd 64 bit > systems; all systems running linux. > > *And* it's not a feature patch but a bug-fixing one! > Python is a langu