David Fetter wrote:
On Fri, Oct 30, 2009 at 08:51:57PM -0700, John R Pierce wrote:
Tom Lane wrote:
There is special-purpose software out there that can compute
exactly with rational numbers, but you aren't likely to find it
embedded in any general-purpose tools like databases --- the
us
Karen Pease wrote:
> Sorry for the delay in responding, and thanks for your help.
Sorry I have to keep on asking things. Unfortunately it's sometimes
quite hard to tell what part of a system is misbehaving, and it can
require the collection of quite a bit of diagnostic data :S
>From what I've see
"Jeff Janes" writes:
> Hash index is not concurrency safe, starting in REL8_4_0 and up to HEAD.
Ouch. This used to be okay, because adding new entries to a hash page
always added them at the end. The 8.4 changes to keep individual hash
pages sorted by hashcode broke it :-(.
I think we could re
On Sun, Nov 1, 2009 at 8:52 AM, Tom Lane wrote:
> "Jeff Janes" writes:
>> Hash index is not concurrency safe, starting in REL8_4_0 and up to HEAD.
>
> Ouch. This used to be okay, because adding new entries to a hash page
> always added them at the end. The 8.4 changes to keep individual hash
>
Jeff Janes writes:
> On Sun, Nov 1, 2009 at 8:52 AM, Tom Lane wrote:
>> I think we could recover by having the hashgettuple code path
>> re-synchronize by looking for the heap TID it previously returned.
> Can it get pushed to another page (an overflow page)? My quick
> reading of the code sugg
I wrote:
> Jeff Janes writes:
>> Hash index is not concurrency safe, starting in REL8_4_0 and up to HEAD.
> Ouch. This used to be okay, because adding new entries to a hash page
> always added them at the end. The 8.4 changes to keep individual hash
> pages sorted by hashcode broke it :-(.
Act
I wrote:
> Ugh. Mea culpa for letting this one through.
I've committed patches to fix this.
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
Q1: Who can explain the privilage of the superuser ?
In postgresql's document£¬Part VI. Reference,SQL Commands,GRANT, it said:
It should be noted that database superusers can access all objects
regardless of object privilege settings.
Q2: Why PostgreSQL check whether the view1'sowner had peivil
"hx.li" writes:
> In postgresql's document£¬Part VI. Reference,SQL Commands,GRANT, it said:
> It should be noted that database superusers can access all objects
> regardless of object privilege settings.
What that means in this example is that the superuser can select from
the view, even if the
I think it is right---the superuser can select from
the view, even if the view's owner tries to prevent that---,
but maybe a good way is checking owner's privilage when creating a view as
Oracle.
It would be better not to create a view if a user cann`t access a table.
regards, hx.li
"Tom Lane"
Hi Tom,
I agree with Hxli. It may be a good way to add permissions check when create
the view.
I also find 2 pieces of words in the document about the owner of the object.
"By default, only the owner of an object can do anything with the object."
"as the owner has all privileges by default
On 31/10/2009 4:32 PM, Karen Pease wrote:
> Sorry for the delay in responding, and thanks for your help.
By the way, you may also be able to learn some more using the 'blktrace'
tool. This gathers low-level data about what processes are performing
I/O on your system.
# mount -t debugfs none /sys/
12 matches
Mail list logo
