Thread: ERROR: cannot find attribute 1 of relation pg_temp.460.0
After creating temporary table with CREATE TEMP TABLE command in ECPG I get following error when disconnecting / exiting program: query: close C1 ProcessUtility: close C1 CommitTransactionCommand proc_exit(0) [#0] shmem_exit(0) [#0] ERROR: cannot find attribute 1 of relation pg_temp.460.0 pq_flush: send() failed: Bad file descriptor AbortCurrentTransaction pq_flush: send() failed: Bad file descriptor FATAL 1: Socket command type pq_flush: send() failed: Bad file descriptor proc_exit(0) [#1] ERROR: unknown frontend message was received pq_flush: send() failed: Bad file descriptor AbortCurrentTransaction NOTICE: AbortTransaction and not in in-progress state pq_flush: send() failed: Bad file descriptor /usr/lib/postgresql/bin/postmaster: reaping dead processes... /usr/lib/postgresql/bin/postmaster: CleanupProc: pid 460 exited with status 11 /usr/lib/postgresql/bin/postmaster: CleanupProc: reinitializing shared memory and semaphores shmem_exit(0) [#0] binding ShmemCreate(key=52e519, size=4794368) If I try to delete temporary table before disconnecting things get even worse - it enters infinite loop of errors. Any clue what is wrong? Regards, Ivo Simicevic.
Ivo Simicevic <ivo@ultra.hr> writes:
> After creating temporary table with CREATE TEMP TABLE command in ECPG
> I get following error when disconnecting / exiting program:
I believe this is triggered by ecpg's autocommit feature, and that
you could work around it by ensuring that at least one commit occurs
between creation of the temp table and application exit. It looks
like 6.5.* gets confused if it has to delete a never-yet-committed
temp table :-(.
I don't see any such problem with current sources, but I dunno if it's
practical to back-patch a fix into 6.5.*. The current sources have
diverged quite a bit in that area...
regards, tom lane
On Sun, Nov 28, 1999 at 06:45:26PM -0500, Tom Lane wrote: > I believe this is triggered by ecpg's autocommit feature, and that > you could work around it by ensuring that at least one commit occurs > between creation of the temp table and application exit. It looks IMO the naming of autocommit is all but a good one. There is only one way to commit a transaction in ecpg and that's by issuing a COMMIT resp. END WORK statement. The only difference between the two ways of operation in ecpg is how to start a transaction. With AUTOCOMMIT set to ON a transaction is started only via a BEGIN WORK statement. Ot in other words if you do not start a transaction each statement is its own one and thus autocommitted. If AUTOCOMMIT is set to OFF ecpg always starts a new transaction after a COMMIT resp. a ROLLBACK. > like 6.5.* gets confused if it has to delete a never-yet-committed > temp table :-(. Yes, this looks like there is no commit after the create and AUTOCOMMIT is set to OFF (default). Michael -- Michael Meskes | Go SF 49ers! Th.-Heuss-Str. 61, D-41812 Erkelenz | Go Rhein Fire! Tel.: (+49) 2431/72651 | Use Debian GNU/Linux! Email: Michael@Fam-Meskes.De | Use PostgreSQL! ************
On Sun, Nov 28, 1999 at 06:45:26PM -0500, Tom Lane wrote: > I believe this is triggered by ecpg's autocommit feature, and that > you could work around it by ensuring that at least one commit occurs > between creation of the temp table and application exit. It looks IMO the naming of autocommit is all but a good one. There is only one way to commit a transaction in ecpg and that's by issuing a COMMIT resp. END WORK statement. The only difference between the two ways of operation in ecpg is how to start a transaction. With AUTOCOMMIT set to ON a transaction is started only via a BEGIN WORK statement. Ot in other words if you do not start a transaction each statement is its own one and thus autocommitted. If AUTOCOMMIT is set to OFF ecpg always starts a new transaction after a COMMIT resp. a ROLLBACK. > like 6.5.* gets confused if it has to delete a never-yet-committed > temp table :-(. Yes, this looks like there is no commit after the create and AUTOCOMMIT is set to OFF (default). Michael -- Michael Meskes | Go SF 49ers! Th.-Heuss-Str. 61, D-41812 Erkelenz | Go Rhein Fire! Tel.: (+49) 2431/72651 | Use Debian GNU/Linux! Email: Michael@Fam-Meskes.De | Use PostgreSQL! ************