Re: proposal: additional error fields

From: Peter Geoghegan <peter(at)2ndquadrant(dot)com>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: proposal: additional error fields
Date: 2012-05-01 17:56:13
Message-ID: CAEYLb_U2hRk2g9-Nshoo7kmJeUU0vLm31jxxJtkOyVva-+N+Pg@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 1 May 2012 17:22, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
> Yeah.  I also noticed in my benchmarking that sprintf() seemed to be
> very slow, to the point where I wondered whether we ought to have our
> own minimal version of sprintf() just for error strings.

Which sprintf()? You're probably aware that we already have a memset
replacement, MemSet, and indeed we even have a pg_sprintf(). Without
saying that we shouldn't do that, I'd caution against it. I use glibc
2.14.90, and for example my system's memcpy is implemented with
various optimisation that are only applicable to the architecture of
my system - SSE3 optimisations. A quick google throws up
http://sources.redhat.com/ml/libc-alpha/2010-01/msg00016.html .

Ditto every other architecture (most of these are from a recent
revision of glibc from SCM):

[peter(at)peterlaptop ~]$ locate memcpy.S
/home/peter/glibc/sysdeps/i386/i586/memcpy.S
/home/peter/glibc/sysdeps/i386/i686/memcpy.S
/home/peter/glibc/sysdeps/i386/i686/multiarch/memcpy.S
/home/peter/glibc/sysdeps/ia64/memcpy.S
/home/peter/glibc/sysdeps/powerpc/powerpc32/a2/memcpy.S
/home/peter/glibc/sysdeps/powerpc/powerpc32/cell/memcpy.S
/home/peter/glibc/sysdeps/powerpc/powerpc32/power4/memcpy.S
/home/peter/glibc/sysdeps/powerpc/powerpc32/power6/memcpy.S
/home/peter/glibc/sysdeps/powerpc/powerpc32/power7/memcpy.S
/home/peter/glibc/sysdeps/powerpc/powerpc64/memcpy.S
/home/peter/glibc/sysdeps/powerpc/powerpc64/a2/memcpy.S
/home/peter/glibc/sysdeps/powerpc/powerpc64/cell/memcpy.S
/home/peter/glibc/sysdeps/powerpc/powerpc64/power4/memcpy.S
/home/peter/glibc/sysdeps/powerpc/powerpc64/power6/memcpy.S
/home/peter/glibc/sysdeps/powerpc/powerpc64/power7/memcpy.S
/home/peter/glibc/sysdeps/s390/s390-32/memcpy.S
/home/peter/glibc/sysdeps/s390/s390-64/memcpy.S
/home/peter/glibc/sysdeps/sh/memcpy.S
/home/peter/glibc/sysdeps/sparc/sparc32/memcpy.S
/home/peter/glibc/sysdeps/sparc/sparc32/sparcv9/memcpy.S
/home/peter/glibc/sysdeps/sparc/sparc32/sparcv9/multiarch/memcpy.S
/home/peter/glibc/sysdeps/sparc/sparc64/memcpy.S
/home/peter/glibc/sysdeps/sparc/sparc64/multiarch/memcpy.S
/home/peter/glibc/sysdeps/x86_64/memcpy.S
/home/peter/glibc/sysdeps/x86_64/multiarch/memcpy.S
/home/peter/llvm/projects/compiler-rt/lib/arm/aeabi_memcpy.S
/usr/src/debug/glibc-2.14-394-g8f3b1ff/sysdeps/x86_64/memcpy.S
/usr/src/debug/glibc-2.14-394-g8f3b1ff/sysdeps/x86_64/multiarch/memcpy.S

--
Peter Geoghegan       http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training and Services

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Brian Weaver 2012-05-01 18:09:37 Re: Problem with multi-job pg_restore
Previous Message Tom Lane 2012-05-01 17:44:06 Re: Problem with multi-job pg_restore