Re: [BUGS] Bug in move 0
"Hiroshi Inoue" <[EMAIL PROTECTED]> writes: > If I remember correctly *move 0* means *move all* in the > implementation of cursor. It does (I looked at it before). > I don't know if it's the spec or not. As best I can tell from SQL92, FETCH RELATIVE 0 implies no movement (refetch same row). MOVE is not in the spec but it seems it ought to behave like that too. The fix seemed too extensive to be making in the last days of 7.0 beta, so I let it go at the time --- but someone should fix this. regards, tom lane
Re: [BUGS] Bug in move 0
Bruce Momjian <[EMAIL PROTECTED]> writes: > I just sent off an email stating that MOVE 0 goes to the end, and that > the FETCH manual page says: > Postgres does not currently support this notion; in > fact the value zero is reserved to indicate that > all rows should be retrieved and is equivalent to > ^^ > specifying the ALL keyword. If the RELATIVE key- > word has been used, the Postgres assumes that the > user intended SQL92 behavior and returns this error > message. > So it seems we are OK. We may have documented the behavior, but that doesn't make it right ;-) If someone were to submit a patch to change MOVE 0 into a no-op (without breaking MOVE ALL of course), I'd vote to apply it. regards, tom lane
Re: [BUGS] Bug in move 0
> Bruce Momjian <[EMAIL PROTECTED]> writes: > >> We may have documented the behavior, but that doesn't make it right ;-) > >> If someone were to submit a patch to change MOVE 0 into a no-op > >> (without breaking MOVE ALL of course), I'd vote to apply it. > > > If we do that, how does one move to the end of a cursor? > > MOVE ALL. > > The problem right now is just that MOVE ALL is internally represented > as MOVE 0 ... there needs to be a different representation for it. > > regards, tom lane > Added to TODO: * MOVE 0 should not move to end of cursor -- Bruce Momjian| http://www.op.net/~candle [EMAIL PROTECTED] | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup.| Drexel Hill, Pennsylvania 19026
Re: [BUGS] Bug in move 0
Bruce Momjian <[EMAIL PROTECTED]> writes: >> We may have documented the behavior, but that doesn't make it right ;-) >> If someone were to submit a patch to change MOVE 0 into a no-op >> (without breaking MOVE ALL of course), I'd vote to apply it. > If we do that, how does one move to the end of a cursor? MOVE ALL. The problem right now is just that MOVE ALL is internally represented as MOVE 0 ... there needs to be a different representation for it. regards, tom lane
Re: [BUGS] Bug in move 0
> Bruce Momjian <[EMAIL PROTECTED]> writes: > > I just sent off an email stating that MOVE 0 goes to the end, and that > > the FETCH manual page says: > > > Postgres does not currently support this notion; in > > fact the value zero is reserved to indicate that > > all rows should be retrieved and is equivalent to > > ^^ > > specifying the ALL keyword. If the RELATIVE key- > > word has been used, the Postgres assumes that the > > user intended SQL92 behavior and returns this error > > message. > > > So it seems we are OK. > > We may have documented the behavior, but that doesn't make it right ;-) > If someone were to submit a patch to change MOVE 0 into a no-op > (without breaking MOVE ALL of course), I'd vote to apply it. If we do that, how does one move to the end of a cursor? -- Bruce Momjian| http://www.op.net/~candle [EMAIL PROTECTED] | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup.| Drexel Hill, Pennsylvania 19026
Re: [BUGS] Bug in move 0
> "Hiroshi Inoue" <[EMAIL PROTECTED]> writes: > > If I remember correctly *move 0* means *move all* in the > > implementation of cursor. > > It does (I looked at it before). > > > I don't know if it's the spec or not. > > As best I can tell from SQL92, FETCH RELATIVE 0 implies no movement > (refetch same row). MOVE is not in the spec but it seems it ought > to behave like that too. > > The fix seemed too extensive to be making in the last days of 7.0 > beta, so I let it go at the time --- but someone should fix this. > I just sent off an email stating that MOVE 0 goes to the end, and that the FETCH manual page says: SQL92 allows one to repetatively retrieve the cur- sor at its "current position" using the syntax FETCH RELATIVE 0 FROM cursor Postgres does not currently support this notion; in fact the value zero is reserved to indicate that all rows should be retrieved and is equivalent to ^^ specifying the ALL keyword. If the RELATIVE key- word has been used, the Postgres assumes that the user intended SQL92 behavior and returns this error message. So it seems we are OK. -- Bruce Momjian| http://www.op.net/~candle [EMAIL PROTECTED] | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup.| Drexel Hill, Pennsylvania 19026
Re: [BUGS] Bug in move 0
Seems MOVE 0 moves to the end of the cursor. The FETCH manual says: SQL92 allows one to repetatively retrieve the cur- sor at its "current position" using the syntax FETCH RELATIVE 0 FROM cursor Postgres does not currently support this notion; in fact the value zero is reserved to indicate that all rows should be retrieved and is equivalent to ^^ specifying the ALL keyword. If the RELATIVE key- word has been used, the Postgres assumes that the user intended SQL92 behavior and returns this error message. > = > POSTGRESQL BUG REPORT TEMPLATE > = > > > Your name : Jutso Hung > Your email address : [EMAIL PROTECTED] > > > System Configuration > - > Architecture (example: Intel Pentium) : AMD K6 > > Operating System (example: Linux 2.0.26 ELF) : Linux 2.2.12-20 > > PostgreSQL version (example: PostgreSQL-6.5.3): PostgreSQL-7.0Beta1 > > Compiler used (example: gcc 2.8.0) : egcs-2.91.66 > > > Please enter a FULL description of your problem: > > > If declare a cursor for a query, and move with 0. Then can not > fetch any record ! > > a example: > > template1=# select * from emp; > empno |name > + > 11 | John Smith > 12 | Mary White > 13 | Joe Brown > (3 rows) > > template1=# begin; > BEGIN > template1=# declare x cursor for select * from emp; > SELECT > template1=# move 0 in x; > MOVE > template1=# fetch all in x; > empno | name > ---+-- > (0 rows) > > template1=# move backward all in x; > MOVE > template1=# fetch all in x; > empno |name > + > 11 | John Smith > 12 | Mary White > 13 | Joe Brown > (3 rows) > > > Jutso Hung <[EMAIL PROTECTED]> > > > -- Bruce Momjian| http://www.op.net/~candle [EMAIL PROTECTED] | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup.| Drexel Hill, Pennsylvania 19026
[BUGS] Query causesExecSubPlan: NULL value error
POSTGRESQL BUG REPORT TEMPLATE Your name :Richard Smith Your email address : [EMAIL PROTECTED] System Configuration - Architecture (example: Intel Pentium) :Intel Pentium Operating System (example: Linux 2.0.26 ELF) :Red Hat Linux 6.2 (Stock) PostgreSQL version (example: PostgreSQL-6.5.3) :PostgreSQL-6.5.3 Compiler used (example: gcc 2.8.0):n/a Please enter a FULL description of your problem: I am studying Postgres and have been working thru Bruce Momjian's book. In figure 8.9 on page 79 I am doing the second query in that figure. I have typed it in exactly as he presented it but I get a: "ERROR: ExecSubPlan: null value returned by expression subselect" type error. I belive my table structures are ok, because the previous examples (including the one on the same page) have worked on it. I emailed this problem to Bruce and he replied: "That is strange. It sounds like a PostgreSQL bug. My guess is that there is one or two rows that is causing this. Please report it to the bugs list so we can fix it." I have copied and pasted the query and the error message below: test1=> SELECT f1.firstname, f1.lastname, f1.age FROM friend f1 WHERE age = ( test1-> SELECT MAX(f2.age) FROM friend f2 WHERE f1.state = f2.state ) test1-> ORDER BY firstname, lastname ; ERROR: ExecSubPlan: null value returned by expression subselect test1=> I have copied the data set: test1=> SELECT * FROM friend ; firstname |lastname|city |state|age ---++---+-+--- Cindy |Anderson|Denver |CO | 23 Mike |Nichols |Tampa Bay |FL | 20 Mark |Middleton |Indianapolis |IN | Jack |Burger | | | 27 Dean |Yeager |Plymouth |MA | 24 Ned|Millstone |Cedar Creek|MD | 27 Sandy |Gleason |Ocean City |MA | 33 Victor |Tabor |Williamsport |PA | 22 Dick |Gleason |Ocean City |NJ | 20 Mari-Jo|Anderson|Long Island|NY | 32 Pete |Moxeiter|Saskatoon |SK | 35 Sid|Gleason |Denver |CO | 21 Sam|I Am|New York |NY | 27 Sam|Jackson |Allentown |PA | 23 Deb|Bouchier|Saskatoon |SK | 32 Natalie|Fisher |Fortbywater|NJ | 22 (16 rows) test1=> Please describe a way to repeat the problem. Please try to provide a concise reproducible example, if at all possible: -- This problem occures everytime I run the query.
Re: [BUGS] Query causesExecSubPlan: NULL value error
"Rick Smith" <[EMAIL PROTECTED]> writes: >PostgreSQL version (example: PostgreSQL-6.5.3) :PostgreSQL-6.5.3 > ERROR: ExecSubPlan: null value returned by expression subselect 6.5 and older don't cope with sub-selects returning NULL. This is fixed in Postgres 7.0. regards, tom lane
Re: [BUGS] Query causesExecSubPlan: NULL value error
Cool. Thanks, Tom. > "Rick Smith" <[EMAIL PROTECTED]> writes: > >PostgreSQL version (example: PostgreSQL-6.5.3) :PostgreSQL-6.5.3 > > > ERROR: ExecSubPlan: null value returned by expression subselect > > 6.5 and older don't cope with sub-selects returning NULL. This is fixed > in Postgres 7.0. > > regards, tom lane > -- Bruce Momjian| http://www.op.net/~candle [EMAIL PROTECTED] | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup.| Drexel Hill, Pennsylvania 19026
Re: [BUGS] Minimal patches for PostgreSQL 7.0b3 on NetBSD/alpha 1.4.1....
I am unsure how to address this NetBSD/alpha patch.
> Here are minimal patches to get 7.0 beta 3 limping along on NetBSD/alpha
> release 1.4.1.
>
> There are lots of problems with the oid handling, and I can't get it
> to successfully even begin to do a make runcheck, make runtest, or
> make bigtest.
>
> The results of a maketest are:
> === Notes... =
> postmaster must already be running for the regression tests to succeed.
> The time zone is set to PST8PDT for these tests by the client frontend.
> Please report any apparent problems to [EMAIL PROTECTED]
> See regress/README for more information.
>
> === dropping old regression database... =
> ERROR: typeidTypeRelid: Invalid type - oid = 0
> dropdb: database removal failed
> === creating new regression database... =
> ERROR: createdb: database 'regression' already exists
> createdb: database creation failed
> createdb failed
>
> Minimal patches are attached. They are enough to get 7.0 beta 3 up
> and able to do minimal SQL queries. They are also required to get
> it to build at all.
> --
> Kevin P. Nealhttp://www.pobox.com/~kpn/
>
> "You're a slacker if you only give 90% 'cause you are afraid of the \
> other 10%."-- Ross Smith Apr 22 1999 2:29am
[ Attachment, skipping... ]
--
Bruce Momjian| http://www.op.net/~candle
[EMAIL PROTECTED] | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup.| Drexel Hill, Pennsylvania 19026
*** ./old/src/backend/main/main.c Wed Jan 26 00:56:30 2000
--- ./new/src/backend/main/main.c Fri Apr 7 22:19:30 2000
***
*** 12,27
--- 12,31
*
*-
*/
#include
+ #if defined(__NetBSD__)
+ #include
+ #else
#if defined(__alpha__) && !defined(linux)
#include
#include "machine/hal_sysinfo.h"
#define ASSEMBLER
#include
#undef ASSEMBLER
+ #endif
#endif
#include "postgres.h"
#ifdef USE_LOCALE
#include
*** ./old/src/include/port/netbsd.h Tue Mar 7 20:58:23 2000
--- ./new/src/include/port/netbsd.h Sun Apr 9 23:49:37 2000
***
*** 1,43
#define USE_POSIX_TIME
#if defined(__i386__)
#define NEED_I386_TAS_ASM
#define HAS_TEST_AND_SET
#endif
#if defined(__sparc__)
#define NEED_SPARC_TAS_ASM
#define HAS_TEST_AND_SET
#endif
#if defined(__vax__)
#define NEED_VAX_TAS_ASM
#define HAS_TEST_AND_SET
#endif
#if defined(__ns32k__)
#define NEED_NS32K_TAS_ASM
#define HAS_TEST_AND_SET
#endif
#if defined(__m68k__)
#define HAS_TEST_AND_SET
#endif
#if defined(__arm__)
#define HAS_TEST_AND_SET
#endif
#if defined(__mips__)
/* # undef HAS_TEST_AND_SET */
#endif
! #if defined(__powerpc__)
#define HAS_TEST_AND_SET
#endif
#if defined(__powerpc__)
typedef unsigned int slock_t;
- #else
- typedef unsigned char slock_t;
#endif
--- 1,50
#define USE_POSIX_TIME
#if defined(__i386__)
#define NEED_I386_TAS_ASM
#define HAS_TEST_AND_SET
+ typedef unsigned char slock_t;
#endif
#if defined(__sparc__)
#define NEED_SPARC_TAS_ASM
#define HAS_TEST_AND_SET
+ typedef unsigned char slock_t;
#endif
#if defined(__vax__)
#define NEED_VAX_TAS_ASM
#define HAS_TEST_AND_SET
+ typedef unsigned char slock_t;
#endif
#if defined(__ns32k__)
#define NEED_NS32K_TAS_ASM
#define HAS_TEST_AND_SET
+ typedef unsigned char slock_t;
#endif
#if defined(__m68k__)
#define HAS_TEST_AND_SET
+ typedef unsigned char slock_t;
#endif
#if defined(__arm__)
#define HAS_TEST_AND_SET
+ typedef unsigned char slock_t;
#endif
#if defined(__mips__)
/* # undef HAS_TEST_AND_SET */
+ typedef unsigned char slock_t;
#endif
! #if defined(__alpha__)
#define HAS_TEST_AND_SET
+ typedef unsigned long int slock_t;
#endif
#if defined(__powerpc__)
+ #define HAS_TEST_AND_SET
typedef unsigned int slock_t;
#endif
*** ./old/src/include/storage/s_lock.h Wed Jan 26 00:58:33 2000
--- ./new/src/include/storage/s_lock.h Sun Apr 9 23:56:46 2000
***
*** 260,270
--- 260,275
#else /* i.e. not __osf__ */
#define TAS(lock) tas(lock)
#define S_UNLOCK(lock) { __asm__("mb"); *(lock) = 0; }
+ #if defined(__GNUC__)
+ static int /* GCC on the Alpha doesn't appear to handle
+inlining of assembly with %0 or %1 properly. */
+ #else
static __inline__ int
+ #endif
tas(volatile slock_t *lock)
{
register slock_t _res;
__asm__(" ldq $0, %0 \n\
Re: [BUGS] Minimal patches for PostgreSQL 7.0b3 on NetBSD/alpha 1.4.1....
Bruce Momjian <[EMAIL PROTECTED]> writes: > I am unsure how to address this NetBSD/alpha patch. I'd say leave it out for now. After I finish the fmgr revisions we ought to have a better shot at porting to Alphas. I know most of Ryan K's Linux/Alpha patches will go away with that. I am only fifty or so functions away from updating everything that accepts pass-by-value data types. There are a lot of pass-by-reference data types not touched yet, but I think that those should work anywhere that sizeof(Datum) == sizeof(pointer), so the vast majority of the fmgr-related porting problems should be gone at that point. I will be calling for port testers as soon as I commit those changes... regards, tom lane
Re: [BUGS] Minimal patches for PostgreSQL 7.0b3 on NetBSD/alpha 1.4.1....
That was my guess, though his changes were s_lock related. Seems that is an Alpha mess too. > Bruce Momjian <[EMAIL PROTECTED]> writes: > > I am unsure how to address this NetBSD/alpha patch. > > I'd say leave it out for now. After I finish the fmgr revisions we > ought to have a better shot at porting to Alphas. I know most of > Ryan K's Linux/Alpha patches will go away with that. > > I am only fifty or so functions away from updating everything that > accepts pass-by-value data types. There are a lot of pass-by-reference > data types not touched yet, but I think that those should work anywhere > that sizeof(Datum) == sizeof(pointer), so the vast majority of the > fmgr-related porting problems should be gone at that point. I will be > calling for port testers as soon as I commit those changes... > > regards, tom lane > -- Bruce Momjian| http://www.op.net/~candle [EMAIL PROTECTED] | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup.| Drexel Hill, Pennsylvania 19026
Re: [BUGS] Minimal patches for PostgreSQL 7.0b3 on NetBSD/alpha 1.4.1....
Bruce Momjian <[EMAIL PROTECTED]> writes: > That was my guess, though his changes were s_lock related. Seems that is > an Alpha mess too. Yes, it sounds like we will need some help from a certified Alpha guru to make spinlock code that works reliably on multi-CPU Alphas :-(. Anyone have friends in the right places at DEC? regards, tom lane
Re: [BUGS] Problem with ecpg
Can someone comment on this patch?
>
>
> POSTGRESQL BUG REPORT TEMPLATE
>
>
>
>
> Your name : Bernard Isambert
> Your email address : [EMAIL PROTECTED]
>
>
> System Configuration
> -
> Architecture (example: Intel Pentium) : Intel pentium
>
> Operating System (example: Linux 2.0.26 ELF) : Linux 2.2.13
>
> PostgreSQL version (example: PostgreSQL-6.5.3): PostgreSQL-7.0beta5
> (and previous)
>
> Compiler used (example: gcc 2.8.0) : any...
>
>
>
> Please enter a FULL description of your problem:
>
> The problem is in the parsing of operators by ecpg (details below).
> As a result, good or bad precompile depends on usage of spaces
> in the source, where it should not.
>
>
> Please describe a way to repeat the problem. Please try to provide a
> concise reproducible example, if at all possible:
> --
>
> Source file:
>
> EXEC SQL BEGIN DECLARE SECTION;
> VARCHAR hostvar[32];
> EXEC SQL END DECLARE SECTION;
>
> strcpy(hostvar.arr, "something");
>
> EXEC SQL SELECT column2 FROM table1 WHERE column1 = :hostvar;
>
> strcpy(hostvar.arr, "anything");
>
> EXEC SQL SELECT column2 FROM table1 WHERE column1=:hostvar;
>
>
> Ecpg parsing gives:
>
> for the first select, with spaces around the = sign:
>
> { ECPGdo(__LINE__, NULL, "select column2 from table1 where column1 =
> ? ",
> ECPGt_varchar,&(hostvar),32L,1L,sizeof(struct varchar_hostvar),
> ECPGt_NO_INDICATOR, NULL, 0L, 0L, 0L, ECPGt_EOIT, ECPGt_EORT);}
>
> for the second select, without spaces around (after) the = sign:
>
> { ECPGdo(__LINE__, NULL, "select column2 from table1 where column1
> =: hostvar",
>ECPGt_EOIT, ECPGt_EORT);}
>
> which is clearly different from the expected result
> and yields a run-time error ...
>
>
> If you know how this problem might be fixed, list the solution below:
> -
>
> I suggest a workaround in the ecpg source "pgc.l"
> (src/interfaces/ecpg/preproc/pgc.l):
>
> diff pgc.l.orig pgc.l
> 192c192,194
> < operator{op_chars}+
> ---
> > /* op_mchars = op_chars but the ':' */
> > op_mchars [\~\!\@\#\^\&\|\`\?\$\+\-\*\\/\%\<\>\=]
> > operator{op_chars}{op_mchars}*
>
> This forbids ":" to be the second (or above) char in an operator.
> Is there any situation where it should be?
> Or maybe the rule should be a bit more complex?
>
> --
> __
>
> Bernard ISAMBERT ([EMAIL PROTECTED])
> Syndicat Interhospitalier de Bretagne (www.sib.fr)
> __
>
--
Bruce Momjian| http://www.op.net/~candle
[EMAIL PROTECTED] | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup.| Drexel Hill, Pennsylvania 19026
Re: [BUGS] libpq++ update
Tom Vijlbrief, Tom Lane added some of your patches to 7.0. Do you have
anything new for 7.1? I know you were still working on it when we
entered beta.
>
> POSTGRESQL BUG REPORT TEMPLATE
>
>
>
> Your name : Tom Vijlbrief
> Your email address : [EMAIL PROTECTED]
>
>
> System Configuration
> -
> Architecture (example: Intel Pentium) : Intel PII
>
> Operating System (example: Linux 2.0.26 ELF) : Linux 2.3.51
>
> PostgreSQL version (example: PostgreSQL-6.5.3): PostgreSQL-6.5.3
>
> Compiler used (example: gcc 2.8.0) : egcs-2.91.66
>
>
> Please enter a FULL description of your problem:
>
> libpq++ leaks file descriptors and memory.
>
> The constructor of PgConnection leaks a file everytime it is called.
> Also DEBUG is on by default.
>
> In addition the header file libpq++.H is insane. It contains
> outdated copies of the header files (pglobject.h and the others).
>
> The libpq++.H declares a smaller PgLargeObject (without class member
> variables) then the PgLargeObject in pglobject.h.
> This is the reason that examples/testlo crashes !
>
> I fixed the header classes and memory/file leakage. I also added
> header file PostgresDatabase.h which contains a new implementation
> with exception handling, cursors and transactions. Look at
> examples/testexcep.cc for the usage. The C++ interface is still
> compatible with the old version.
>
>
> Please describe a way to repeat the problem. Please try to provide a
> concise reproducible example, if at all possible:
> --
> Running the next program, it crashes after approx. 1000 iterations
> (depending on configuration of OS)
>
>
> #include
>
> #include
>
> int main()
> {
> for (int i= 0; i < 1; i++) {
> cerr << i << endl;
> PgConnection("");
> }
> }
>
>
> Running examples/testlo crashes with a damaged stack.
>
>
> If you know how this problem might be fixed, list the solution below:
> -
>
> change 'FILE * debug' from a local var to a static var in
> pgconnection.cc.
>
> I added a tar containing a new version of the src/interfaces/libpq++
> directory
> because many files (source, headers, README, TODO, CHANGES) are
> changed.
[ Attachment, skipping... ]
--
Bruce Momjian| http://www.op.net/~candle
[EMAIL PROTECTED] | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup.| Drexel Hill, Pennsylvania 19026
Re: [BUGS] CLUSTER bug
This was fixed in 7.0.1. > Sorry for a downer on an excellent piece of software. > > -- > Darren Steven > Applications Specialist > Networking Tasmania > Telstra Australia > Ph.1800 813 302 > > > If PostgreSQL failed to compile on your computer or you found a bug that > is likely to be specific to one platform then please fill out this form > and e-mail it to [EMAIL PROTECTED] > > To report any other bug, fill out the form below and e-mail it to > [EMAIL PROTECTED] > > If you not only found the problem but solved it and generated a patch > then e-mail it to [EMAIL PROTECTED] instead. Please use the > command "diff -c" to generate the patch. > > You may also enter a bug report at http://www.postgresql.org/ instead of > e-mail-ing this form. > > > POSTGRESQL BUG REPORT TEMPLATE > > > > Your name : Darren Steven > Your email address: [EMAIL PROTECTED] > > > System Configuration > - > Architecture (example: Intel Pentium) : Intel PIII > > Operating System (example: Linux 2.0.26 ELF): Linux 2.2.14 > > PostgreSQL version (example: PostgreSQL-6.5.1): PostgreSQL-7.0 > > Compiler used (example: gcc 2.8.0) : egcs-2.91.66 19990314/Linux >(egcs-1.1.2 release) > > > Please enter a FULL description of your problem: > > > CLUSTER fails and appears to corrupt database. I don't know if this happened on >other releases, found it by mistake while playing with 7.0 > > PS Great DB by the way. > > > > Please describe a way to repeat the problem. Please try to provide a > concise reproducible example, if at all possible: > -- > > Create a database, create a table. insert some data. create index on one of fields. >CLUSTER indexname ON tablename; > > With a large number of rows (so I can see it happeneing), I see the table being >copied to a temp, and the renamed back to its original name. the problem is with the >index : > > dws=# create index testind on accesslog (alclient); > CREATE > dws=# cluster testind on accesslog; > ERROR: temp_674e00 is an index relation > > > temp_674e00 appears to be a copy of the index file. > > psql now tells me the relation accesslog no longer exists > > the same error also occurs on small tables. > > If you know how this problem might be fixed, list the solution below: > - > > Sorry. I've looked at cluster.c and if I fix it I'll post it. -- Bruce Momjian| http://www.op.net/~candle [EMAIL PROTECTED] | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup.| Drexel Hill, Pennsylvania 19026
