Looking at your query, I notice that the longer query happens when you
search on b.zcustnum=30538 while the LEFT OUTER JOIN remains the same.
It could be that when testing a.zcustnum=30530 the server can short
circuit the logic - it only has to check a.zcustnum to see if the
entire tuple
Hi All,
I'm wonder if there is any possibility to kick out automatically stuck in
queries after say 10 minutes or so?
I mean some kind of queries which calls eg. buggy functions with dead loops
or something similar.
Time to time I face such kind of problems which are solved automatically
after
DECLARE
groups integer[];
tmp RECORD;
tmpi integer;
BEGIN
FOR tmp IN SELECT i_group_id FROM l_group_to_user WHERE i_user_id =
$1 LOOP
SELECT i_group_id INTO tmpi FROM s_group WHERE i_group_id =
tmp.i_group_id;
groups[] := tmpi;
RETURN NEXT tmp.i_group_id;
END LOOP;
RETURN
On Mon, 2 Feb 2004, [iso-8859-2] Együd Csaba wrote:
Hi All,
I'm wonder if there is any possibility to kick out automatically stuck in
queries after say 10 minutes or so?
I mean some kind of queries which calls eg. buggy functions with dead loops
or something similar.
Time to time I face
Ahh! Thanks Kris! That works!
-- Csaba
-Original Message-
From: Kris Jurka [mailto:[EMAIL PROTECTED]
Sent: 2004. februr 2. 10:14
To: Egyd Csaba
Cc: [EMAIL PROTECTED] (E-mail)
Subject: Re: [GENERAL] How to kick out automatically stuck in queries
On Mon, 2 Feb 2004, [iso-8859-2]
Merrall, Graeme wrote:
I don't think there's an easy way to do this but I thought I better ask just in case. I'm trying to come up with a way to search across a number of databases without resorting to lots of horrible scripts. In one database I have a lot of news stories from our news provider
Kris, thanks for you feedback. Can you give me any further info on the
questions below?
Kris Jurka said:
3) If I want accented characters to sort correctly, must I select
UNICODE
(or the appropriate ISO 8859 char set) over SQL_ASCII?
You are confusing encoding with locale. Locales
On Mon, 2 Feb 2004, John Sidney-Woollett wrote:
Kris, thanks for you feedback. Can you give me any further info on the
questions below?
Kris Jurka said:
3) If I want accented characters to sort correctly, must I select
UNICODE
(or the appropriate ISO 8859 char set) over SQL_ASCII?
On Mon, Feb 02, 2004 at 04:22:29PM +1100, Stephen Robert Norris wrote:
On Fri, 2004-01-30 at 13:04, Alvaro Herrera wrote:
On Thu, Jan 29, 2004 at 08:50:47PM -0500, Manuel Tejada wrote:
By the way, what does mean RHEL3?
Red Hat Entreprise Linux, a commercial Linux distribution
uom := (select uom from prodclass where code = prod_class) ;
Now I want to know why this syntax even compiles!?
What does this mean in plpgsql and where can I find a discussionin the
documentation?
Rick
Tom Lane wrote:
Frank Millman [EMAIL PROTECTED] writes:
uom := (select uom
I need to return a row of data from a function. I've been looking the the HTML
docs and have found nothing of value. If I try to return a variable of type
RECORD, I get the following error:
NOTICE: plpgsql: ERROR during compile of last_log near line 0
ERROR: fmgr_info: function 0: cache lookup
Richard Schilling [EMAIL PROTECTED] writes:
Looking at your query, I notice that the longer query happens when you
search on b.zcustnum=30538 while the LEFT OUTER JOIN remains the same.
It could be that when testing a.zcustnum=30530 the server can short
circuit the logic - it only has to
Michal Hlavac [EMAIL PROTECTED] writes:
groups[] := tmpi;
returns error: syntax error at or near [
This is supported in PG 7.4 (although you do need to provide a subscript
expression ...)
regards, tom lane
---(end of
On Sat, 31 Jan 2004 23:41:54 -0500, Doug McNaught wrote:
For 7.3, the info you need is available in the system catalogs, which
have a somewhat hairier layout than the SQL-standard information_schema.
Doug, thanks - do you know if the system catalogs retain the same
abilities in 7.4? So that if
Would you attach your startup script?
2 other questions?
1. Are all the binaries you are calling using the full paths?
2. Are you calling the pg_ctl as user postgres(or other user) (i.e. su -
postgres -c 'pg_ctl .'
Quoting Remi [EMAIL PROTECTED]:
Hello,
I've installed redhat
I have a table with these columns:
id, node, parent_node_id
The top-most nodes would have a parent_node_id of
NULL. Is it possible to get a node, and all its parent
nodes, in a single query?
For example, a node might be:
books computers databases oss postgres
and the rows fetched would
Ben [EMAIL PROTECTED] writes:
On Sat, 31 Jan 2004 23:41:54 -0500, Doug McNaught wrote:
For 7.3, the info you need is available in the system catalogs, which
have a somewhat hairier layout than the SQL-standard information_schema.
Doug, thanks - do you know if the system catalogs retain the
Is someone taking care about the fact that the pgdb.py shipped with
7.4.1 is the wrong version? What bail me out is the fact that the
version pgdb.py shipped with 7.4.1 is a version *pre 7.3*; we
add the same bug with the 7.3 and was not solved until the 7.3.2
distribution:
Couple of ways to do it. One is to use the hierarchical query patch
that mimics Oracle's CONNECT BY
syntax at
http://www.brasileiro.net/postgres/cookbook/view-one-recipe.adp?
recipe_id=19490.
Another way is to use a nested set model, described at
[EMAIL PROTECTED] (harjan) writes:
cannot extend table name input/output error check free disk space
The hard disk has about 1 gb free space.
Pls advise.
The check free disk space bit is just a hint, which is not very
relevant in this case. The critical part of that message is the
kernel
Doug McNaught [EMAIL PROTECTED] writes:
Ben [EMAIL PROTECTED] writes:
Doug, thanks - do you know if the system catalogs retain the same
abilities in 7.4? So that if I implement this, will it still work later? I
don't mind hairy, but temporary is a concern, at least.
The system catalog
Gaetano Mendola [EMAIL PROTECTED] writes:
Is someone taking care about the fact that the pgdb.py shipped with
7.4.1 is the wrong version?
There is no pgdb.py in the core PG 7.4.* releases. I suppose you
are talking about a packaging error in the RPM distribution. Lamar Owen
would be the man
22 matches
Mail list logo