* 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 s
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 curren
* 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
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
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 w
* 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 sugg
* 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 rev
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 co
* 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 tha
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 ba
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 ha
* 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 (le
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 Blan
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
i
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)
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 Fro
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
"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.
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
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 t
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 men
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
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 pro
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 investig
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.
T
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)
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
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
autova
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 x
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
30 matches
Mail list logo
