SEO
vBulletin Search Engine Optimization
| |||||||
| Register | FAQ | Members List | Calendar | Search | Today's Posts | Mark Forums Read |
04-08-2008, 07:20 PM
| ||||
| ||||
 Re: Eeek! Major problem after reload with tsearch2 This is know issue with OIDS. You,probably, needed to apply regprocedure_7.4.patch.gz patch from http://www.sai.msu.su/~megera/postgres/gist/tsearch/V2/ Oleg On Thu, 3 Feb 2005, Karl Denninger wrote: > Ok, I found out what was going on with the tsearch2 module and reloading > after an upgrade to 8.0.1 from 7.4.1 > > The data now loads cleanly, and selects are fine. > > HOWEVER, when I attempt an update, I issue the following SQL command (this > table has a tsearch2 vector in it  > > update post set invisible='0' where ordinal='2843' > > And get back: > > ERROR: cache lookup failed for function 36476 CONTEXT: SQL statement > "select lt.tokid, map.dict_name from public.pg_ts_cfgmap as map, > public.pg_ts_cfg as cfg, public.token_type( $1 ) as lt where lt.alias = > map.tok_alias and map.ts_name = cfg.ts_name and cfg.oid= $2 order by > lt.tokid desc;" > > Aieeee! > > A reindex did nothing. > > What did I miss? Looks like there's something missing, but what?! > > -- > Regards, Oleg __________________________________________________ ___________ Oleg Bartunov, sci.researcher, hostmaster of AstroNet, Sternberg Astronomical Institute, Moscow University (Russia) Internet: oleg@sai.msu.su, http://www.sai.msu.su/~megera/ phone: +007(095)939-16-83, +007(095)939-23-83 ---------------------------(end of broadcast)--------------------------- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match      |
|
04-08-2008, 07:20 PM
| ||||
| ||||
| Re: Eeek! Major problem after reload with tsearch2 On Thu, 3 Feb 2005, Karl Denninger wrote: > The patch is in the 8.0.1 version of Tsearch2 already. > > The problem is that I have a dump from a 7.4.1 database taken with the > 8.0.1 pg_dumpall that I need to be able to get back online on 8.0.x. you had to apply patch to 7.4.1 db before dumping or use regprocedure_update.sql to update your live 7.4.1 database ! pg_dump (pg_dumpall) has nothing with the problem. After applying patch and dumping db you have OID-free db and should have no problem ! > > Is the only option to find all the functions in the tsearch.sql file, drop > them by hand, remove all the tsearch2 index fields, then reload > tsearch2.sql and re-create the indices? > > That's not impossible, but a shizload of work, as there's no good way that > I can see to drop all the tsearch2 functions in a single step (e.g. I'd > have to go through the tsearch2.sql file individually, find all the > entries, drop them, etc.) > > Another possibility.... > > Does a pg_dumpall dump functions as well? It appears not from the > documentation - so if I drop the columns and then dump the database, I > should have a "clean" dump without the OID stuff in it. > > If I then re-init and reload the data, I should then be able to do so > without the tsearch2.sql stuff. I can then reload the tsearch2.sql > functions and re-create the indices. > > Sound plausible? > No, if you have OIDs in db pg_dump* will dump them. Try regprocedure_update.sql and read http://www.sai.msu.su/~megera/postgr...-V2-intro.html If you have 7.4.1 db running you might go way described earlier. > - > Regards, Oleg __________________________________________________ ___________ Oleg Bartunov, sci.researcher, hostmaster of AstroNet, Sternberg Astronomical Institute, Moscow University (Russia) Internet: oleg@sai.msu.su, http://www.sai.msu.su/~megera/ phone: +007(095)939-16-83, +007(095)939-23-83 ---------------------------(end of broadcast)--------------------------- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to majordomo@postgresql.org) |
Linear Mode
