Klink, John | 1 Aug 01:00 2012
Picon

Grant Privliages Based on Unix Groups

I am trying to setup readonly access to my user groups.  I would like to grant select on a set of tables based on what Unix group they belong to.  This way when new users are added to a ronly group on the ldap server, I don’t have to go to each data base to update a local group on each postgres data base.

 

I realize you can create a groups and users in postgres and add users to groups.  I would like for postgres to grant or deny access based on the users Group ID on the system vs having to create and manage groups on each of my postgres data base servers.

 

Current version running is:

 

psql (PostgreSQL) 8.4.4

contains support for command-line editing

 

I have been searching but can’t find a reference to using unix groups to grant select, only references to groups created in postgres.

 

Thanks in advance.

 

John

Gary Webster | 1 Aug 17:43 2012

[pgsql] How bad is this full vacuum error?

Hello.

How bad is this?

2012-08-01 06:30:03 PDT 15961 [local] cp_repository_na2 ERROR:  missing chunk number 0 for toast value 1086399 in pg_toast_987417

2012-08-01 06:30:03 PDT 15961 [local] cp_repository_na2 STATEMENT:  VACUUM (FULL);


Does this mean I have db corruption, or just that the vacuum quit?

Thanks.

Kevin Grittner | 1 Aug 19:48 2012

Re: PostgreSQL oom_adj postmaster process to -17

Radovan Jablonovsky <radovan.jablonovsky <at> replicon.com> wrote:

> We are running PostgreSQL version 9.1.1

You should apply the latest bug fixes by updating to 9.1.4.

http://www.postgresql.org/support/versioning/

> with 32GB of RAM, 32GB of SWAP and during high load we could reach
> (swap + RAM) memory limit.

If you're even *starting* to swap you're doing something wrong, much
less exhausting swap space equal to actual RAM.  What is your
configuration?

http://wiki.postgresql.org/wiki/Server_Configuration

While it's probably a good idea to configure the OOM killer to
behave more sanely, we tend to ignore it in favor of ensuring that
it never comes into play.  We run about 200 databases 24/7 and I
think I've seen it kick in about twice -- when we ran queries that
leaked memory on each row in a big query.

-Kevin

--

-- 
Sent via pgsql-admin mailing list (pgsql-admin <at> postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-admin

Ascarabina | 1 Aug 21:05 2012
Picon

Re: Could You help me

On 25.07.2012 20:15, Joshua D. Drake wrote:
>
> You are going to need to install some HAC components, such as 
> pacemaker/corosync and automate the base backup creation for the old 
> master. It is not complicated but it is comprehensive.

I was also looking something like this. Is there any complate tutorial 
for postgresql 9+ ?

--

-- 
Sent via pgsql-admin mailing list (pgsql-admin <at> postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-admin

Alanoly Andrews | 1 Aug 21:42 2012

Re: pg_dump on Postgres 9.1

On this issue, instead of going for a newer version of xlc, as suggested, I opted to get a newer version of the
Postgres source code, 9.1.4. After compiling it with the same xlc version, I found that pg_dump works as
expected. So, the problem appears to be somewhere in the 9.1 source code, at least for binaries created
from it for AIX (6.1).

Regards.

Alanoly.

-----Original Message-----
From: Tom Lane [mailto:tgl <at> sss.pgh.pa.us] 
Sent: Friday, July 27, 2012 12:13 PM
To: Alanoly Andrews
Cc: 'pgsql-admin <at> postgresql.org'
Subject: Re: [ADMIN] pg_dump on Postgres 9.1

Alanoly Andrews <alanolya <at> invera.com> writes:
> Is there any reported bug with pg_dump in Postgres 9.1, on AIX ? The following command hangs for "ever" and
has to be interrupted. It creates a zero-length file.

We had a recent report of strange server-side behavior on AIX that went away after rebuilding with a newer
version of xlc, suggesting that the code was getting bitten by an xlc optimization bug.  Perhaps this is the
same thing inside pg_dump.  If you're not using the latest xlc, try updating.  If you are, does rebuilding
with -O0 change the behavior?

			regards, tom lane
****************************************************
This e-mail may be privileged and/or confidential, and the sender does not waive any related rights and
obligations. Any distribution, use or copying of this e-mail or the information it contains by other than
an intended recipient is unauthorized. If you received this e-mail in error, please advise me (by return
e-mail or otherwise) immediately.

Ce courriel est confidentiel et protégé. L'expéditeur ne renonce pas aux droits et obligations qui s'y
rapportent. Toute diffusion, utilisation ou copie de ce message ou des renseignements qu'il contient
par une personne autre que le (les) destinataire(s) désigné(s) est interdite. Si vous recevez ce
courriel par erreur, veuillez m'en aviser immédiatement, par retour de courriel ou par un autre moyen.
****************************************************

--

-- 
Sent via pgsql-admin mailing list (pgsql-admin <at> postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-admin

Gary Webster | 1 Aug 21:44 2012

simple question about two 'servers' on same OS

Hello.

When running two 'separate' instances of Postgres on the same machine (diff ports), do I also have two separate installs of the binaries (prefix), or only two separate datadir ?

If the former, should I make another "postgresb" superuser, or use the same one?

If I have two separate prefix dirs, & only one "postgres" superuser, which is its home dir, or does it matter?

Thanks.

Joshua D. Drake | 1 Aug 21:59 2012

Re: simple question about two 'servers' on same OS


On 08/01/2012 12:44 PM, Gary Webster wrote:
> Hello.
>
> When running two 'separate' instances of Postgres on the same machine
> (diff ports), do I also have two separate installs of the binaries
> (prefix),

No

> or only two separate datadir ?

Yes

> If I have two separate prefix dirs, & only one "postgres" superuser,
> which is its home dir, or does it matter?

Doesn't matter.

Sincerely,

Joshua D. Drake

-- 
Command Prompt, Inc. - http://www.commandprompt.com/
PostgreSQL Support, Training, Professional Services and Development
High Availability, Oracle Conversion, Postgres-XC
 <at> cmdpromptinc - 509-416-6579

--

-- 
Sent via pgsql-admin mailing list (pgsql-admin <at> postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-admin

Tom Lane | 1 Aug 22:18 2012
Picon

Re: [pgsql] How bad is this full vacuum error?

Gary Webster <webster <at> lexmark.com> writes:
> How bad is this?

> 2012-08-01 06:30:03 PDT 15961 [local] cp_repository_na2 ERROR:  missing
> chunk number 0 for toast value 1086399 in pg_toast_987417
> 2012-08-01 06:30:03 PDT 15961 [local] cp_repository_na2 STATEMENT:  VACUUM
> (FULL);

If it's repeatable, it's corrupted data :-(.  If it just happened once,
and doesn't recur on the next try, it might have been related to a system
catalog race condition that we fixed last fall.  (What PG version are you
running?)  I'm unsure about that though, because the toast table name
seems to indicate that it's for a user table not a system catalog, and
I'm not very sure why VACUUM would be doing toast dereferences into a
user table.

			regards, tom lane

--

-- 
Sent via pgsql-admin mailing list (pgsql-admin <at> postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-admin

Anibal David Acosta | 1 Aug 22:27 2012

Timeout error on pgstat

I have a lot (maybe 1 every 10 seconds) of this error WARNING:  pgstat wait timeout

 

Also this

ERROR:  canceling autovacuum task

 

In the pg_stat_activity show an autovacuum process over a very used table that runs about 1 hour and then this vacuum is cancelled (according to log)

 

I have Postgres 9.0.3 on a windows 2008 R2 running for about 1 year in same conditions, but this error is occurring about 1 week ago.

 

Thanks!!

Craig Ringer | 2 Aug 04:00 2012
Picon

Re: Timeout error on pgstat

On 08/02/2012 04:27 AM, Anibal David Acosta wrote:

I have a lot (maybe 1 every 10 seconds) of this error WARNING:  pgstat wait timeout

A quick search suggests this can be due to excessive I/O. However, this thread:

http://postgresql.1045698.n5.nabble.com/pgstat-wait-timeout-td5078125.html

sounds very similar to your issue. I'm wondering if there's a bug lurking in there somewhere.


In the pg_stat_activity show an autovacuum process over a very used table that runs about 1 hour and then this vacuum is cancelled (according to log)
Was there any context to the `cancelling autovacuum task' message?

 I have Postgres 9.0.3 on a windows 2008 R2 running for about 1 year in same conditions, but this error is occurring about 1 week ago.


The current 9.0 release is 9.0.8, so you're missing a bunch of bug fixes.

http://www.postgresql.org/docs/current/static/release-9-0-8.html

Consider updating. You don't need to do a dump and reload or use pg_upgrade, since it's only a minor version update. Stop the DB, install the new binaries, start the DB.

However, I don't see any fixes related to the stats writer in the relnotes from the 9.0 series.

--
Craig Ringer

Gmane