* Joe Conway ([EMAIL PROTECTED]) wrote:
> Stephen Frost wrote:
> >I've already submitted a patch which should correct this. It also adds
> >a new SQL function which determines if a given user is in a specific
> >role. It also implements SET ROLE, CURRENT_ROLE and SYSTEM_USER.
>
> Oh, cool. Sorry
Stephen Frost wrote:
Is this something we should worry about? Or do we just put a warning in
the docs?
I've already submitted a patch which should correct this. It also adds
a new SQL function which determines if a given user is in a specific
role. It also implements SET ROLE, CURRENT_ROLE an
* Joe Conway ([EMAIL PROTECTED]) wrote:
> Roles cause a problem for the information schema view table_privileges.
Right.
[...]
> Is this something we should worry about? Or do we just put a warning in
> the docs?
I've already submitted a patch which should correct this. It also adds
a new SQ
Roles cause a problem for the information schema view table_privileges.
For example:
CREATE TABLE tbl_1
(
f1int,
f2text
);
INSERT INTO tbl_1 VALUES(1, 'a');
REVOKE ALL ON tbl_1 FROM public;
CREATE USER user1;
CREATE USER user2;
CREATE ROLE role1;
GRANT ALL ON tbl_1 TO role1;
G
On Sat, Jul 09, 2005 at 11:43:52PM +0300, Hannu Krosing wrote:
> Could the new file not be made to cover the next available 1GB of file
> space, that is a new physical file ?
>
> This could made using of same kind of machinery my proposal for
> concurrent index does (i.e. locks that forbid puttin
On L, 2005-07-09 at 09:47 -0400, Mike Mascari wrote:
> Stephen Frost wrote:
>
> > delete from x;/truncate x;
> > --> Creates a new, empty, file and makes it the 'current' file
> > --> Marks the old file for deletion, but it is kept around for any
> > transactions which were started befor
On R, 2005-07-08 at 14:45 -0400, Tom Lane wrote:
> Simon Riggs <[EMAIL PROTECTED]> writes:
> > I don't think we should care too much about indexes. We can rebuild
> > them...but losing heap sectors means *data loss*.
There might be some merit in idea to disabling WAL/PITR for indexes,
where one ca
Stephen Frost wrote:
To give 'testuser' the rights of 'testrole' you should do:
grant testrole to testuser;
This is because create role, alter role, alter user, etc, use the
same set of options (since there's a large overlap) in the syntax,
though some things don't make sense for some of thos
* Joe Conway ([EMAIL PROTECTED]) wrote:
> After months of being unable to keep up with what's going on here, I'm
> trying to educate myself on some of the latest developments. I was
> playing with roles a bit, and I don't know if I'm doing something wrong,
> or if I found a hole:
Things have ch
After months of being unable to keep up with what's going on here, I'm
trying to educate myself on some of the latest developments. I was
playing with roles a bit, and I don't know if I'm doing something wrong,
or if I found a hole:
works fine:
regression=# create role testrole2 with user test
Stephen Frost <[EMAIL PROTECTED]> writes:
> * Mike Mascari (mascarm@mascari.com) wrote:
>> And when the transaction that issued the TRUNCATE aborts after step 3,
>> but newer transactions commit?
> The newer transactions would have to check for that situation.
How would they do that? They might
* Mike Mascari (mascarm@mascari.com) wrote:
> Stephen Frost wrote:
>
> >delete from x;/truncate x;
> > --> Creates a new, empty, file and makes it the 'current' file
> > --> Marks the old file for deletion, but it is kept around for any
> > transactions which were started before the truncat
Stephen Frost wrote:
delete from x;/truncate x;
--> Creates a new, empty, file and makes it the 'current' file
--> Marks the old file for deletion, but it is kept around for any
transactions which were started before the truncate;
--> New transactions use the empty file
--> Once al
Does truncate not being MVCC-safe cause problems in your situation? It
certainly doesn't in mine and I expect the same is true for alot of
others in the same situation.
Well, it is done inside a transaction, plus has concurrent use...
Chris
---(end of broadcast)---
14 matches
Mail list logo
