[BUGS] BUG #3261: autovacuum starts regarding config setting
The following bug has been logged online: Bug reference: 3261 Logged by: Evgeny Gridasov Email address: [EMAIL PROTECTED] PostgreSQL version: 8.2.4-CVS Operating system: Linux Description:autovacuum starts regarding config setting Details: Hello, autovacuum starts even if autovacuum=off is set in config file, I've checked it through 'show autovacuum' and see it off. But still there is an autovacuum process vacuuming the tables. is this 8.2.4 CVS-only issue? CVS checkout was yesterday at about 15:00-16:00 GMT Evgeny. ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [BUGS] BUG #3261: autovacuum starts regarding config setting
Evgeny Gridasov wrote: autovacuum starts even if autovacuum=off is set in config file, I've checked it through 'show autovacuum' and see it off. But still there is an autovacuum process vacuuming the tables. Even when you disable autovacuum with autovacuum=off, it's still launched to prevent xid wraparound. See the documentation on xid wrap-around: http://www.postgresql.org/docs/8.2/interactive/routine-vacuuming.html#VACUUM-FOR-WRAPAROUND and on the autovacuum_freeze_max_age configuration variable for more information. is this 8.2.4 CVS-only issue? No. It's a new feature in the 8.2. -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [BUGS] BUG #3261: autovacuum starts regarding config setting
Please CC the list to allow others to participate in the discussion, and to have it archived for future readers... Evgeny Gridasov wrote: I've seen it analyzing and vacuuming some tables for a long time... Is it OK? The reason I'm asking I was dump-restoring a huge database, and disabled autovacuum in config file. Well, to avoid XID wrap-around, you have to run (auto)vacuum eventually. If you don't mind that your clog files will take up more disk space, as you probably don't if you have a huge database anyways, you can increase autovacuum_freeze_max_age so you don't need to run it as often. But I'm starting to wonder if it was the XID wraparound that triggered the autovacuum after all. You did restart postmaster after setting autovacuum=off in the config file, right? That's required for the setting to take effect. What table is it vacuuming? A recently restored table shouldn't need to be vacuumed for a long time. -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com ---(end of broadcast)--- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate
Re: [BUGS] BUG #3261: autovacuum starts regarding config setting
Heikki, Yes, I did restart postmaster after setting autovacuum=off as I've mentioned before I've checked it using show autovacuum. It was vacuuming a table from the old database while the server was running pg_dump -U postgres old_base | psql new_base postgres Sorry for missing the CC, I had a bad night sleep (actually dump-restored db =) On Fri, 04 May 2007 11:57:25 +0100 Heikki Linnakangas <[EMAIL PROTECTED]> wrote: > Please CC the list to allow others to participate in the discussion, and > to have it archived for future readers... > > Evgeny Gridasov wrote: > > I've seen it analyzing and vacuuming some tables for a long time... > > Is it OK? > > The reason I'm asking I was dump-restoring a huge database, and disabled > > autovacuum in config file. > > Well, to avoid XID wrap-around, you have to run (auto)vacuum eventually. > If you don't mind that your clog files will take up more disk space, as > you probably don't if you have a huge database anyways, you can increase > autovacuum_freeze_max_age so you don't need to run it as often. > > But I'm starting to wonder if it was the XID wraparound that triggered > the autovacuum after all. You did restart postmaster after setting > autovacuum=off in the config file, right? That's required for the > setting to take effect. > > What table is it vacuuming? A recently restored table shouldn't need to > be vacuumed for a long time. > > -- >Heikki Linnakangas >EnterpriseDB http://www.enterprisedb.com > ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [BUGS] PGSQL - WARNING: 25P01: there is no transaction in progress
Even desactivate Auto-vacuum didn't fix my issue. Is there any place where I can see past transactions or transactions in queue that hasn't been processed ? Thank you, On 2 mai, 10:02, [EMAIL PROTECTED] (Alvaro Herrera) wrote: > DNS escribió: > > > On 27 avr, 19:17, [EMAIL PROTECTED] (Tom Lane) wrote: > > > > This is just a warning, which most likely is there only because somebody > > > typed COMMIT or ABORT unnecessarily. What problem are you actually > > > having? > > > No one is working on the database when come up the warning. The > > warning makes us worrier about the database but nothing serious on > > database side. > > This is not possible. The server does not send this message all by > itself. Maybe the driver or connection pooler you are using is sending > a ROLLBACK command when it connects, to "clear up" the connection or > something like that. > > -- > Alvaro Herrerahttp://www.CommandPrompt.com/ > The PostgreSQL Company - Command Prompt, Inc. ---(end of broadcast)--- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate
Re: [BUGS] PGSQL - WARNING: 25P01: there is no transaction in progress
DNS wrote: Even desactivate Auto-vacuum didn't fix my issue. Is there any place where I can see past transactions or transactions in queue that hasn't been processed ? You could put log_statement = all to your postgresql.conf. That'll log every statement sent to the server to the log file. There's no other way to see past statements from the server side. There's no such thing as a queue of transactions. -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [BUGS] PGSQL - WARNING: 25P01: there is no transaction in progress
DNS escribió: > Even desactivate Auto-vacuum didn't fix my issue. I don't think anybody ever suggested that autovacuum had something to do with it. > Is there any place > where I can see past transactions or transactions in queue that hasn't > been processed ? Why are you bothering with investigating transactions when the message states perfectly clearly that there is no transaction involved? -- Alvaro Herrerahttp://www.CommandPrompt.com/ PostgreSQL Replication, Consulting, Custom Development, 24x7 support ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [BUGS] PGSQL - WARNING: 25P01: there is no transaction in progress
Thanks alot, log_statement = all shows where come the errors. On 4 mai, 10:49, [EMAIL PROTECTED] (Heikki Linnakangas) wrote: > DNS wrote: > > Even desactivate Auto-vacuum didn't fix my issue. Is there any place > > where I can see past transactions or transactions in queue that hasn't > > been processed ? > > You could put log_statement = all to your postgresql.conf. That'll log > every statement sent to the server to the log file. > > There's no other way to see past statements from the server side. > There's no such thing as a queue of transactions. > > -- >Heikki Linnakangas >EnterpriseDB http://www.enterprisedb.com ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [BUGS] Grantor name gets lost when grantor role dropped
Alvaro Herrera <[EMAIL PROTECTED]> writes: > So I'm currently considering the following alternatives: > 1. do nothing at all with pg_shdepend. Upon role deletion, seqscan > pg_auth_members and reject the drop altogether if there is a role > granted to another which mentions the to-be-dropped role ID as grantor. > This is easiest in terms of code (it's even mentioned in the comments in > DropRole). > 2. record one pg_shdepend entry for each role that has granted something > to each role (unless the grantor is the same role being granted, in > which case we needn't record anything). So if role A grants Z and X to > C, and role B grants Y and W to C, C now has access to W, Y, X and Z and > there are two pg_shdepend entries: > C -> A > C -> B > So dropping a role would be disallowed automatically without any code > changes, with the checkSharedDependencies() call that's already in > DropRole. Adding a role membership would require a bit more work, > because we'd first need to check that there's not already a pg_shdepend > entry for that combination. Removing a role membership also becomes > more work; we need to check that no other grant depends on the same > grantor before removing the entry. Both of these have got race conditions ... not but what the dependency code has got race condition problems already, but maybe we should try to avoid introducing more? I haven't got any better ideas though. Why is it that we record grantor at all? One could argue that granting membership in a role is done on behalf of that role and there's no real need to remember exactly who did it. regards, tom lane ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [BUGS] Grantor name gets lost when grantor role dropped
Tom Lane wrote: > Alvaro Herrera <[EMAIL PROTECTED]> writes: > > So I'm currently considering the following alternatives: > > > 1. do nothing at all with pg_shdepend. Upon role deletion, seqscan > > pg_auth_members and reject the drop altogether if there is a role > > granted to another which mentions the to-be-dropped role ID as grantor. > > This is easiest in terms of code (it's even mentioned in the comments in > > DropRole). > > > 2. record one pg_shdepend entry for each role that has granted something > > to each role (unless the grantor is the same role being granted, in > > which case we needn't record anything). So if role A grants Z and X to > > C, and role B grants Y and W to C, C now has access to W, Y, X and Z and > > there are two pg_shdepend entries: > > C -> A > > C -> B > > So dropping a role would be disallowed automatically without any code > > changes, with the checkSharedDependencies() call that's already in > > DropRole. Adding a role membership would require a bit more work, > > because we'd first need to check that there's not already a pg_shdepend > > entry for that combination. Removing a role membership also becomes > > more work; we need to check that no other grant depends on the same > > grantor before removing the entry. > > Both of these have got race conditions ... not but what the dependency > code has got race condition problems already, but maybe we should try > to avoid introducing more? I haven't got any better ideas though. I couldn't parse this paragraph very well. However I'm not sure why you say the dependency code has got race conditions? We do lock the object before checking the dependencies, so it's not possible to add a new dependency while we're dropping the object. .. right? I'm going to have a look at it again. > Why is it that we record grantor at all? One could argue that granting > membership in a role is done on behalf of that role and there's no real > need to remember exactly who did it. I think you should ask Stephen Frost about that -- added to CC. If the grantor bit is not important, then what we should do is just omit emitting the GRANTED BY part in pg_dumpall, which fixes this report. -- Alvaro Herrerahttp://www.CommandPrompt.com/ The PostgreSQL Company - Command Prompt, Inc. ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [BUGS] Grantor name gets lost when grantor role dropped
Alvaro Herrera <[EMAIL PROTECTED]> writes: > Tom Lane wrote: >> Both of these have got race conditions ... not but what the dependency >> code has got race condition problems already, but maybe we should try >> to avoid introducing more? I haven't got any better ideas though. > I couldn't parse this paragraph very well. However I'm not sure why you > say the dependency code has got race conditions? We do lock the object > before checking the dependencies, so it's not possible to add a new > dependency while we're dropping the object. Sorry, I was thinking of the regular dependency code, which has open bug report(s) based on exactly the fact that there's no such locking. shdepend may be OK, since it's fundamentally only dealing in roles. >> Why is it that we record grantor at all? One could argue that granting >> membership in a role is done on behalf of that role and there's no real >> need to remember exactly who did it. > I think you should ask Stephen Frost about that -- added to CC. > If the grantor bit is not important, then what we should do is just omit > emitting the GRANTED BY part in pg_dumpall, which fixes this report. It's at least something we should reflect on before sweating hard to make it work... regards, tom lane ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [BUGS] order by question.
I'll try this question again. _ From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Jose Blanco Sent: Thursday, May 03, 2007 4:12 PM To: pgsql-bugs@postgresql.org Subject: [BUGS] order by question. I'm using version 7.3 of postgres and when I issue the following command select author, sort_author from itemsbyauthor where sort_author like 'tan%'; I get the following results: Author sort_author Tan, Weihong| tan, weihong Tang, S. C. | tang, s. c. Tan, Fang | tan, fang Note how the tan's are not grouped together when I think they should be. Is this something that is fixed in a more current version of postgres? Thank you!
Re: [BUGS] order by question.
"Jose Blanco" <[EMAIL PROTECTED]> writes: > I'll try this question again. The answer is the same as before: you didn't specify an ORDER BY clause, therefore there is no reason to expect any particular output ordering. Whatever ordering you might happen to see is an implementation artifact. regards, tom lane ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [BUGS] order by question.
This second time I did, see select author, sort_author from itemsbyauthor where sort_author like 'tan%' order by 2; "order by 2" Or am I not understanding something? Thanks! -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Tom Lane Sent: Friday, May 04, 2007 2:24 PM To: Jose Blanco Cc: pgsql-bugs@postgresql.org Subject: Re: [BUGS] order by question. "Jose Blanco" <[EMAIL PROTECTED]> writes: > I'll try this question again. The answer is the same as before: you didn't specify an ORDER BY clause, therefore there is no reason to expect any particular output ordering. Whatever ordering you might happen to see is an implementation artifact. regards, tom lane ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
[BUGS] Removing pg_auth_members.grantor (was Grantor name gets lost when grantor role dropped)
Tom Lane wrote: > Alvaro Herrera <[EMAIL PROTECTED]> writes: > >> Why is it that we record grantor at all? One could argue that granting > >> membership in a role is done on behalf of that role and there's no real > >> need to remember exactly who did it. > > > I think you should ask Stephen Frost about that -- added to CC. > > > If the grantor bit is not important, then what we should do is just omit > > emitting the GRANTED BY part in pg_dumpall, which fixes this report. > > It's at least something we should reflect on before sweating hard to > make it work... I took a look, and concluded that the only bit of code that uses the grantor at all is pg_dumpall. Does this means we can remove it altogether? In back branches, we would take out the pg_dumpall code. -- Alvaro Herrerahttp://www.CommandPrompt.com/ PostgreSQL Replication, Consulting, Custom Development, 24x7 support ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [BUGS] order by question.
Jose Blanco wrote: > This second time I did, see > > select author, sort_author from itemsbyauthor where sort_author like > 'tan%' order by 2; No, your posts didn't contain that query. -- Peter Eisentraut http://developer.postgresql.org/~petere/ ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [BUGS] order by question.
On Fri, 4 May 2007, Jose Blanco wrote: > This second time I did, see > > select author, sort_author from itemsbyauthor where sort_author like 'tan%' > order by 2; > > > "order by 2" > > Or am I not understanding something? One issue you might not realize is that the sort order for some locales ignore symbols and spaces for initial scans, so for example, you might find that "A Z" > "AB" while " " < "B". Specifically, for the data you gave, en_US would order them "tan, fang", "tang, s. c.", "tan, weihong" while C would order them "tan, fang", "tan, weihong", "tang, s. c.". ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [BUGS] order by question.
I'm not sure what you mean by "C" and how do I change this? -Original Message- From: Stephan Szabo [mailto:[EMAIL PROTECTED] Sent: Friday, May 04, 2007 3:38 PM To: Jose Blanco Cc: 'Tom Lane'; pgsql-bugs@postgresql.org Subject: Re: [BUGS] order by question. On Fri, 4 May 2007, Jose Blanco wrote: > This second time I did, see > > select author, sort_author from itemsbyauthor where sort_author like 'tan%' > order by 2; > > > "order by 2" > > Or am I not understanding something? One issue you might not realize is that the sort order for some locales ignore symbols and spaces for initial scans, so for example, you might find that "A Z" > "AB" while " " < "B". Specifically, for the data you gave, en_US would order them "tan, fang", "tang, s. c.", "tan, weihong" while C would order them "tan, fang", "tan, weihong", "tang, s. c.". ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [BUGS] Removing pg_auth_members.grantor (was Grantor name gets lost when grantor role dropped)
* Alvaro Herrera ([EMAIL PROTECTED]) wrote: > I took a look, and concluded that the only bit of code that uses the > grantor at all is pg_dumpall. > > Does this means we can remove it altogether? In back branches, we would > take out the pg_dumpall code. I don't have time right at the moment (leaving shortly and will be gone all weekend) but what I would do is check the SQL standard, especially the information schema, for any requirement to track the grantor. Much of what I did was based on the standard so that may have been the instigation for tracking grantor. Though, even without that, we track the grantor of most other grants (possibly all currently?) and it seems like a useful bit of information for DBAs to be able to know who granted what to whom. I can't say I've used it though, personally. Of course, I'll be pretty unhappy if a day comes when I do need it and it's not there. :) Thanks, Stephen signature.asc Description: Digital signature
Re: [BUGS] Removing pg_auth_members.grantor (was Grantor name gets lost when grantor role dropped)
Stephen Frost wrote: > I don't have time right at the moment (leaving shortly and will be gone > all weekend) but what I would do is check the SQL standard, especially > the information schema, for any requirement to track the grantor. Much > of what I did was based on the standard so that may have been the > instigation for tracking grantor. Hmm. I had forgotten the information schema. I just checked: the only view using pg_auth_members is APPLICABLE_ROLES, and that one doesn't display the grantor column. > Though, even without that, we track > the grantor of most other grants (possibly all currently?) and it seems > like a useful bit of information for DBAs to be able to know who granted > what to whom. I note that the grantor of ACLs are listed separately, for example in COLUMN_PRIVILEGES, ROLE_COLUMN_GRANTS, etc. -- Alvaro Herrerahttp://www.CommandPrompt.com/ The PostgreSQL Company - Command Prompt, Inc. ---(end of broadcast)--- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate
Re: [BUGS] Removing pg_auth_members.grantor (was Grantor name gets lost when grantor role dropped)
Alvaro Herrera wrote: > Stephen Frost wrote: > > > I don't have time right at the moment (leaving shortly and will be gone > > all weekend) but what I would do is check the SQL standard, especially > > the information schema, for any requirement to track the grantor. Much > > of what I did was based on the standard so that may have been the > > instigation for tracking grantor. > > Hmm. I had forgotten the information schema. I just checked: the only > view using pg_auth_members is APPLICABLE_ROLES, and that one doesn't > display the grantor column. This section of the standard is relevant: 4.34.3 Roles Each grant is represented and identified by a role authorization descriptor. A role authorization descriptor includes: — The role name of the role. — The of the grantor. — The of the grantee. — An indication of whether or not the role was granted with the WITH ADMIN OPTION and hence is grantable. ... continues reading the spec ... Ah, here it is, 12.7 . It says that if role revokes another role from a third role, it will only remove the privileges that were granted by him, not someone else. That is, if roles A and B grant a role Z to C, and then role A revokes Z from C, then role C continues to have the role Z because of the grant B gave. So we have a problem here, because this alvherre=# create role a; CREATE ROLE alvherre=# create role b; CREATE ROLE alvherre=# create role z admin a, b; CREATE ROLE alvherre=# create role c; CREATE ROLE alvherre=# set session authorization a; SET alvherre=> grant z to c; GRANT ROLE alvherre=> set session authorization b; SET alvherre=> grant z to c; NOTICE: role "c" is already a member of role "z" should not emit any noise, but instead add another grant of Z to C with grantor B. -- Alvaro Herrerahttp://www.CommandPrompt.com/ The PostgreSQL Company - Command Prompt, Inc. ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [BUGS] Removing pg_auth_members.grantor (was Grantor name gets lost when grantor role dropped)
* Alvaro Herrera ([EMAIL PROTECTED]) wrote: > Ah, here it is, 12.7 . It says that if role revokes > another role from a third role, it will only remove the privileges that > were granted by him, not someone else. Hmm. I'm not sure, but that may have been a case where it was generally decided that the spec was somewhat braindead in this fashion (it seems so in my personal view of this, honestly...). To issue a revoke and have it not work would be kind of concerning. If we do end up following this path we should emit a warning (at least...) if the user still has the rights which are being revoked, even if through someone else. Perhaps that also implies that tracking the grantor is unnecessary. Thanks, Stephen signature.asc Description: Digital signature
Re: [BUGS] Removing pg_auth_members.grantor (was Grantor name gets lost when grantor role dropped)
Stephen Frost <[EMAIL PROTECTED]> writes: > Hmm. I'm not sure, but that may have been a case where it was generally > decided that the spec was somewhat braindead in this fashion (it seems > so in my personal view of this, honestly...). To issue a revoke and > have it not work would be kind of concerning. If we do end up following > this path we should emit a warning (at least...) if the user still has > the rights which are being revoked, even if through someone else. That's not how it works for rights on ordinary objects. regards, tom lane ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [BUGS] Removing pg_auth_members.grantor (was Grantor name gets lost when grantor role dropped)
* Tom Lane ([EMAIL PROTECTED]) wrote:
> Stephen Frost <[EMAIL PROTECTED]> writes:
> > Hmm. I'm not sure, but that may have been a case where it was generally
> > decided that the spec was somewhat braindead in this fashion (it seems
> > so in my personal view of this, honestly...). To issue a revoke and
> > have it not work would be kind of concerning. If we do end up following
> > this path we should emit a warning (at least...) if the user still has
> > the rights which are being revoked, even if through someone else.
>
> That's not how it works for rights on ordinary objects.
Not quite sure which bit you're referring to here.. On 8.1, at least,
we ignore a grant which has a matching right and target:
sfrost=> set role u1;
sfrost=> \dp
Access privileges for database "sfrost"
Schema | Name | Type |Access privileges
+--+---+-
sfrost | test | table | {u1=arwdRxt/u1,u3=r/u1}
(1 row)
sfrost=> reset role;
RESET
sfrost=> set role u2;
SET
sfrost=> grant select on test to u3;
GRANT
sfrost=> \dp
Access privileges for database "sfrost"
Schema | Name | Type |Access privileges
+--+---+-
sfrost | test | table | {u1=arwdRxt/u1,u3=r/u1}
(1 row)
Additionally, any user with ownership rights on the table in question
can revoke the rights of a user. Still as u2:
sfrost=> revoke select on test from u3;
REVOKE
sfrost=> \dp
Access privileges for database "sfrost"
Schema | Name | Type | Access privileges
+--+---+---
sfrost | test | table | {u1=arwdRxt/u1}
(1 row)
If you're saying we don't currently warn if a revoke leaves the
priviledges in-tact for the right and target, I'm not sure you can
currently get in a state where it'd be possible to run into that.
Either you have the rights to remove the grant on the object
(you're an 'owner' of it), in which case the grant will be removed
if it exists (based on the right and target, regardless of who
granted it), or you don't, in which case you get a permission denied
ERROR outright. If regular object permissions were ever changed to
require the grantor to be the revoker, I would want a warning in the
case described for regular objects as well.
If you're saying we don't currently require that the grantor be the
revoker on regular objects, I would agree. :)
Thanks,
Stephen
signature.asc
Description: Digital signature
Re: [BUGS] order by question.
* Jose Blanco <[EMAIL PROTECTED]> [040507, 14:28]: > This second time I did, see > > select author, sort_author from itemsbyauthor where sort_author like 'tan%' > order by 2; > > > "order by 2" > > Or am I not understanding something? Hi Jose, have you tried to modify your query as others suggested? i.e.: --> select author, sort_author from itemsbyauthor where sort_author like 'tan% ORDER BY sort_author; HTH Regards, Ennio. -- [Perche' usare Win$ozz (dico io) se ..."anche uno sciocco sa farlo. \\?// Fa' qualche cosa di cui non sei capace!" (diceva Henry Miller) ](°|°) [Why use Win$ozz (I say) if ... "even a fool can do that. )=( Do something you aren't good at!" (as Henry Miller used to say) ] ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [BUGS] Removing pg_auth_members.grantor (was Grantor name gets lost when grantor role dropped)
Stephen Frost <[EMAIL PROTECTED]> writes: > If you're saying we don't currently warn if a revoke leaves the > priviledges in-tact for the right and target, I'm not sure you can > currently get in a state where it'd be possible to run into that. I'm thinking of the case that comes up periodically where newbies think that revoking a right from a particular user overrides a grant to PUBLIC of the same right. regards, tom lane ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [BUGS] Removing pg_auth_members.grantor (was Grantor name gets lost when grantor role dropped)
Based on the discussion so far, it seems to me that the sane course of action is to continue to register the grantor, because the standard mandates that it should be there; but ignore the parts where we revoke selectively, because that's a stupid thing to do. So we do deviate, if slightly. So we will have pg_dumpall do nothing special if the grantor has gone away since granting the privilege. That is, exactly the patch that was submitted, no new code needs to be written. (Maybe a mention in the "compatibility" section of REVOKE is warranted, though I'm not sure). Does anyone object to this course of action? -- Alvaro Herrerahttp://www.CommandPrompt.com/ PostgreSQL Replication, Consulting, Custom Development, 24x7 support ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [BUGS] Removing pg_auth_members.grantor (was Grantor name gets lost when grantor role dropped)
* Tom Lane ([EMAIL PROTECTED]) wrote: > Stephen Frost <[EMAIL PROTECTED]> writes: > > If you're saying we don't currently warn if a revoke leaves the > > priviledges in-tact for the right and target, I'm not sure you can > > currently get in a state where it'd be possible to run into that. > > I'm thinking of the case that comes up periodically where newbies think > that revoking a right from a particular user overrides a grant to PUBLIC > of the same right. Technically, the grant to public is a different target from the target of the revoke in such a case. Following the spec would mean that even when the grant and the revoke target is the same (unless you're the original grantor) the right won't be removed. I'm not against adding a warning in the case you describe though, but I don't see it being as necessary for that case. What the spec describes is, at least in my view, much more counter-intuitive than how PG currently works. Thanks, Stephen signature.asc Description: Digital signature
Re: [BUGS] order by question.
On Fri, 4 May 2007, Jose Blanco wrote: > I'm not sure what you mean by "C" and how do I change this? It's a locale name. The ordering is effectively byte order ordering, while many other locales like en_US have more interesting sorting rules. IIRC, the locale can only be set at initdb time currently, so changing it requires re-initialize the database directory. ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [BUGS] order by question.
* Ennio-Sr <[EMAIL PROTECTED]> [040507, 23:52]: > * Jose Blanco <[EMAIL PROTECTED]> [040507, 14:28]: > > This second time I did, see > > > > select author, sort_author from itemsbyauthor where sort_author like 'tan%' > > order by 2; > > > Hi Jose, > have you tried to modify your query as others suggested? i.e.: > > --> select author, sort_author from itemsbyauthor where sort_author like > 'tan%' ORDER BY sort_author; > Oops ... I missed your "order by 2" ... Sorry ;( -- [Perche' usare Win$ozz (dico io) se ..."anche uno sciocco sa farlo. \\?// Fa' qualche cosa di cui non sei capace!" (diceva Henry Miller) ](°|°) [Why use Win$ozz (I say) if ... "even a fool can do that. )=( Do something you aren't good at!" (as Henry Miller used to say) ] ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
