Обсуждение: ERROR: index_rescan: invalid amrescan regproc ???
Hello,
I am trying to run the ImageViewer.java example that is part of the
src/interfaces/jdbc/ examples. I have a database test which has two
images loaded into it with the ImageVIewer app.
I am running a cvs snapshot as of 4/22, java1.2, Solaris 7, cc: WorkShop
Compilers 5.0 98/12/15 C 5.0.
I envoke the postmaster as:su bpm -c "${PGSQLHOME}/bin/postmaster -i -d -D ${PGDATA} 2>&1 >
${PGDATA}/trace.log"
to get a trace.log file.
I start the java app as:
vlad: java -classpath $MYCLASSPATH example.ImageViewer
jdbc:postgresql:test bpm foo
Connecting to Database URL = jdbc:postgresql:test
Selecting oid for item_4.gif
Got oid 149387
Import complete
Selecting oid for item_2.gif
Got oid 149441
At this point I get a SQLException: "Fastpath: index_rescan: invalid
amrescan regproc"
In the trace.log, I have:
vlad: tail -f trace.log
read_pg_options: all=1,verbose=2,query
debug info: User = bpm RemoteHost = 127.0.0.1 RemotePort = 33694 DatabaseName =
test Verbose = 2 Noversion = f timings = f dates = Normal bufsize
=64 sortmem = 512 query echo = f
InitPostgres
StartTransactionCommand
query: show datestyle
ProcessUtility: show datestyle
CommitTransactionCommand
LockReleaseAll: lockmethod=1, pid=4369
LockReleaseAll: reinitializing lockQueue
LockReleaseAll: done
StartTransactionCommand
query: select proname, oid from pg_proc where proname = 'lo_open' or
proname = 'lo_close' or proname = 'lo_creat' or proname = 'lo_unlink' or
proname = 'lo_lseek' or proname = 'lo_tell' or proname = 'loread' or
proname = 'lowrite'
ProcessQuery
CommitTransactionCommand
LockReleaseAll: lockmethod=1, pid=4369
LockReleaseAll: reinitializing lockQueue
LockReleaseAll: done
StartTransactionCommand
query: select imgname from images order by imgname
ProcessQuery
CommitTransactionCommand
LockReleaseAll: lockmethod=1, pid=4369
LockReleaseAll: reinitializing lockQueue
LockReleaseAll: done
StartTransactionCommand
query: select imgoid from images where imgname='item_4.gif'
ProcessQuery
CommitTransactionCommand
LockReleaseAll: lockmethod=1, pid=4369
LockReleaseAll: reinitializing lockQueue
LockReleaseAll: done
StartTransactionCommand
CommitTransactionCommand
LockReleaseAll: lockmethod=1, pid=4369
LockReleaseAll: reinitializing lockQueue
LockReleaseAll: done
StartTransactionCommand
CommitTransactionCommand
LockReleaseAll: lockmethod=1, pid=4369
LockReleaseAll: reinitializing lockQueue
LockReleaseAll: done
StartTransactionCommand
CommitTransactionCommand
LockReleaseAll: lockmethod=1, pid=4369
LockReleaseAll: reinitializing lockQueue
LockReleaseAll: done
StartTransactionCommand
CommitTransactionCommand
LockReleaseAll: lockmethod=1, pid=4369
LockReleaseAll: reinitializing lockQueue
LockReleaseAll: done
StartTransactionCommand
CommitTransactionCommand
LockReleaseAll: lockmethod=1, pid=4369
LockReleaseAll: reinitializing lockQueue
LockReleaseAll: done
StartTransactionCommand
CommitTransactionCommand
LockReleaseAll: lockmethod=1, pid=4369
LockReleaseAll: reinitializing lockQueue
LockReleaseAll: done
StartTransactionCommand
CommitTransactionCommand
LockReleaseAll: lockmethod=1, pid=4369
LockReleaseAll: reinitializing lockQueue
LockReleaseAll: done
StartTransactionCommand
query: select imgoid from images where imgname='item_2.gif'
ProcessQuery
CommitTransactionCommand
LockReleaseAll: lockmethod=1, pid=4369
LockReleaseAll: reinitializing lockQueue
LockReleaseAll: done
StartTransactionCommand
CommitTransactionCommand
LockReleaseAll: lockmethod=1, pid=4369
LockReleaseAll: reinitializing lockQueue
LockReleaseAll: done
StartTransactionCommand
CommitTransactionCommand
LockReleaseAll: lockmethod=1, pid=4369
LockReleaseAll: reinitializing lockQueue
LockReleaseAll: done
StartTransactionCommand
CommitTransactionCommand
LockReleaseAll: lockmethod=1, pid=4369
LockReleaseAll: reinitializing lockQueue
LockReleaseAll: done
StartTransactionCommand
CommitTransactionCommand
LockReleaseAll: lockmethod=1, pid=4369
LockReleaseAll: reinitializing lockQueue
LockReleaseAll: done
StartTransactionCommand
CommitTransactionCommand
LockReleaseAll: lockmethod=1, pid=4369
LockReleaseAll: reinitializing lockQueue
LockReleaseAll: done
StartTransactionCommand
AbortCurrentTransaction
LockReleaseAll: lockmethod=1, pid=4369
LockReleaseAll: reinitializing lockQueue
LockReleaseAll: done
Which doesn't show an error :-(
>From the commandline where I envoked postmaster, I have:
# /etc/init.d/postgress.init start
FindExec: found "/opt/pgsql/bin/postgres" using argv[0]
FindExec: found "/opt/pgsql/bin/postgres" using argv[0]
/opt/pgsql/bin/postmaster: BackendStartup: pid 4481 user bpm db test
socket 5
NOTICE: DateStyle is Postgres with US (NonEuropean) conventions
ERROR: index_rescan: invalid amrescan regproc
Then the java app is basically dead & I have to exit.
Any ideas?
Thanks.
--
Brian Millett
Enterprise Consulting Group "Heaven can not exist,
(314) 205-9030 If the family is not eternal"
bpm@ec-group.com F. Ballard Washburn
On Fri, 23 Apr 1999, Brian P Millett wrote: > Hello, > I am trying to run the ImageViewer.java example that is part of the > src/interfaces/jdbc/ examples. I have a database test which has two > images loaded into it with the ImageVIewer app. > > I am running a cvs snapshot as of 4/22, java1.2, Solaris 7, cc: WorkShop > Compilers 5.0 98/12/15 C 5.0. [snip] > At this point I get a SQLException: "Fastpath: index_rescan: invalid > amrescan regproc" This looks like something in the backend has died while a fastpath function was being used. I'll see if I can recreate it here. [snip] > Then the java app is basically dead & I have to exit. > > Any ideas? Peter -- Peter T Mount peter@retep.org.uk Main Homepage: http://www.retep.org.uk PostgreSQL JDBC Faq: http://www.retep.org.uk/postgresJava PDF Generator: http://www.retep.org.uk/pdf
Peter T Mount <peter@retep.org.uk> writes:
> On Fri, 23 Apr 1999, Brian P Millett wrote:
>> At this point I get a SQLException: "Fastpath: index_rescan: invalid
>> amrescan regproc"
> This looks like something in the backend has died while a fastpath
> function was being used. I'll see if I can recreate it here.
Just to save you repeating the look-around I just did: that's
coming out of backend/access/index/indexam.c, and it's apparently
complaining that a pg_am table row has a null amrescan field.
That shouldn't be true of any of the pg_am rows in a correct
installation.
Brian, what does 'select * from pg_am' show? Did you do an initdb
while installing the 6.5 snapshot you're using?
regards, tom lane
Tom Lane wrote: > Peter T Mount <peter@retep.org.uk> writes: > > On Fri, 23 Apr 1999, Brian P Millett wrote: > >> At this point I get a SQLException: "Fastpath: index_rescan: invalid > >> amrescan regproc" > > > This looks like something in the backend has died while a fastpath > > function was being used. I'll see if I can recreate it here. > > Just to save you repeating the look-around I just did: that's > coming out of backend/access/index/indexam.c, and it's apparently > complaining that a pg_am table row has a null amrescan field. > That shouldn't be true of any of the pg_am rows in a correct > installation. > > Brian, what does 'select * from pg_am' show? Did you do an initdb > while installing the 6.5 snapshot you're using? No I did not. :-( I had done everything else but that. Sorry. I did remove the old & do an "initdb", "createdb test", then reran the : java -classpath $MYCLASSPATH example.ImageViewer jdbc:postgresql:test bpm foo Then I got the following SQLexception. ERROR: index_beginscan: invalid ambeginscan regproc Then I did the test=> select * from pg_am; amname|amowner|amkind|amstrategies|amsupport|amgettuple |aminsert |amdelete |amgetattr|amsetlock|amsettid|amfreetuple|ambeginscan |amrescan |amendscan |ammarkpos |amrestrpos |amopen|amclose|ambuild |amcreate|amdestroy ------+-------+------+------------+---------+------------+----------+----------+---------+---------+--------+-----------+-------------+----------+-----------+-----------+------------+------+-------+---------+--------+--------- rtree | 159|o | 8| 3|rtgettuple |rtinsert |rtdelete |- |- |- |- |rtbeginscan |rtrescan |rtendscan |rtmarkpos |rtrestrpos |- |- |rtbuild |- |- btree | 159|o | 5| 1|btgettuple |btinsert |btdelete |- |- |- |- |btbeginscan |btrescan |btendscan |btmarkpos |btrestrpos |- |- |btbuild |- |- hash | 159|o | 1| 1|hashgettuple|hashinsert|hashdelete|- |- |- |- |hashbeginscan|hashrescan|hashendscan|hashmarkpos|hashrestrpos|- |- |hashbuild|- |- gist | 159|o | 100| 7|gistgettuple|gistinsert|gistdelete|- |- |- |- |gistbeginscan|gistrescan|gistendscan|gistmarkpos|gistrestrpos|- |- |gistbuild|- |- (4 rows) Thanks. -- Brian Millett Enterprise Consulting Group "Heaven can not exist, (314) 205-9030 If the family is not eternal" bpm@ec-group.com F. Ballard Washburn
> I did remove the old & do an "initdb", "createdb test", then reran the :
> java -classpath $MYCLASSPATH example.ImageViewer jdbc:postgresql:test bpm
> foo
> Then I got the following SQLexception.
> ERROR: index_beginscan: invalid ambeginscan regproc
> Then I did the
> test=> select * from pg_am;
> [ perfectly normal-looking pg_am table ... ]
Hmm. Nothing wrong with the table that I can see; conclusion is that
its cache image in memory must be messed up. Perhaps you are indeed
dealing with a platform-specific bug. Or it could be a memory-clobber
kind of problem (but I'd think lots of people would be reporting strange
behavior if we had one of those on the loose).
You might try building the backend with assert checking turned on
(--enable-cassert) to see if any problems are detected.
regards, tom lane