Jim Buttafuoco wrote:
> Hackers,
>
> I can confirm that HEAD does not initdb because of a SIGBUS as reported below
> by Martin Pitt @ debian (see his email
> below). My build farm member (corgi) did pass all checks 6 days ago (I was
> having some issues with the build farm
> code before that)
> Andrew Dunstan <[EMAIL PROTECTED]> writes:
> > The attached patch against cvs tip does seem to work. Instead of playing
> > with the environment, we simply allow perl to do its worst and then put
> > things back the way we wanted them.
How does that affect to the API calls you can make from P
kevin brintnall <[EMAIL PROTECTED]> writes:
> I want to work on the following TODO item:
> Allow INET + INT4 to increment the host part of the address, or
> throw an error on overflow.
I think Joachim Wieland is already on that; see yesterday's discussion.
> I plan to add a '+' operat
Hi..
I want to work on the following TODO item:
Allow INET + INT4 to increment the host part of the address, or
throw an error on overflow.
I plan to add a '+' operator to the system catalog. Is there a way to
reserve/request an OID for this purpose? I was thinking about using
I've been running the regression tests with the sinval-reset stress
testing program I posted yesterday:
http://archives.postgresql.org/pgsql-hackers/2006-01/msg00244.php
I've seen several crashes caused by using a tuple descriptor obtained
from lookup_rowtype_tupdesc() after the descriptor has been
First, I cleaned up many of the warnings on my Windows box by running
this to fix up comments in perl's config.h:
sed -i -e 's,\(^/\*.*\)/\*,\1/ *,' config.h
unix2dos config.h
That puts a space between the / and * of what would otherwise be an
embedded comment start, and thus removes
Stefan Kaltenbrunner <[EMAIL PROTECTED]> writes:
> -HEAD does not compile on my SMP i386 OpenBSD-current box (using a plain
> ./configure):
Looks like Peter forgot to test the non-USE_ASSERT_CHECKING case.
I've applied a fix.
regards, tom lane
---(
"Alon Goldshuv" <[EMAIL PROTECTED]> writes:
> The following is a suggestion for optimizing the libpq COPY FROM call for
> better performance. I submitted a similar suggestion awhile ago, but it
> wasn't safe enough. This one is better.
It's not enough better, because it will still deadlock given a
Andrew Dunstan <[EMAIL PROTECTED]> writes:
> I just traced starting up a postmaster, and got over 38000 lines like this:
>stat64("/etc/localtime", {st_mode=S_IFREG|0644, st_size=1267, ...}) = 0
> I assume it comes from the timezone library, but it seems highly
> inefficient. Anyone know why we
Tom Lane wrote:
Andrew Dunstan <[EMAIL PROTECTED]> writes:
The attached patch against cvs tip does seem to work. Instead of playing
with the environment, we simply allow perl to do its worst and then put
things back the way we wanted them.
Doesn't that screw up Perl, though? Its i
Jeremy Drake <[EMAIL PROTECTED]> writes:
> On Sat, 7 Jan 2006, Tom Lane wrote:
>> A bit of a leap in the dark, but: maybe the triggering event for this
>> situation is not a "VACUUM pg_amop" but a global cache reset due to
>> sinval message buffer overrun.
> I tried that function you sent, while r
Andrew Dunstan <[EMAIL PROTECTED]> writes:
> The attached patch against cvs tip does seem to work. Instead of playing
> with the environment, we simply allow perl to do its worst and then put
> things back the way we wanted them.
Doesn't that screw up Perl, though? Its idea of what the locale i
Title: Re: [HACKERS] Libpq COPY optimization
A note on this – we see a huge performance benefit from this change on Solaris, so much so that it should be mandatory for that platform. Solaris’ error handling is deeper, and so the repeated redundant interrupts that this patch avoids causes 60% of
I wrote:
Further testing shows the problem persisting. Back to the drawing board.
The attached patch against cvs tip does seem to work. Instead of playing
with the environment, we simply allow perl to do its worst and then put
things back the way we wanted them.
Comments?
cheers
and
Hannu Krosing <[EMAIL PROTECTED]> writes:
> Interestingly I use pg_stat_activity view to watch for stuck backends,
> "stuck" in the sense that they have not noticed when client want away
> and are now waitin the TCP timeout to happen. I query for backends which
> have been in "" state for longer
I wrote:
#ifdef WIN32
#define WIN32IO_IS_STDIO
#endif
I have added this (without code rearrangement) on the 8.0 and 8.1 stable
branches.
cheers
andrew
---(end of broadcast)---
TIP 5: don't forget to increase your free space map settings
On Fri, Jan 06, 2006 at 06:36:52PM -0500, Greg Stark wrote:
> Josh Berkus writes:
>
> > > These numbers don't make much sense to me. It seems like 5% is about as
> > > slow as reading the whole file which is even worse than I expected. I
> > > thought I was being a bit pessimistic to think readin
Hackers,
I can confirm that HEAD does not initdb because of a SIGBUS as reported below
by Martin Pitt @ debian (see his email
below). My build farm member (corgi) did pass all checks 6 days ago (I was
having some issues with the build farm
code before that). If anyone would like to SSH into
The perl headers on Win32 try to hijack stdio and lots of other stuff
(like getenv). This is annoying, as it generates lots of warnings, and
probably dangerous as well. To inhibit that we would need to set a flag
before the header inclusion, thus:
#ifdef WIN32
#define WIN32IO_IS_STDIO
#endif
> I just traced starting up a postmaster, and got over 38000
> lines like this:
>
>stat64("/etc/localtime", {st_mode=S_IFREG|0644,
> st_size=1267, ...}) = 0
>
> I assume it comes from the timezone library, but it seems
> highly inefficient. Anyone know why we might get this?
Without diggi
The following is a suggestion for optimizing the libpq COPY FROM call for
better performance. I submitted a similar suggestion awhile ago, but it
wasn't safe enough. This one is better. It shows a pretty significant
improvement while maintaining deadlock prevention.
The change is localized to PQpu
I just traced starting up a postmaster, and got over 38000 lines like this:
stat64("/etc/localtime", {st_mode=S_IFREG|0644, st_size=1267, ...}) = 0
I assume it comes from the timezone library, but it seems highly
inefficient. Anyone know why we might get this?
cheers
andrew
-
I wrote:
After some analysis of perl's locale.c, I came up with the attached
patch, which seems to cure the previously observed problem on my
Windows box.
Further testing shows the problem persisting. Back to the drawing board.
cheers
andrew
---(end of broad
Ühel kenal päeval, T, 2006-01-03 kell 09:40, kirjutas Simon Riggs:
> We can also save lots of cycles on the current statement overhead, which
> is currently the worst part of the stats, performance-wise. That
> definitely needs redesign. AFAICS we only ever need to know the SQL
> statement via the
Hi!
-HEAD does not compile on my SMP i386 OpenBSD-current box (using a plain
./configure):
gmake[4]: Leaving directory
`/home/mastermind/source/pgsql/src/backend/utils/mb'
/usr/local/bin/gmake -C misc SUBSYS.o
gmake[4]: Entering directory
`/home/mastermind/source/pgsql/src/backend/utils/mi
sc'
/u
25 matches
Mail list logo