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
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 all
* 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 truncate;
--
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 be long
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
* 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
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
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 can
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 before the
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 putting
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;
* 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 SQL
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
* 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 for the
14 matches
Mail list logo
