On Sat, May 27, 2006 at 11:52:40AM -0400, Tom Lane wrote:
> Martijn van Oosterhout writes:
> > How about the suggestion of using a sequential index scan like the
> > recent changes to VACUUM in the case that there are no regular index
> > quals?
>
> Nonstarter (hint: the solution we found for VAC
Marko Kreen wrote:
On 5/28/06, Martijn van Oosterhout 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,
Ü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Ü
Aka
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 numb
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.
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
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.
Therefor
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 retur
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
> tuple
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 03:59:44PM -0400, Tom Lane wrote:
> 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. Howe
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 t
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 creat
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 bitto
> >> 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?
> >
> > Ma
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 "SEL
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 functi
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 point
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 PGresult?
>
> >
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 PGresult?
> There are only five of them;
Tom Lane wrote:
> Martijn van Oosterhout 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,
> > PQgetvalu
Martijn van Oosterhout 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 warning (row n
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 wo
On Sun, May 28, 2006 at 11:42:48AM -0400, Alvaro Herrera wrote:
> 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?
Patch is good, but sett
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 lo
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 become
=?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
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
On 5/28/06, Martijn van Oosterhout 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, if you're calling s
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 -Wmissi
30 matches
Mail list logo
