On Fri, 2004-09-24 at 12:30, Neil Conway wrote:
> Barring any objections, I intend to apply the attached patch to HEAD
> later today.
Applied to HEAD.
-Neil
---(end of broadcast)---
TIP 2: you can get off all lists at once with the unregister com
"Casey Allen Shobe" <[EMAIL PROTECTED]> writes:
> When I first log in to psql as a superuser, the first time I try to use
> lo_export (), I get a reference leak warning.
This is fixed post-beta2, I believe.
regards, tom lane
---(end of broadcast)--
This is a test mail
You also need to use -L to specify a location for the log file. By
default pg_autovacuum just logs to STDERR, so if you daemonize the
process (via -D), you won't be able to recover the output easily unless
you explicitly select a log file location.
-tfo
On Sep 22, 2004, at 2:29 AM, Iulia Pacura
Hi!
I run pg_autovacuum:
./pg_autovacuum -D
but then I cannot find pg_autovacuum.log file.
Where shoud I look for it?
Thank you.
---(end of broadcast)---
TIP 2: you can get off all lists at once with the unregister command
(send "unregister YourEm
When I first log in to psql as a superuser, the first time I try to use
lo_export (), I get a reference leak warning. This does not happen on
subsequent attempts. However I can log out and log back in, and see the
error again the first time I execute the query.
Detail follows. Please CC respons
Tom Lane <[EMAIL PROTECTED]> writes:
> Greg Stark <[EMAIL PROTECTED]> writes:
> > Peter Eisentraut <[EMAIL PROTECTED]> writes:
> >> 2) switching the locale at run time is too expensive when using the system
> >> library.
>
> > Fwiw I did some experiments with this and found it wasn't true.
>
> R
>Marc Colosimo wrote:
>
>> Oops, I used the same setting as in the old hacking message (-O2, gcc
>> 3.3). If I understand what you are saying, then it turns out yes, PG's
>> MemSet is faster for smaller blocksizes (see below, between 32 and
>> 64). I just replaced the whole MemSet with memset an
At 2004-09-20 02:16:50 -0400, [EMAIL PROTECTED] wrote:
>
> Personally I find it annoying that you can't call describe on a
> statement, only a portal, but that's the way it is now.
No, it isn't. Describe accepts both prepared statement and portal names.
In the former case, it returns ParameterDesc
I had previously mentioned that queries run much different depending on
whether a VACUUM ANALYZE is done or just a plain ANALYZE. At the time I
was told that that couldn't be and since I could just use the one that
worked better I didn't worry about it. Now I have updated my database
to 7.4 and b
On Fri, 2004-09-24 at 00:35, Tom Lane wrote:
> I would be inclined to get rid of the separate NOPRINTADE code and make
> NOFIXADE select both flags.
Barring any objections, I intend to apply the attached patch to HEAD
later today.
-Neil
Index: src/backend/main/main.c
Oliver Jowett <[EMAIL PROTECTED]> writes:
> Here's a one-line patch that clarifies the Execute protocol docs slightly.
Applied.
regards, tom lane
---(end of broadcast)---
TIP 1: subscribe and unsubscribe commands go to [EMAI
Tom Lane wrote:
Oliver Jowett <[EMAIL PROTECTED]> writes:
Tom Lane wrote:
How can clients distinguish multiple resultsets if they're using the
extended query protocol?
You'll get multiple repetitions of RowDescription/DataRows.
Ah, so the Execute spontaneously generates a RowDescription
spontane
On Thu, Sep 23, 2004 at 11:12:18AM -0700, Josh Berkus wrote:
> A second point, which I brought up with you on IRC, is to eliminate
> overloading and allow named parameter calls on SPs. This is extremely
> useful functionality in T-SQL and PL/SQL; in fact, I'd say that it's
> essential for any
Greg Stark <[EMAIL PROTECTED]> writes:
> Tom Lane <[EMAIL PROTECTED]> writes:
>> however commit that and let the procedure launch its own transactions
>> (compare to VACUUM, db-wide CLUSTER, etc) once we have read the
>> procedure body from the catalogs and done any pre-parsing we want to do.
> We
Tom Lane <[EMAIL PROTECTED]> writes:
> In fact it would more or less have to start in a transaction; keep in
> mind that *we cannot do any database access* outside a transaction,
> and therefore we could not have looked up the procedure in the system
> catalogs in the first place without starting
Greg Stark <[EMAIL PROTECTED]> writes:
> Alvaro Herrera <[EMAIL PROTECTED]> writes:
>> What's needed for this is to isolate the transaction-initiating code
>> from the main query-processing loop. So for CALL statements it wouldn't
>> be invoked, and the procedure would be able to use its own expli
[EMAIL PROTECTED] (Dominic Mitchell) writes:
> On Thu, Sep 23, 2004 at 04:37:52PM -0400, Tom Lane wrote:
>> That last statement is not actually correct, is it? AFAICS we do tell
>> SSL to enforce certificates if we find a valid root.crt file.
> According to the docs[1], you also need
> SSL_VERIFY
Oliver Jowett <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>>> How can clients distinguish multiple resultsets if they're using the
>>> extended query protocol?
>>
>> You'll get multiple repetitions of RowDescription/DataRows.
> Ah, so the Execute spontaneously generates a RowDescription
> spo
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> What's needed for this is to isolate the transaction-initiating code
> from the main query-processing loop. So for CALL statements it wouldn't
> be invoked, and the procedure would be able to use its own explicit
> transaction blocks and savepoints.
Tom Lane wrote:
How can clients distinguish multiple resultsets if they're using the
extended query protocol?
You'll get multiple repetitions of RowDescription/DataRows.
Ah, so the Execute spontaneously generates a RowDescription
spontaneously when it hits the second resultset, without needing an
Oliver Jowett <[EMAIL PROTECTED]> writes:
> The JDBC driver currently sends Describe/Execute and expects exactly one
> of RowDescription/NoData followed by zero or more DataRows followed by
> one of CommandComplete/EmptyQueryResponse/PortalSuspended. This seems
> wrong if there could be multiple
Tom Lane wrote:
regression=# create rule r1 as on insert to surprise do
regression-# ( select 'hello' ; select 'how are you' );
CREATE RULE
The 'hello' result was in fact computed and sent by the backend, but it
was discarded in libpq (see the documentation about PQexec: only the
last resultset re
On Thu, Sep 23, 2004 at 12:40:41PM -0400, Tom Lane wrote:
> What I'd like to see is a "procedure" capability which is somehow
> outside the transaction system and can therefore invoke BEGIN, COMMIT,
> SAVEPOINT, etc. I have no immediate ideas about how to do this, but
> I think that's what people
Folks,
Just noticed -- the hard way -- that running ALTER TABLE ... SET STATISTICS
requires a full table lock.I can't think of any practical reason why SET
STATISTICS would need to lock the table; presumably this is just because it's
an ALTER TABLE statement?If so, maybe we should consi
Gavin, Neil,
> Following is a proposal to implement what SQL2003 calls 'SQL-Invoked
> Procedures' and what most people refer to as stored procedures. Fujitsu
> will be funding Neil Conway and I to work on this feature.
Which, by the way, is way keen.
My comments are based on having professionall
Gavin Sherry <[EMAIL PROTECTED]> writes:
> 3) Procedures can be run in the same savepoint level as the caller when
> OLD SAVEPOINT LEVEL is specified at creation time. According to SQL2003,
> functions must be run on a new savepoint level. From my understanding, we
> do not do this currently.
It's
Fabien COELHO <[EMAIL PROTECTED]> writes:
> Now if you connect to some other server with some other protocol, that is
> another issue...
But the code in question is only for SSL connection to PG, so that's
a red herring I think.
> Also, I do not know how the postgresql protocol interacts
> with S
Andrew Dunstan <[EMAIL PROTECTED]> writes:
> I'm not sure I understand why keeping track of what we need for each
> executable is such a difficult task, though. I count 23 executables and
> a handful of libraries. Is this such a herculean task?
"Handful"? I count 32 AC_CHECK_LIB and AC_SEARCH_
Dear Tom,
> When I wrote that, I was trying to assume as little as possible about
> the SSL protocol. The only way there could be a problem is if the
> server is first to send during the SSL negotiation handshake; which
> seems odd but not impossible. Anyone know for sure?
As for the RFC, the
Gavin Sherry wrote:
Do you have any idea about databases returning result sets from SQL
procedures (ie, not functions).
As other's have pointed out, this is very common in the MS SQL Server
world (and I believe Sysbase also supports it). It works like:
select * from something
...
select * from s
Tom Lane wrote:
Peter Eisentraut <[EMAIL PROTECTED]> writes:
Am Donnerstag, 23. September 2004 13:02 schrieb Thomas Hallgren:
From what I can understand from the documentation, the only utility in
PostgreSQL that actually uses zlib is pg_dump? If so, why is the
postgres process linked with
Hannu Krosing <[EMAIL PROTECTED]> writes:
> IIRC support for returning multiple recordsets was removed from
> postgresql fe-be protocol years ago as "nobody ever needs it" ;)
The protocol can still do it, and so can the backend, but it will
certainly break most if not all clients. Here's an examp
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> Am Donnerstag, 23. September 2004 13:02 schrieb Thomas Hallgren:
>> From what I can understand from the documentation, the only utility in
>> PostgreSQL that actually uses zlib is pg_dump? If so, why is the
>> postgres process linked with -lz?
> Becau
Neil Conway <[EMAIL PROTECTED]> writes:
> Does anyone have any idea what this code is intended to do, and why it
> is necessary?
A bit of googling (I used "SSIN_UACPROC") will turn up enough info to
clue you in. Apparently, on these machines an unaligned memory access
causes a trap to the kernel,
Hannu Krosing <[EMAIL PROTECTED]> writes:
>> One possibility is to forget the direct call to recv() and use
>> pqReadData --- since conn->ssl isn't set yet, and we aren't expecting
>> the server to send more than one byte, this should in theory be safe.
> I was scared by the comment before recv(..
No idea. That code came in at a time when we weren't as good at
documenting platform-specific stuff. (We never expected to be this
popular or to be playing with this code 8 years later.) :-)
I just found this:
http://joshua.raleigh.nc.us/docs/linux-2.4.10_html/87660.html
Want to upda
Peter Eisentraut wrote:
Am Donnerstag, 23. September 2004 13:02 schrieb Thomas Hallgren:
From what I can understand from the documentation, the only utility in
PostgreSQL that actually uses zlib is pg_dump? If so, why is the
postgres process linked with -lz?
Because we are too lazy to fine
Hannu Krosing wrote:
On N, 2004-09-23 at 15:22, Peter Mount wrote:
Hannu Krosing wrote:
On N, 2004-09-23 at 11:34, Grant Finnemore wrote:
Hi Magnus,
Yes, this is the situation that I have been thinking about. Specifically
when a single stored procedure returns many recordsets.
On N, 2004-09-23 at 15:22, Peter Mount wrote:
> Hannu Krosing wrote:
>
> >On N, 2004-09-23 at 11:34, Grant Finnemore wrote:
> >
> >
> >>Hi Magnus,
> >>
> >>Yes, this is the situation that I have been thinking about. Specifically
> >>when a single stored procedure returns many recordsets.
> >>
Hannu Krosing wrote:
On N, 2004-09-23 at 11:34, Grant Finnemore wrote:
Hi Magnus,
Yes, this is the situation that I have been thinking about. Specifically
when a single stored procedure returns many recordsets.
IIRC support for returning multiple recordsets was removed from
postgresql fe-be
Peter Eisentraut wrote:
Because we are too lazy to fine-tune the build system for cases like
this.
The best solution would be to build zlib with symbol versioning.
I'm not so sure. I think zlib is a commodity on most systems. You don't
want to build it at all. Perhaps if I submit a patch that
Am Donnerstag, 23. September 2004 13:02 schrieb Thomas Hallgren:
> From what I can understand from the documentation, the only utility in
> PostgreSQL that actually uses zlib is pg_dump? If so, why is the
> postgres process linked with -lz?
Because we are too lazy to fine-tune the build system fo
Laszlo,
Tom, is there other way in pg 7.4 than backporting PG_TRY? It seems a lot
of work.
I have the needed macros implemented for 7.4 in PL/Java. Look in
src/C/pljava.h.
The exception handling in versions prior to 8.0 is very rudimentary
though. There's (as you already discovered) no way to fi
Problem:
PL/Java use a JVM. On some platforms and with some JVM's (Sun's in
particular) a libzip.so is bundled that contains a 1.1.3 version of
functions also provided in zlib (why they do this is beyond me, but they
do so I'll have to live with it). PostgreSQL is linked with zlib by
default. T
On N, 2004-09-23 at 11:34, Grant Finnemore wrote:
> Hi Magnus,
>
> Yes, this is the situation that I have been thinking about. Specifically
> when a single stored procedure returns many recordsets.
IIRC support for returning multiple recordsets was removed from
postgresql fe-be protocol years ago
On Thu, 23 Sep 2004, Oliver Jowett wrote:
> Gavin Sherry wrote:
>
> > I don't get this multiple ResultSet stuff. All I can think of is that the
> > spec has this in mind:
> >
> > CallableStatement cstmt = conn.prepareCall("{call foo(); call bar();}");
> >
> > or
> >
> > CallableStatement cstmt = c
Hi Magnus,
Yes, this is the situation that I have been thinking about. Specifically
when a single stored procedure returns many recordsets.
Perhaps I should also clarify that the "spec" I have been using is
the JDK javadoc documentation.
Using java with Magnus' procedure:
CallableStatement cs = c
Gavin Sherry wrote:
I don't get this multiple ResultSet stuff. All I can think of is that the
spec has this in mind:
CallableStatement cstmt = conn.prepareCall("{call foo(); call bar();}");
or
CallableStatement cstmt = conn.prepareCall("{call foo()} {call bar();}");
or some other permutation.
It's
On N, 2004-09-23 at 06:41, Tom Lane wrote:
> Hannu Krosing <[EMAIL PROTECTED]> writes:
> > We were bitten by the following bug a few times, when our server tried
> > to reestablish connections under bad network conditions:
> >
> > if connection is closed while trying to get response to SSL setup pa
> > IN parameter values are set using the set methods inherited from
> > PreparedStatement. The type of all OUT parameters must be
> registered
> > prior to executing the stored procedure; their values are retrieved
> > after execution via the get methods provided here.
> >
> > A CallableStatem
On Thu, 23 Sep 2004, Grant Finnemore wrote:
> Quoth the JDBC spec:
>
> public interface CallableStatement
> extends PreparedStatement
>
> The interface used to execute SQL stored procedures. The JDBC API provides a
> stored procedure SQL escape syntax that allows stored procedures to be called
> i
52 matches
Mail list logo
