Le 28 mai 06 à 04:08, Andrew Dunstan a écrit :
Tom Lane wrote:
osprey hasn't been able to build HEAD since the GIN code was added.
I'm not sure that GIN is really to blame though, as the error looks
like an out-of-memory problem while trying to link the backend:
ccache gcc -O2 -Wall
On 5/28/06, Martijn van Oosterhout kleptog@svana.org wrote:
With -lpthread
lock.enabled 323s
lock.disabled 50s
lock.unlocked 36s
I forgot to test with -lpthread, my bad. Indeed by default
something less expensive that full locking is going on.
The crux of the matter is though,
Coverity picked up an error in dumpStdStrings() since last night. At
line 1448 there's PQclear(res) yet it's used several times further down
(lines 1452, 1454 and 1456).
I'd actually suggest zeroing out res-tuples in PQclear so this sort of
problem becomes much more obvious.
Coverity bug 304 for
=?ISO-8859-1?Q?R=E9mi_Zara?= [EMAIL PROTECTED] writes:
Tom Lane wrote:
Perhaps the swap space or ulimit setting on the box needs to be
raised?
What kind of ulimit did you think of ?
I'll try upping the data segment size.
Yeah, data segment size would be the most likely culprit if this is a
Martijn van Oosterhout wrote:
Coverity picked up an error in dumpStdStrings() since last night. At
line 1448 there's PQclear(res) yet it's used several times further down
(lines 1452, 1454 and 1456).
I'd actually suggest zeroing out res-tuples in PQclear so this sort of
problem becomes much
Alvaro Herrera [EMAIL PROTECTED] writes:
Martijn van Oosterhout wrote:
I'd actually suggest zeroing out res-tuples in PQclear so this sort of
problem becomes much more obvious.
Is it worthwhile to zero out the res-block array as well?
Your patch isn't doing that, merely zeroing a local
On Sun, May 28, 2006 at 12:00:33PM -0400, Tom Lane wrote:
Another possibility is to just MemSet the whole PGresult struct
to zeroes before free'ing it. Compared to the cost of obtaining
a query result from the backend, this probably doesn't cost enough
to be worth worrying about, and it would
Martijn van Oosterhout kleptog@svana.org writes:
On Sun, May 28, 2006 at 12:00:33PM -0400, Tom Lane wrote:
Another possibility is to just MemSet the whole PGresult struct
to zeroes before free'ing it.
Probably better actually, since by setting ntups to zero also,
PQgetvalue will return a
Tom Lane wrote:
Martijn van Oosterhout kleptog@svana.org writes:
On Sun, May 28, 2006 at 12:00:33PM -0400, Tom Lane wrote:
Another possibility is to just MemSet the whole PGresult struct
to zeroes before free'ing it.
Probably better actually, since by setting ntups to zero also,
Alvaro Herrera wrote:
Tom Lane wrote:
Alvaro Herrera [EMAIL PROTECTED] writes:
Tom Lane wrote:
Hm. But I think we'd *like* it to segfault; the idea is to make the
user's programming error as obvious as possible. Is it worth the
trouble to just zero out the pointer members of the
Alvaro Herrera wrote:
Done. They were actually four, not five. The one I mistakingly though
was one was the notice processor hooks.
The case Martijn was saying would be warned about by the memset
approach, setting ntuples to 0, would actually be handled as a segfault,
because functions
Hi,
I've been having the COPY FROM patch that was posted on pgsql-patches
some time ago (I think from Hannu Krossing), sitting on my machine, with
the intention to commit it for 8.2. However there's something I'm not
very sure about -- the patch creates an execution plan by passing a
literal
anoncvs (svr4, 66.98.251.159) is still slow responding to cvs
update; it's been spotty for about a week now. Tcpdump shows
connections being established but then long delays for ACKs,
sometimes long enough for cvs to time out. Any updates on
what's going on?
Magnus apparently
Hi,
On Sun, 2006-05-28 at 21:25 +0200, Magnus Hagander wrote:
For bittorrent, I propose we take it out. We've suggested it before, I
don't recall receiving any real requests to keep it, and IMHO it's way
much more pain than it's worth. Therefor, unless someone objects, I'll
pull the
Alvaro Herrera [EMAIL PROTECTED] writes:
I've been having the COPY FROM patch that was posted on pgsql-patches
some time ago (I think from Hannu Krossing), sitting on my machine, with
the intention to commit it for 8.2. However there's something I'm not
very sure about -- the patch creates an
I'm trying to setup Kerberos authentication with PG on Windows 2000.
I have installed the MIT Kerberos Windows dlls into the PG bin directory
- replacing the krb5_32.dll and comerr32.dll from the PG install.
I did this because the PG install did not have the krbcc32.dll,
which is needed to find
On Sat, 27 May 2006, Martijn van Oosterhout wrote:
On Sat, May 27, 2006 at 10:57:05AM -0400, Tom Lane wrote:
* Up to now, the only functions directly invoked by an index AM were
members of index opclasses; and since opclasses can only be defined by
superusers, there was at least some basis for
On Sun, May 28, 2006 at 10:43:18PM +0300, Heikki Linnakangas wrote:
I don't know the planner internals, so this might not make any sense at
all, but how about having separate index scan and fetch nodes. Index scan
would return index tuples and fetch would get the corresponding heap
tuples.
Heikki Linnakangas [EMAIL PROTECTED] writes:
On Sat, 27 May 2006, Martijn van Oosterhout wrote:
Actually, for a first pass I was considering doing it within the
nodeIndexScan.c/nodeBitmapScan.c and not within the AM at all. But I
just remembered, the index interface has no way to return the
For bittorrent, I propose we take it out. We've suggested it before, I
don't recall receiving any real requests to keep it, and IMHO it's way
much more pain than it's worth.
We received a couple of requests for the torrent on the IRC channel when
the update was released. Just FYI.
James William Pye [EMAIL PROTECTED] writes:
I guess there are two ways to go about it. Simply remove the
assumption that probin is only relevant to C functions; perhaps
allowing a hardwired exception for builtin languages where allowing
probin to be set would be deemed unsightly (ie, the easy
Hi,
I've been taking a look at what's needed for the non-transactional part
of pg_class. If I've understood this correctly, we need a separate
catalog, which I've dubbed pg_ntclass (better ideas welcome), and a new
pointer in RelationData to hold a pointer to this new catalog for each
relation.
If it were really expensive to derive bytecode from source text
then maybe it'd make sense to do what you're doing, but surely that's
not all that expensive. Everyone else manages to parse prosrc on the
fly and cache the result in memory; why isn't plpython doing that?
It depends on the
Ühel kenal päeval, P, 2006-05-28 kell 13:53, kirjutas Alvaro Herrera:
Hi,
I've been having the COPY FROM patch that was posted on pgsql-patches
some time ago (I think from Hannu Krossing),
Not by/from me :)
--
Hannu Krosing
Database Architect
Skype Technologies OÜ
24 matches
Mail list logo
