Обсуждение: Old problem needs solution
Greetings! At some point, I'm not even sure when, I apparently had a bad upgrade on one of my production databases. I'm in a situation now where I've got my back up against a wall and not sure what to do. The problem is, I'm receiving this message frequently: did not find '}' at end of input node I am currently running version 7.4.7 and am trying to migrate on up to 8. The data is completely available to the application (large forums database is primary concern), but I can't back it up or do anything with it aside from let it dig itself deeper. Does anybody have a suggestion on how to fix this, or some way around it? I could probably write a script to suck all my data out and push it back in, but I'm hoping and praying there's something better out there, hopefully a real honest to goodness fix for it ; ) Thanks, G
Gerald D. Anderson wrote: > Greetings! > > At some point, I'm not even sure when, I apparently had a bad upgrade on > one of my production databases. I'm in a situation now where I've got > my back up against a wall and not sure what to do. The problem is, I'm > receiving this message frequently: > > did not find '}' at end of input node When? > I am currently running version 7.4.7 and am trying to migrate on up to > 8. The data is completely available to the application (large forums > database is primary concern), but I can't back it up or do anything with > it aside from let it dig itself deeper. Can you pg_dump individual tables (with -t my_table_name) -- Richard Huxton Archonet Ltd
data # pg_dump -Fc -f blah.txt -tforums_auth forums22 -u User name: postgres Password: pg_dump: SQL command failed pg_dump: Error message from server: ERROR: did not find '}' at end of input node pg_dump: The command was: SELECT (SELECT usename FROM pg_user WHERE usesysid = datdba) as dba, pg_encoding_to_char(encoding) as encoding, datpath FROM pg_database WHERE datname = 'forums22' That help? As far as when, pretty much anytime I do anything. My guess is messed up metadata. G Richard Huxton wrote: > Gerald D. Anderson wrote: > >> Greetings! >> >> At some point, I'm not even sure when, I apparently had a bad upgrade >> on one of my production databases. I'm in a situation now where I've >> got my back up against a wall and not sure what to do. The problem >> is, I'm receiving this message frequently: >> >> did not find '}' at end of input node > > > When? > >> I am currently running version 7.4.7 and am trying to migrate on up >> to 8. The data is completely available to the application (large >> forums database is primary concern), but I can't back it up or do >> anything with it aside from let it dig itself deeper. > > > Can you pg_dump individual tables (with -t my_table_name) >
On Wed, Jun 01, 2005 at 10:24:25AM -0500, Gerald D. Anderson wrote: > Greetings! > > At some point, I'm not even sure when, I apparently had a bad upgrade on > one of my production databases. I'm in a situation now where I've got > my back up against a wall and not sure what to do. The problem is, I'm > receiving this message frequently: > > did not find '}' at end of input node Are you using Gentoo? Are you using the hierarchical queries patch? Were you using any of the above in the previous Postgres version? If this is the case, you will have to get the old postmaster again, and run it against your data directory, and use that to make the dump. The reload it in the new directory. The problem with the hierarchical queries patch (which Gentoo applies to some of their builds) is that it doesn't include the necessary catalog-version increment. So people can use the same data directory with or without the patch applied, which is a mistake because it causes the errors you are seeing. -- Alvaro Herrera (<alvherre[a]surnet.cl>) "Use it up, wear it out, make it do, or do without"
Gerald D. Anderson wrote: > data # pg_dump -Fc -f blah.txt -tforums_auth forums22 -u User > name: postgres > Password: > pg_dump: SQL command failed > pg_dump: Error message from server: ERROR: did not find '}' at end of > input node > pg_dump: The command was: SELECT (SELECT usename FROM pg_user WHERE > usesysid = datdba) as dba, pg_encoding_to_char(encoding) as encoding, > datpath FROM pg_database WHERE datname = 'forums22' > > That help? As far as when, pretty much anytime I do anything. My guess > is messed up metadata. Yep - I'm guessing it's an issue with an array (group membership?) in pg_user. Can you SELECT * FROM pg_user? -- Richard Huxton Archonet Ltd
Richard Huxton <dev@archonet.com> writes:
> Yep - I'm guessing it's an issue with an array (group membership?) in
> pg_user.
No, I'll bet lunch that Alvaro fingered the correct culprit: either
addition or subtraction of that darn hierarchical-query patch. It
changes the on-disk representation of view rules in a way that produces
exactly this failure mode.
One of the disadvantages of open source is that you can't prevent people
from breaking your software :-(
regards, tom lane
Ok, well it looks like Richard owes Tom a lunch, or that's my best guess anyway. I am running Gentoo, as far as that particular patch, I'm unsure, but if it's installed by default then yes. So, I've pulled down the earliest ebuild I can get which is 7.3.6. Get it installed and go to start it: FATAL: The data directory was initialized by PostgreSQL version 7.4, which is not compatible with this version 7.3.6. So, the plot thickens. Is there somewhere I can go tweak a few bytes to make it think it's 7.3? Also, is 7.3 going to be early enough? This database has been around for years, and like I said, I'm not sure when this happened : / Truly appreciate the help guys! g Alvaro Herrera wrote: >On Wed, Jun 01, 2005 at 10:24:25AM -0500, Gerald D. Anderson wrote: > > >>Greetings! >> >>At some point, I'm not even sure when, I apparently had a bad upgrade on >>one of my production databases. I'm in a situation now where I've got >>my back up against a wall and not sure what to do. The problem is, I'm >>receiving this message frequently: >> >>did not find '}' at end of input node >> >> > >Are you using Gentoo? Are you using the hierarchical queries patch? >Were you using any of the above in the previous Postgres version? > >If this is the case, you will have to get the old postmaster again, and >run it against your data directory, and use that to make the dump. The >reload it in the new directory. > >The problem with the hierarchical queries patch (which Gentoo applies to >some of their builds) is that it doesn't include the necessary >catalog-version increment. So people can use the same data directory >with or without the patch applied, which is a mistake because it causes >the errors you are seeing. > > >
"Gerald D. Anderson" <gander@vte.com> writes:
> So, the plot thickens. Is there somewhere I can go tweak a few bytes to
> make it think it's 7.3?
No. That's not what you want anyway; you want a late 7.4 build, just
one without the hierarchical-queries patch. I dunno enough about Gentoo
to say how you get rid of a patch you don't want, but if it's anything
like RPMs, you can just dike the patch out of the specfile and rebuild.
regards, tom lane
On Fri, 3 Jun 2005 12:38 am, Tom Lane wrote: > "Gerald D. Anderson" <gander@vte.com> writes: > > So, the plot thickens. Is there somewhere I can go tweak a few bytes to > > make it think it's 7.3? > > No. That's not what you want anyway; you want a late 7.4 build, just > one without the hierarchical-queries patch. I dunno enough about Gentoo > to say how you get rid of a patch you don't want, but if it's anything > like RPMs, you can just dike the patch out of the specfile and rebuild. > USE="-pg-hier" emerge -vp =postgresql-7.4.7-r2 Will do the job on gentoo. It's not enabled by default unless somebody has put pg-hier somewhere in the use flags. Regards Russell Smith > regards, tom lane > > ---------------------------(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 > >
Yup, was just going to respond this morning. It isn't enabled by default (at least in the ebuilds I've looked at). I've built it with pg_hier and without pg_hier and get the same results either way : / Might there be some other cause for this? Or even a dirty fix if this is what it is? Gerald Russell Smith wrote: >On Fri, 3 Jun 2005 12:38 am, Tom Lane wrote: > > >>"Gerald D. Anderson" <gander@vte.com> writes: >> >> >>>So, the plot thickens. Is there somewhere I can go tweak a few bytes to >>>make it think it's 7.3? >>> >>> >>No. That's not what you want anyway; you want a late 7.4 build, just >>one without the hierarchical-queries patch. I dunno enough about Gentoo >>to say how you get rid of a patch you don't want, but if it's anything >>like RPMs, you can just dike the patch out of the specfile and rebuild. >> >> >> >USE="-pg-hier" emerge -vp =postgresql-7.4.7-r2 > >Will do the job on gentoo. It's not enabled by default unless somebody has put >pg-hier somewhere in the use flags. > >Regards > >Russell Smith > > > > > >> regards, tom lane >> >>---------------------------(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 >> >> >> >> > > >
On Fri, Jun 03, 2005 at 06:48:06AM -0500, Gerald D. Anderson wrote:
> Yup, was just going to respond this morning. It isn't enabled by
> default (at least in the ebuilds I've looked at). I've built it with
> pg_hier and without pg_hier and get the same results either way : /
> Might there be some other cause for this? Or even a dirty fix if this
> is what it is?
Hmm, maybe there's another problem then. I don't know what can it be
though. Please post the result of
select ev_action from pg_rewrite where ev_class = 'pg_user'::regclass;
Mine, for a vanilla 7.4 installation, is
ev_action | ({QUERY :commandType 1 :querySource 0 :canSetTag true :utilityStmt <> :resultRelation 0 :into <> :hasAggs
false:hasSubLinks
false :rtable ({RTE :alias {ALIAS :aliasname *OLD* :colnames <>} :eref {ALIAS :aliasname *OLD* :colnames ("usename"
"usesysid""usecreatedb"
"usesuper" "usecatupd" "passwd" "valuntil" "useconfig")} :rtekind 0 :relid 16683 :inh false :inFromCl false
:checkForReadfalse
:checkForWrite false :checkAsUser 1} {RTE :alias {ALIAS :aliasname *NEW* :colnames <>} :eref {ALIAS :aliasname *NEW*
:colnames("usename"
"usesysid" "usecreatedb" "usesuper" "usecatupd" "passwd" "valuntil" "useconfig")} :rtekind 0 :relid 16683 :inh false
:inFromClfalse
:checkForRead false :checkForWrite false :checkAsUser 1} {RTE :alias <> :eref {ALIAS :aliasname pg_shadow :colnames
("usename""usesysid"
"usecreatedb" "usesuper" "usecatupd" "passwd" "valuntil" "useconfig")} :rtekind 0 :relid 1260 :inh true :inFromCl true
:checkForReadtrue
:checkForWrite false :checkAsUser 1}) :jointree {FROMEXPR :fromlist ({RANGETBLREF :rtindex 3}) :quals <>} :rowMarks ()
:targetList
({TARGETENTRY :resdom {RESDOM :resno 1 :restype 19 :restypmod -1 :resname usename :ressortgroupref 0 :resorigtbl 1260
:resorigcol1 :resjunk
false} :expr {VAR :varno 3 :varattno 1 :vartype 19 :vartypmod -1 :varlevelsup 0 :varnoold 3 :varoattno 1}} {TARGETENTRY
:resdom{RESDOM
:resno 2 :restype 23 :restypmod -1 :resname usesysid :ressortgroupref 0 :resorigtbl 1260 :resorigcol 2 :resjunk false}
:expr{VAR :varno 3
:varattno 2 :vartype 23 :vartypmod -1 :varlevelsup 0 :varnoold 3 :varoattno 2}} {TARGETENTRY :resdom {RESDOM :resno 3
:restype16 :restypmod
-1 :resname usecreatedb :ressortgroupref 0 :resorigtbl 1260 :resorigcol 3 :resjunk false} :expr {VAR :varno 3 :varattno
3:vartype 16
:vartypmod -1 :varlevelsup 0 :varnoold 3 :varoattno 3}} {TARGETENTRY :resdom {RESDOM :resno 4 :restype 16 :restypmod -1
:resnameusesuper
:ressortgroupref 0 :resorigtbl 1260 :resorigcol 4 :resjunk false} :expr {VAR :varno 3 :varattno 4 :vartype 16
:vartypmod-1 :varlevelsup 0
:varnoold 3 :varoattno 4}} {TARGETENTRY :resdom {RESDOM :resno 5 :restype 16 :restypmod -1 :resname usecatupd
:ressortgroupref0 :resorigtbl
1260 :resorigcol 5 :resjunk false} :expr {VAR :varno 3 :varattno 5 :vartype 16 :vartypmod -1 :varlevelsup 0 :varnoold 3
:varoattno5}}
{TARGETENTRY :resdom {RESDOM :resno 6 :restype 25 :restypmod -1 :resname passwd :ressortgroupref 0 :resorigtbl 0
:resorigcol0 :resjunk
false} :expr {CONST :consttype 25 :constlen -1 :constbyval false :constisnull false :constvalue 12 [ 12 0 0 0 42 42 42
4242 42 42 42 ]}}
{TARGETENTRY :resdom {RESDOM :resno 7 :restype 702 :restypmod -1 :resname valuntil :ressortgroupref 0 :resorigtbl 1260
:resorigcol7
:resjunk false} :expr {VAR :varno 3 :varattno 7 :vartype 702 :vartypmod -1 :varlevelsup 0 :varnoold 3 :varoattno 7}}
{TARGETENTRY:resdom
{RESDOM :resno 8 :restype 1009 :restypmod -1 :resname useconfig :ressortgroupref 0 :resorigtbl 1260 :resorigcol 8
:resjunkfalse} :expr {VAR
:varno 3 :varattno 8 :vartype 1009 :vartypmod -1 :varlevelsup 0 :varnoold 3 :varoattno 8}}) :groupClause <> :havingQual
<>:distinctClause
<> :sortClause <> :limitOffset <> :limitCount <> :setOperations <> :resultRelations ()})
--
Alvaro Herrera (<alvherre[a]surnet.cl>)
"Aprender sin pensar es inútil; pensar sin aprender, peligroso" (Confucio)
Ok, you're over my head now so I'm just going to post the results in the
hope that something clicks. Here ya go:
({QUERY :commandType 1 :querySource 0 :canSetTag true :utilityStmt <>
:resultRelation 0 :into <> :hasAggs false :hasSubLinks false :rtable
({RTE :alias {ALIAS :aliasname *OLD* :colnames <>} :eref {ALIAS
:aliasname *OLD* :colnames ("usename" "usesysid" "usecreatedb"
"usesuper" "usecatupd" "passwd" "valuntil" "useconfig")} :rtekind 0
:relid 16683 :inh false :inFromCl false :checkForRead false
:checkForWrite false :checkAsUser 1} {RTE :alias {ALIAS :aliasname *NEW*
:colnames <>} :eref {ALIAS :aliasname *NEW* :colnames ("usename"
"usesysid" "usecreatedb" "usesuper" "usecatupd" "passwd" "valuntil"
"useconfig")} :rtekind 0 :relid 16683 :inh false :inFromCl false
:checkForRead false :checkForWrite false :checkAsUser 1} {RTE :alias <>
:eref {ALIAS :aliasname pg_shadow :colnames ("usename" "usesysid"
"usecreatedb" "usesuper" "usecatupd" "passwd" "valuntil" "useconfig")}
:rtekind 0 :relid 1260 :inh true :inFromCl true :checkForRead true
:checkForWrite false :checkAsUser 1}) :jointree {FROMEXPR :fromlist
({RANGETBLREF :rtindex 3}) :quals <>} :rowMarks () :targetList
({TARGETENTRY :resdom {RESDOM :resno 1 :restype 19 :restypmod -1
:resname usename :ressortgroupref 0 :resorigtbl 1260 :resorigcol 1
:resjunk false} :expr {VAR :varno 3 :varattno 1 :vartype 19 :vartypmod
-1 :varlevelsup 0 :varnoold 3 :varoattno 1}} {TARGETENTRY :resdom
{RESDOM :resno 2 :restype 23 :restypmod -1 :resname usesysid
:ressortgroupref 0 :resorigtbl 1260 :resorigcol 2 :resjunk false} :expr
{VAR :varno 3 :varattno 2 :vartype 23 :vartypmod -1 :varlevelsup 0
:varnoold 3 :varoattno 2}} {TARGETENTRY :resdom {RESDOM :resno 3
:restype 16 :restypmod -1 :resname usecreatedb :ressortgroupref 0
:resorigtbl 1260 :resorigcol 3 :resjunk false} :expr {VAR :varno 3
:varattno 3 :vartype 16 :vartypmod -1 :varlevelsup 0 :varnoold 3
:varoattno 3}} {TARGETENTRY :resdom {RESDOM :resno 4 :restype 16
:restypmod -1 :resname usesuper :ressortgroupref 0 :resorigtbl 1260
:resorigcol 4 :resjunk false} :expr {VAR :varno 3 :varattno 4 :vartype
16 :vartypmod -1 :varlevelsup 0 :varnoold 3 :varoattno 4}} {TARGETENTRY
:resdom {RESDOM :resno 5 :restype 16 :restypmod -1 :resname usecatupd
:ressortgroupref 0 :resorigtbl 1260 :resorigcol 5 :resjunk false} :expr
{VAR :varno 3 :varattno 5 :vartype 16 :vartypmod -1 :varlevelsup 0
:varnoold 3 :varoattno 5}} {TARGETENTRY :resdom {RESDOM :resno 6
:restype 25 :restypmod -1 :resname passwd :ressortgroupref 0 :resorigtbl
0 :resorigcol 0 :resjunk false} :expr {CONST :consttype 25 :constlen -1
:constbyval false :constisnull false :constvalue 12 [ 12 0 0 0 42 42 42
42 42 42 42 42 ]}} {TARGETENTRY :resdom {RESDOM :resno 7 :restype 702
:restypmod -1 :resname valuntil :ressortgroupref 0 :resorigtbl 1260
:resorigcol 7 :resjunk false} :expr {VAR :varno 3 :varattno 7 :vartype
702 :vartypmod -1 :varlevelsup 0 :varnoold 3 :varoattno 7}} {TARGETENTRY
:resdom {RESDOM :resno 8 :restype 1009 :restypmod -1 :resname useconfig
:ressortgroupref 0 :resorigtbl 1260 :resorigcol 8 :resjunk false} :expr
{VAR :varno 3 :varattno 8 :vartype 1009 :vartypmod -1 :varlevelsup 0
:varnoold 3 :varoattno 8}}) :groupClause <> :havingQual <>
:distinctClause <> :sortClause <> :limitOffset <> :limitCount <>
:hierClause <> :setOperations <> :resultRelations ()})
That help? *cringe*
Again, I REALLY appreciate your time!
Gerald
Alvaro Herrera wrote:
>On Fri, Jun 03, 2005 at 06:48:06AM -0500, Gerald D. Anderson wrote:
>
>
>>Yup, was just going to respond this morning. It isn't enabled by
>>default (at least in the ebuilds I've looked at). I've built it with
>>pg_hier and without pg_hier and get the same results either way : /
>>Might there be some other cause for this? Or even a dirty fix if this
>>is what it is?
>>
>>
>
>Hmm, maybe there's another problem then. I don't know what can it be
>though. Please post the result of
>
>select ev_action from pg_rewrite where ev_class = 'pg_user'::regclass;
>
>Mine, for a vanilla 7.4 installation, is
>
>
>ev_action | ({QUERY :commandType 1 :querySource 0 :canSetTag true :utilityStmt <> :resultRelation 0 :into <> :hasAggs
false:hasSubLinks
>false :rtable ({RTE :alias {ALIAS :aliasname *OLD* :colnames <>} :eref {ALIAS :aliasname *OLD* :colnames ("usename"
"usesysid""usecreatedb"
>"usesuper" "usecatupd" "passwd" "valuntil" "useconfig")} :rtekind 0 :relid 16683 :inh false :inFromCl false
:checkForReadfalse
>:checkForWrite false :checkAsUser 1} {RTE :alias {ALIAS :aliasname *NEW* :colnames <>} :eref {ALIAS :aliasname *NEW*
:colnames("usename"
>"usesysid" "usecreatedb" "usesuper" "usecatupd" "passwd" "valuntil" "useconfig")} :rtekind 0 :relid 16683 :inh false
:inFromClfalse
>:checkForRead false :checkForWrite false :checkAsUser 1} {RTE :alias <> :eref {ALIAS :aliasname pg_shadow :colnames
("usename""usesysid"
>"usecreatedb" "usesuper" "usecatupd" "passwd" "valuntil" "useconfig")} :rtekind 0 :relid 1260 :inh true :inFromCl true
:checkForReadtrue
>:checkForWrite false :checkAsUser 1}) :jointree {FROMEXPR :fromlist ({RANGETBLREF :rtindex 3}) :quals <>} :rowMarks ()
:targetList
>({TARGETENTRY :resdom {RESDOM :resno 1 :restype 19 :restypmod -1 :resname usename :ressortgroupref 0 :resorigtbl 1260
:resorigcol1 :resjunk
>false} :expr {VAR :varno 3 :varattno 1 :vartype 19 :vartypmod -1 :varlevelsup 0 :varnoold 3 :varoattno 1}}
{TARGETENTRY:resdom {RESDOM
>:resno 2 :restype 23 :restypmod -1 :resname usesysid :ressortgroupref 0 :resorigtbl 1260 :resorigcol 2 :resjunk false}
:expr{VAR :varno 3
>:varattno 2 :vartype 23 :vartypmod -1 :varlevelsup 0 :varnoold 3 :varoattno 2}} {TARGETENTRY :resdom {RESDOM :resno 3
:restype16 :restypmod
>-1 :resname usecreatedb :ressortgroupref 0 :resorigtbl 1260 :resorigcol 3 :resjunk false} :expr {VAR :varno 3
:varattno3 :vartype 16
>:vartypmod -1 :varlevelsup 0 :varnoold 3 :varoattno 3}} {TARGETENTRY :resdom {RESDOM :resno 4 :restype 16 :restypmod
-1:resname usesuper
>:ressortgroupref 0 :resorigtbl 1260 :resorigcol 4 :resjunk false} :expr {VAR :varno 3 :varattno 4 :vartype 16
:vartypmod-1 :varlevelsup 0
>:varnoold 3 :varoattno 4}} {TARGETENTRY :resdom {RESDOM :resno 5 :restype 16 :restypmod -1 :resname usecatupd
:ressortgroupref0 :resorigtbl
>1260 :resorigcol 5 :resjunk false} :expr {VAR :varno 3 :varattno 5 :vartype 16 :vartypmod -1 :varlevelsup 0 :varnoold
3:varoattno 5}}
>{TARGETENTRY :resdom {RESDOM :resno 6 :restype 25 :restypmod -1 :resname passwd :ressortgroupref 0 :resorigtbl 0
:resorigcol0 :resjunk
>false} :expr {CONST :consttype 25 :constlen -1 :constbyval false :constisnull false :constvalue 12 [ 12 0 0 0 42 42 42
4242 42 42 42 ]}}
>{TARGETENTRY :resdom {RESDOM :resno 7 :restype 702 :restypmod -1 :resname valuntil :ressortgroupref 0 :resorigtbl 1260
:resorigcol7
>:resjunk false} :expr {VAR :varno 3 :varattno 7 :vartype 702 :vartypmod -1 :varlevelsup 0 :varnoold 3 :varoattno 7}}
{TARGETENTRY:resdom
>{RESDOM :resno 8 :restype 1009 :restypmod -1 :resname useconfig :ressortgroupref 0 :resorigtbl 1260 :resorigcol 8
:resjunkfalse} :expr {VAR
>:varno 3 :varattno 8 :vartype 1009 :vartypmod -1 :varlevelsup 0 :varnoold 3 :varoattno 8}}) :groupClause <>
:havingQual<> :distinctClause
><> :sortClause <> :limitOffset <> :limitCount <> :setOperations <> :resultRelations ()})
>
>
>
>
On Fri, Jun 03, 2005 at 05:55:36PM -0500, Gerald D. Anderson wrote:
> Ok, you're over my head now so I'm just going to post the results in the
> hope that something clicks. Here ya go:
Ok, I diff'ed both and guess what:
("a" is your output, "b" is mine)
07:19 drizzt ~ 0$ diff a b
38c38
< :limitCount <> :hierClause <> :setOperations <> :resultRelations ()})
---
> :limitCount <> :setOperations <> :resultRelations ()})
So we now have confirmed that the problem is the hierarchical queries
patch.
> That help? *cringe*
I guess your build with the "use flag" wasn't successful. I think you
have two choices:
1. really build with the patch installed, and dump your data using that
2. Make an update of pg_rewrite in order to get rid of that. I think
this is easier, but you should be very careful not to corrupt the table.
I'd start by doing a CREATE TABLE AS to copy the contents of pg_rewrite
somewhere else, just in case you screw it up. Then come up with some
clever UPDATE query to remove the extraneous ":hierClause <> " part.
--
Alvaro Herrera (<alvherre[a]surnet.cl>)
"In Europe they call me Niklaus Wirth; in the US they call me Nickel's worth.
That's because in Europe they call me by name, and in the US by value!"
Hrm, well, proof's in the pudding I guess. I went back and rebuilt with
pg-hier after reading this and I'm seeing the results you expect, seems
to be working. I don't know what I did yesterday, but I wasn't paying
attention somewhere. Currently working on backing up a test db, then
will try the production if successful. I'll let you guys know.
Thanks again!
Gerald
Alvaro Herrera wrote:
>On Fri, Jun 03, 2005 at 05:55:36PM -0500, Gerald D. Anderson wrote:
>
>
>>Ok, you're over my head now so I'm just going to post the results in the
>>hope that something clicks. Here ya go:
>>
>>
>
>Ok, I diff'ed both and guess what:
>
>("a" is your output, "b" is mine)
>
>07:19 drizzt ~ 0$ diff a b
>38c38
>< :limitCount <> :hierClause <> :setOperations <> :resultRelations ()})
>---
>
>
>>:limitCount <> :setOperations <> :resultRelations ()})
>>
>>
>
>So we now have confirmed that the problem is the hierarchical queries
>patch.
>
>
>
>>That help? *cringe*
>>
>>
>
>I guess your build with the "use flag" wasn't successful. I think you
>have two choices:
>
>1. really build with the patch installed, and dump your data using that
>
>2. Make an update of pg_rewrite in order to get rid of that. I think
>this is easier, but you should be very careful not to corrupt the table.
>I'd start by doing a CREATE TABLE AS to copy the contents of pg_rewrite
>somewhere else, just in case you screw it up. Then come up with some
>clever UPDATE query to remove the extraneous ":hierClause <> " part.
>
>
>
On Sat, 4 Jun 2005 09:25 am, Alvaro Herrera wrote: > On Fri, Jun 03, 2005 at 05:55:36PM -0500, Gerald D. Anderson wrote: [snip] > > I guess your build with the "use flag" wasn't successful. I think you > have two choices: > > 1. really build with the patch installed, and dump your data using that Given the number of reports we have had about this specific bug on the lists. I have take the time to submit a bug directly to the gentoo project. Hopefully that can fit it properly and we will not see this happening again. For reference the bug is at: http://bugs.gentoo.org/show_bug.cgi?id=94965
Ok, that did it. All fixed up and upgraded to 8. The command for gentoo to rebuild WITH the pg-hier patch is (for those that might see this question again): # USE="pg-hier" emerge "=postgresql-7.4.7-r2" -vD # or whatever latest 7.x version is at that time. Backup the data, etc. Then when you're done just # emerge postgresql -vD to update to the latest version which SHOULD NOT have the patch enabled by default. Do another initdb and restore your data. I'm wondering how it got there in the first place. Wonder if there was a bad release where that flag was enabled by default. Oh well, better now. Thanks for all the help! G Russell Smith wrote: >On Sat, 4 Jun 2005 09:25 am, Alvaro Herrera wrote: > > >>On Fri, Jun 03, 2005 at 05:55:36PM -0500, Gerald D. Anderson wrote: >> >> >[snip] > > >>I guess your build with the "use flag" wasn't successful. I think you >>have two choices: >> >>1. really build with the patch installed, and dump your data using that >> >> > >Given the number of reports we have had about this specific bug on the lists. >I have take the time to submit a bug directly to the gentoo project. Hopefully >that can fit it properly and we will not see this happening again. > >For reference the bug is at: >http://bugs.gentoo.org/show_bug.cgi?id=94965 > > >