Обсуждение: bug in 6.4.2?
i was recently importing a fairly large amount of data from a mysql to postgres ( 6.4.2 ). to make a long story short, this involved some renames ( alter table foo rename to bar ). two psql clients were running, accessing the same database and, in some cases, querying on the same table. when one tried to insert into one of the recently dropped-and-renamed tables, it produced an error saying that an attribute didnt exist for <old table's OID>. a restart of that app fixed it. fyi, the error was "get_attisset: no attribute requests in relation 902432" while doing an insert. a select statement just returned 0 rows, even though there were 1 or 2 matching the query ( verified in the psql window i was working in, doing the renames ). is this a known problem ? do the clients cache OIDs or some such ? is there anything i can do, apart from the obvious ( heh ), to make sure this doesnt happen again ? thanks in advance. --- Howie <caffeine@toodarkpark.org> URL: http://www.toodarkpark.org "Do a little dance, make a little code, compile tonight... compile tonight."
> > i was recently importing a fairly large amount of data from a mysql to > postgres ( 6.4.2 ). to make a long story short, this involved some > renames ( alter table foo rename to bar ). two psql clients were running, > accessing the same database and, in some cases, querying on the same > table. when one tried to insert into one of the recently > dropped-and-renamed tables, it produced an error saying that an attribute > didnt exist for <old table's OID>. a restart of that app fixed it. > > fyi, the error was "get_attisset: no attribute requests in relation > 902432" while doing an insert. a select statement just returned 0 rows, > even though there were 1 or 2 matching the query ( verified in the psql > window i was working in, doing the renames ). > > is this a known problem ? do the clients cache OIDs or some such ? is > there anything i can do, apart from the obvious ( heh ), to make sure > this doesnt happen again ? In 6.4.*, table renaming was not properly flushing the cache, I think. Should work fine when 6.5 is released. -- Bruce Momjian | http://www.op.net/~candle maillist@candle.pha.pa.us | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania 19026
On Mon, 31 May 1999, Bruce Momjian wrote: > > > > i was recently importing a fairly large amount of data from a mysql to > > postgres ( 6.4.2 ). to make a long story short, this involved some > > renames ( alter table foo rename to bar ). two psql clients were running, > > accessing the same database and, in some cases, querying on the same > > table. when one tried to insert into one of the recently > > dropped-and-renamed tables, it produced an error saying that an attribute > > didnt exist for <old table's OID>. a restart of that app fixed it. > > > > fyi, the error was "get_attisset: no attribute requests in relation > > 902432" while doing an insert. a select statement just returned 0 rows, > > even though there were 1 or 2 matching the query ( verified in the psql > > window i was working in, doing the renames ). > > > > is this a known problem ? do the clients cache OIDs or some such ? is > > there anything i can do, apart from the obvious ( heh ), to make sure > > this doesnt happen again ? > > In 6.4.*, table renaming was not properly flushing the cache, I think. > Should work fine when 6.5 is released. i had figured the client was caching OIDs. _really_ looking forward to 6.5, keep up the great work! --- Howie <caffeine@toodarkpark.org> URL: http://www.toodarkpark.org "Do a little dance, make a little code, compile tonight... compile tonight."
> > In 6.4.*, table renaming was not properly flushing the cache, I think. > > Should work fine when 6.5 is released. > > i had figured the client was caching OIDs. _really_ looking forward to > 6.5, keep up the great work! Yes, we had a number of cache issues worked on recently. The original problem I remember was that alter table add column did not see the new column in 6.4.2 sometimes. That is all working now. -- Bruce Momjian | http://www.op.net/~candle maillist@candle.pha.pa.us | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania 19026