Gaetano Mendola wrote:
Are you going to fix it for the 8.0 and/or back patch it ?
http://archives.postgresql.org/pgsql-committers/2004-10/msg00229.php
http://archives.postgresql.org/pgsql-committers/2004-10/msg00191.php
plus backpatches to older branches (REL7_3_STABLE, REL7_2_STABLE).
Has there be
Neil Conway <[EMAIL PROTECTED]> writes:
> Has there been any thought about putting out another 7.4 release with
> this fix?
There has, but there are some other open issues I'd like to deal with
first.
If anyone has any pending 7.4 fixes, getting them in in the next
few days would be a Good Plan.
Bruce Momjian <[EMAIL PROTECTED]> writes:
> I think we are getting closer to a final release.
>...
> * synchonize supported encodings and docs
Is this Abhijit's patch to add PQprepare() and PQsendPrepare()?
http://archives.postgresql.org/pgsql-hackers/2004-10/msg00142.php
I'm anxious to see
Tom Lane wrote:
"Magnus Hagander" <[EMAIL PROTECTED]> writes:
I don't have a build env around ATM to test, but my guess would be the
new libpq linking. These functions are probably imported from libpq, and
therefor must be added to the .def file (or rather the .txt file that
generates the .def f
"Matthew T. O'Connor" <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> I have a better idea: make pg_autovacuum not use DLLists. That code
>> is slated for eventual removal from libpq anyway (if not complete
>> destruction). Had I been aware that autovacuum was using it I would
>> have objected .
Greg Stark <[EMAIL PROTECTED]> writes:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
>> * synchonize supported encodings and docs
> Is this Abhijit's patch to add PQprepare() and PQsendPrepare()?
No ... does it look like it?
> I'm not sure whether the patch he sent is adequate, I looked at it
> m
It seems most logical to me to break the fundamental operations into:
1. Prepare to create the compiled query plan
2. Describe to bind the query input/output parameters
3. Execute to produce a result set
Or equivalent functionality. Then, you can bind all three parts into
one operation if you
It seems most logical to me to break the fundamental operations into:
1. Prepare to create the compiled query plan
2. Describe to bind the query input/output parameters
3. Execute to produce a result set
Or equivalent functionality. Then, you can bind all three parts into
one operation if you w
OK, open items updated.
---
Dave Page wrote:
>
>
> > -Original Message-
> > From: [EMAIL PROTECTED]
> > [mailto:[EMAIL PROTECTED] On Behalf Of Bruce Momjian
> > Sent: 16 October 2004 04:39
> > To: PostgreSQL-deve
Sean Chittenden wrote:
> > It seems most logical to me to break the fundamental operations into:
> > 1. Prepare to create the compiled query plan
> > 2. Describe to bind the query input/output parameters
> > 3. Execute to produce a result set
> >
> > Or equivalent functionality. Then, you can b
Tom Lane <[EMAIL PROTECTED]> writes:
> Greg Stark <[EMAIL PROTECTED]> writes:
> > Bruce Momjian <[EMAIL PROTECTED]> writes:
> > > * synchonize supported encodings and docs
>
> > Is this Abhijit's patch to add PQprepare() and PQsendPrepare()?
>
> No ... does it look like it?
Er, oops. I quoted
I wrote:
> Josh Berkus <[EMAIL PROTECTED]> writes:
>> First off, two test runs with OProfile are available at:
>> http://khack.osdl.org/stp/298124/
>> http://khack.osdl.org/stp/298121/
> Hmm. The stuff above 1% in the first of these is
> Counted CPU_CLK_UNHALTED events (clocks processor is not h
Hi again,
Having taken a look at the dblink code I have some questions:
Having a user defined function, is it possible -with no serious memory
overheads- to fork it (outside SPI calls code) in order to make
concurrent dblink calls? What I'm thinking of doing is to create a
function which opens an
Katsaros Kwn/nos wrote:
> Having taken a look at the dblink code I have some questions:
ISTM that you might start with dblink_record() and modify it to suit
using SPI and asynchronous libpq calls. See:
http://www.postgresql.org/docs/current/static/libpq-async.html
Joe
--
I have just started seeing the following on win32:
make[1]: Entering directory
`/home/pgrunner/pgbuildfarm/root/HEAD/pgsql.blurfl/contrib/pg_autovacuum'
gcc -O2 -fno-strict-aliasing -Wall -Wmissing-prototypes
-Wmissing-declarations pg_autovacuum.o -L../../src/interfaces/libpq -lpq
-L../../src/po
15 matches
Mail list logo
