Обсуждение: ERROR: expected just one rule action
Can anyone interpret this error message?
It appears in response to each of the following queries in one
instance of PostgreSQL 8.3:
SELECT usecreatedb, usesuper, CASE WHEN usesuper THEN
pg_postmaster_start_time() ELSE NULL END as upsince FROM pg_user
WHERE usename=current_user ;
SELECT rolcreaterole, rolcreatedb FROM pg_roles WHERE rolname =
current_user;
SELECT setting FROM pg_settings WHERE name IN ('autovacuum',
'track_counts');
SELECT oid, *, pg_catalog.shobj_description(oid, 'pg_authid') AS
description FROM pg_roles WHERE NOT rolcanlogin ORDER BY rolname;
SELECT oid, *, pg_catalog.shobj_description(oid, 'pg_authid') AS
description FROM pg_roles WHERE rolcanlogin ORDER BY rolname;
These queries work fine in another instance of 8.3, so it's not the
queries themselves.
Dave Livesay <dlivesay@covad.net> writes:
> Can anyone interpret this error message?
Something's whacked out about your ON SELECT rules for these views.
Further than that is harder to say --- have you tried looking at
\d output for them, or looked into pg_rewrite?
> It appears in response to each of the following queries in one
> instance of PostgreSQL 8.3:
What's the history of that instance?
regards, tom lane
The history is rather interesting. :-) This is the first version of PostgreSQL provided by a certain very helpful fellow, who has been making PostgreSQL binaries available for us Mac users for years, since he upgraded to Mac OS X 10.5 (aka Leopard). I have not yet upgraded to Leopard, due to some serious compatibility problems it introduced, so I am testing this build for compatibility with Mac OS X 10.4 (aka Tiger). It is working flawlessly on my Intel Mac, but I'm encountering the errors previously mentioned on an older G4 Mac. Since there are so many variables involved--major PostgreSQL upgrade, major Mac OS X upgrade (yes, 10.4 -> 10.5 is a major upgrade ;-) ), support for two different processor families--I'm just trying to narrow down what he needs to look at, and your suggestions are very helpful. I hadn't tried any backslash commands, but someone else with a similar configuration said he was seeing errors with \du and other psql commands. I first noticed the problem when connecting to databases in PGAdmin3. (I'm a GUI-oriented user.) "SELECT * FROM pg_rewrite" seems to work fine. Thank you very much for your help! On Feb 10, 2008, at 12:42 PM, Tom Lane wrote: > Dave Livesay <dlivesay@covad.net> writes: >> Can anyone interpret this error message? > > Something's whacked out about your ON SELECT rules for these views. > Further than that is harder to say --- have you tried looking at > \d output for them, or looked into pg_rewrite? > >> It appears in response to each of the following queries in one >> instance of PostgreSQL 8.3: > > What's the history of that instance? > > regards, tom lane >
Dave Livesay <dlivesay@covad.net> writes:
> This is the first version of PostgreSQL provided by a certain very
> helpful fellow, who has been making PostgreSQL binaries available for
> us Mac users for years, since he upgraded to Mac OS X 10.5 (aka
> Leopard). I have not yet upgraded to Leopard, due to some serious
> compatibility problems it introduced, so I am testing this build for
> compatibility with Mac OS X 10.4 (aka Tiger). It is working
> flawlessly on my Intel Mac, but I'm encountering the errors
> previously mentioned on an older G4 Mac.
Hmm. I'm fairly confident that PG works fine on 10.4/PPC when built
on that platform, since (a) we have a build farm member testing that
case and (b) up till about a week ago I was testing that case
reasonably regularly on my own laptop. (Now I'm using 10.5.)
So what it sounds like to me is a tools compatibility problem.
It's odd that you'd see a problem only here and not all over the
place ... have you tried running the regression tests against this
build?
regards, tom lane
On Feb 10, 2008, at 2:21 PM, Tom Lane wrote: > Dave Livesay <dlivesay@covad.net> writes: >> This is the first version of PostgreSQL provided by a certain very >> helpful fellow, who has been making PostgreSQL binaries available for >> us Mac users for years, since he upgraded to Mac OS X 10.5 (aka >> Leopard). I have not yet upgraded to Leopard, due to some serious >> compatibility problems it introduced, so I am testing this build for >> compatibility with Mac OS X 10.4 (aka Tiger). It is working >> flawlessly on my Intel Mac, but I'm encountering the errors >> previously mentioned on an older G4 Mac. > > Hmm. I'm fairly confident that PG works fine on 10.4/PPC when built > on that platform, since (a) we have a build farm member testing that > case and (b) up till about a week ago I was testing that case > reasonably regularly on my own laptop. (Now I'm using 10.5.) > So what it sounds like to me is a tools compatibility problem. > It's odd that you'd see a problem only here and not all over the > place ... have you tried running the regression tests against this > build? > > regards, tom lane I'm sure it has something to do with the complex build environment and getting up to speed with the new tools. If you have some experience with the Leopard tools, maybe he could post his questions here if he can't figure it out. Or maybe I should just figure out how to build it.
Dave Livesay <dlivesay@covad.net> writes:
> I'm sure it has something to do with the complex build environment
> and getting up to speed with the new tools.
FWIW, I just verified that your queries work fine for me in CVS HEAD
on a G4, under both 10.4 (building with Xcode 2.5) and 10.5 (building
with Xcode 3.0). So it does seem likely that it's the 10.5-back-to-10.4
business that's the problem. I know zip about that aspect of things,
though.
If these are "universal" (Intel+PPC) binaries, that could be an issue
too. There's been some discussion recently about how to build universal
binaries for PG, but I don't think anyone's figured out a really nice
way to do it.
regards, tom lane
On Feb 10, 2008 10:51 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote: > If these are "universal" (Intel+PPC) binaries, that could be an issue > too. There's been some discussion recently about how to build universal > binaries for PG, but I don't think anyone's figured out a really nice > way to do it. If the endianess isn't corrected for the non-native platform at build time, I've seen initdb leave a cluster with a completely broken pg_rewrite (iirc). -- Dave Page EnterpriseDB UK: http://www.enterprisedb.com The Oracle-compatible database company
"Dave Page" <dpage@pgadmin.org> writes:
> If the endianess isn't corrected for the non-native platform at build
> time, I've seen initdb leave a cluster with a completely broken
> pg_rewrite (iirc).
Hmm, but is pg_rewrite really the most obvious symptom? In 8.3 I would
expect massive breakage all over, because of the varvarlena stuff's
sensitivity to endianness.
regards, tom lane
On Feb 11, 2008 4:28 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote: > "Dave Page" <dpage@pgadmin.org> writes: > > If the endianess isn't corrected for the non-native platform at build > > time, I've seen initdb leave a cluster with a completely broken > > pg_rewrite (iirc). > > Hmm, but is pg_rewrite really the most obvious symptom? In 8.3 I would > expect massive breakage all over, because of the varvarlena stuff's > sensitivity to endianness. It was what we found first upon investigating why my first attempts at building a universal binary failed. A quick test with pgAdmin threw an odd error following a select from a view. We eventually realised that the query trees in ev_action were all blank if memory serves. Greg might remember more... -- Dave Page EnterpriseDB UK: http://www.enterprisedb.com The Oracle-compatible database company
"Dave Page" <dpage@pgadmin.org> writes:
> On Feb 11, 2008 4:28 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> "Dave Page" <dpage@pgadmin.org> writes:
>>> If the endianess isn't corrected for the non-native platform at build
>>> time, I've seen initdb leave a cluster with a completely broken
>>> pg_rewrite (iirc).
>>
>> Hmm, but is pg_rewrite really the most obvious symptom? In 8.3 I would
>> expect massive breakage all over, because of the varvarlena stuff's
>> sensitivity to endianness.
> It was what we found first upon investigating why my first attempts at
> building a universal binary failed.
Okay, then that definitely suggests that this is a theory for Dave L.
to pursue. In a universal build you need to do ./configure twice to
generate two different pg_config.h files. I imagine his "helpful
fellow" knew that already, if he'd been able to generate universal
binaries with Xcode 2.5, but maybe 3.0 is messing it up somehow.
regards, tom lane