Hello,
I'm experiencing a strange problem. Here it is :
I've created a function with a FOR loop.
DECLARE
Current RECORD;
BEGIN
FOR current IN SELECT * FROM employees LOOP
Tmp := current.id;
END LOOP;
...
When I call the function, I get the error :
ERROR: record current
On Fri, 1 Oct 2004 07:24 pm, Johann Robette wrote:
Hello,
I'm experiencing a strange problem. Here it is :
I've created a function with a FOR loop.
DECLARE
Current RECORD;
BEGIN
FOR current IN SELECT * FROM employees LOOP
Tmp := current.id;
END LOOP;
...
current != Current ?
Oh sorry about that!
No, I was alright in the syntax. Both are defined as current.
I can't find where the problem lies...
-Message d'origine-
De : [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] De la part de Russell Smith
Envoyé : vendredi 1 octobre 2004 13:20
À : [EMAIL PROTECTED]
Objet :
On Fri, 1 Oct 2004, Matthew T. O'Connor wrote:
Marc G. Fournier wrote:
On Thu, 30 Sep 2004, Matthew T. O'Connor wrote:
Are you using default values for autovacuum? Could you prove a little
more detail by setting pg_autovacuum debug with -d 2
Sure ... just restarted it with that setup ... btw ...
Johann Robette [EMAIL PROTECTED] writes:
I've created a function with a FOR loop.
DECLARE
Current RECORD;
BEGIN
FOR current IN SELECT * FROM employees LOOP
Tmp := current.id;
END LOOP;
...
When I call the function, I get the error :
ERROR: record current is
Thanks for your answer.
In fact, I had a syntax error in my function.
Sorry about that!
-Message d'origine-
De : Tom Lane [mailto:[EMAIL PROTECTED]
Envoyé : vendredi 1 octobre 2004 16:47
À : Johann Robette
Cc : [EMAIL PROTECTED]
Objet : Re: [HACKERS] Record unassigned yet
Johann
I just loaded up 9GB of data (32 tables) into a brand new system (Postgres
7.4.5 on Linux 2.4 with 1GB ram, IDE). I immediately ran vacuum analyze
but Postgres seems to be writing a lot to disk even though none of the
tables have incurred any UPDATES or DELETES yet and there are no other
I was found a bug in PostgreSQL 8.0.0beta3.
It isn't in PostgreSQL 7.4.5.
$ createdb test
$ psql test
test=# SELECT version ();
version
-
PostgreSQL 8.0.0beta3 on i686-pc-linux-gnu,
Hello,
I have error message. I can't find any solution of this problem.
How to solve this?
Thanks for any advice.
commandline:
initdb.exe --no-locale -d -L %MY_CLUSTER_DIR%/share -D
%MY_CLUSTER_DIR%/data
===
Running in debug mode.
VERSION=8.0.0beta2
PGDATA=e:/pg/myCluster/data
[EMAIL PROTECTED] (Bruce Momjian) writes:
Have you tried using cc_r for that compile line? Does that help?
Alas, that is not an option available.
cc_r is specific to the AIX xlc compiler; we're using GCC, and xlc
is not available to us.
bash-2.05a$ gcc -v
Reading specs from
On Sep 29, 2004, at 7:37 AM, Bruce Momjian wrote:
Karel Zak wrote:
On Sat, 2004-09-25 at 23:23 +0200, Manfred Spraul wrote:
[EMAIL PROTECTED] wrote:
If the memset
bypasses the cache then the following access will cause a cache
line
miss, which can be so slow that using the faster memset can
onion [EMAIL PROTECTED] writes:
I just loaded up 9GB of data (32 tables) into a brand new system (Postgres
7.4.5 on Linux 2.4 with 1GB ram, IDE). I immediately ran vacuum analyze
but Postgres seems to be writing a lot to disk even though none of the
tables have incurred any UPDATES or DELETES
On September 30, 2004 05:55 pm, Bruce Momjian wrote:
To me it looks like all you need to do is add -pthreads or maybe -lpthreads
depending on exact system to your compile line..
Have you tried using cc_r for that compile line? Does that help?
Greg Stark [EMAIL PROTECTED] writes:
Shouldn't Postgres be noticing the non-immutable random() function and not
making the subquery an InitPlan?
Perhaps. In the dim past, using a dummy subquery was the only way to
persuade the planner not to re-evaluate functions that you didn't want
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi all,
in my development server running a 7.4.5 I can replicate
continuously this error:
ERROR: left link changed unexpectedly
I obtain this with a vacuum full:
test=# vacuum full verbose ua_user_data_exp;
INFO: vacuuming public.ua_user_data_exp
Bruce Momjian wrote:
MemSet was written when gcc 2.X wasn't even stable yet. Have you run
any tests on 3.4 to see if MemSet is still a win with that compiler?
I've done a test years ago that showed that memset is usually at least
as good as MemSet:
=?ISO-8859-1?Q?Szima_G=E1bor?= [EMAIL PROTECTED] writes:
I was found a bug in PostgreSQL 8.0.0beta3.
Fixed, thanks.
It isn't in PostgreSQL 7.4.5.
Actually it is...
regards, tom lane
---(end of broadcast)---
TIP 2: you
I wrote:
Looking at this, I realize that date_trunc() is mismarked: the
timestamptz variant is strongly dependent on the timezone setting
and so should be STABLE not IMMUTABLE. Ooops.
On looking more closely, I think that all of these functions are
mislabeled:
On Fri, Oct 01, 2004 at 18:53:03 -0400,
Tom Lane [EMAIL PROTECTED] wrote:
What I'm inclined to do with these is change pg_proc.h but not force an
initdb. Does anyone want to argue for an initdb to force it to be fixed
in 8.0? We've lived with the wrong labelings for some time now without
Johann Robette wrote:
Oh sorry about that!
No, I was alright in the syntax. Both are defined as current.
I can't find where the problem lies...
The following works fine for me.
=== BEGIN test ===
DROP TABLE employees;
CREATE TABLE employees (id integer, name text);
COPY employees FROM stdin;
1
On Mon, 2004-09-27 at 16:29, Marc G. Fournier wrote:
Its been almost 4 weeks since we've released Beta2, and there have been
enough improvements to the code to warrant a new Beta, to reduce the
number of already fixed bug reports.
For a complete list of changes/improvement since Beta 1 was
21 matches
Mail list logo
