Thanks Scott.
Good answer, I was consolidating the schemas here, there were too many users
were granted permission to tables.I wanted to consolidate/optimize to bring
it to one role and granting this role to the user (same way as you
mentioned).
Thanks for the solution.
Thanks
Deepak
On Wed, Ap
On Wed, Apr 22, 2009 at 5:01 PM, Scott Marlowe wrote:
> On Wed, Apr 22, 2009 at 4:19 PM, DM wrote:
>> how to revoke multiple users permission from multiple tables at the same
>> time?
>> Or in simple is there a way to revoke multiple users grant access from
>> multiple tables under a schema.?
>
>
On Wed, Apr 22, 2009 at 4:19 PM, DM wrote:
> how to revoke multiple users permission from multiple tables at the same
> time?
> Or in simple is there a way to revoke multiple users grant access from
> multiple tables under a schema.?
Best way is to NOT grant multiple users permissions, but to gra
how to revoke multiple users permission from multiple tables at the same
time?
Or in simple is there a way to revoke multiple users grant access from
multiple tables under a schema.?
I use Revoke below command to execute on each table one by one.
revoke SELECT/ALL on testtable from user1;
Thanks
Scott Marlowe writes:
> On Wed, Apr 22, 2009 at 2:28 PM, Atul Chojar wrote:
>> Any ideas why above update is not working?
> Any possibility you're doing the updates to an inherited table, or a
> table in a different schema or a different database than you think?
Another possibility is that the
On Wed, Apr 22, 2009 at 2:28 PM, Atul Chojar wrote:
> We are facing a strange problem in our 8.2.7 database.
>
> There is a bash shell script that does:-
>
> sql="select distinct to_char(date_of_issue, 'MM') from
> yan.int_prod_s_master order by 1;"
> MM=`/usr/local/pgsql/bin/psql -U postg
We are facing a strange problem in our 8.2.7 database.
There is a bash shell script that does:-
sql="select distinct to_char(date_of_issue, 'MM') from
yan.int_prod_s_master order by 1;"
MM=`/usr/local/pgsql/bin/psql -U postgres -h payday -d sandbox -t -c
"$sql"`
for x in $MM
do
$scr
Shrirang Chitnis writes:
> I see that an auto vacuum process that has started on April 08 is still
> continuing till date on a production server that I manage.
> A) Is there a way to know whether the process is still running or is stalled?
strace the process for a few minutes and see if it does
All,
I see that an auto vacuum process that has started on April 08 is still
continuing till date on a production server that I manage.
Some statistics related to the process are as listed below. The queries are
below statistics.
1) ps -aux | grep ^postgres
postgres 24188 0.0 2.4 14038764 8
"Maria L. Wilson" writes:
> Question - is there any maintenance type item that we could to to check
> for uncommitted transactions on a regular basis - outside of the
> pg_prepared_xacts table?
pg_prepared_xacts is the only SQL-level visibility there is. From a
monitoring standpoint it might
On Wed, 2009-04-22 at 13:10 -0400, Maria L. Wilson wrote:
> wow - I am finally back in business!!
> Question - is there any maintenance type item that we could to to check
> for uncommitted transactions on a regular basis - outside of the
> pg_prepared_xacts table?
>How about from a dev
wow - I am finally back in business!!
Tom - the answer to your question is yes - these uncommitted
transactions blocked the vacuuming. As soon as i got around getting the
uncommitted transactions rollbacked - the vacuuming worked and things
seemed fine. One other little thing i had was a cor
Maria L. Wilson wrote:
> yes - how do i get rid of these??
>
> backend> select * from pg_prepared_xacts;
> 2009-04-22 07:43:27.421 EDT [11767] [] WARNING: database "ange" must
> be vacuumed within 976080 transactions
> 2009-04-22 07:43:27.421 EDT [11767] [] HINT: To avoid a database
> shu
"Maria L. Wilson" writes:
> yes - how do i get rid of these??
Either COMMIT PREPARED or ROLLBACK PREPARED, depending on whether
you think you want those old transactions to take effect or not.
(Personally I'd go for ROLLBACK --- if you did not even know those
transactions were open, you probably
yes - how do i get rid of these??
backend> select * from pg_prepared_xacts;
2009-04-22 07:43:27.421 EDT [11767] [] WARNING: database "ange" must
be vacuumed within 976080 transactions
2009-04-22 07:43:27.421 EDT [11767] [] HINT: To avoid a database
shutdown, execute a full-database VACUUM
15 matches
Mail list logo
