Re: [HACKERS] pgaudit - an auditing extension for PostgreSQL

2014-12-27 Thread Simon Riggs
On 25 December 2014 at 17:09, Jaime Casanova ja...@2ndquadrant.com wrote: On Thu, Dec 25, 2014 at 5:42 AM, Abhijit Menon-Sen a...@2ndquadrant.com wrote: To summarise for people who haven't followed the thread in detail, the idea is that you would do: grant select on foo to audit;

Re: [HACKERS] CATUPDATE confusion?

2014-12-27 Thread Noah Misch
On Mon, Nov 24, 2014 at 04:28:46PM -0500, Adam Brightwell wrote: So, where I find this confusing is that the documentation supports this functionality and the check keeps superuser separate from CATUPDATE... however... comments and implementation in user.c state/do the opposite and couple them

Re: [HACKERS] pgaudit - an auditing extension for PostgreSQL

2014-12-27 Thread Simon Riggs
On 25 December 2014 at 10:42, Abhijit Menon-Sen a...@2ndquadrant.com wrote: Stephen likes the idea, obviously; Simon also said he liked it, but I now wonder if he may have liked the part I implemented (which allows a hot standby to have a different auditing configuration than the primary) but

Re: [HACKERS] pgaudit - an auditing extension for PostgreSQL

2014-12-27 Thread Abhijit Menon-Sen
At 2014-12-27 08:08:32 +, si...@2ndquadrant.com wrote: what if i want to audit different things for different users? That is supported - you can provide a list of roles to be audit roles. You can do that, but maybe it isn't quite enough to do what Jaime is asking for. Not always, at

Re: [HACKERS] Serialization exception : Who else was involved?

2014-12-27 Thread Noah Misch
On Tue, Dec 02, 2014 at 11:17:43AM +0100, Olivier MATROT wrote: Serialization conflict detection is done in src/backend/storage/lmgr/predicate.c, where transactions that are doomed to fail are marked as such with the SXACT_FLAG_DOOMED flag. I simply added elog(...) calls with the NOTIFY

Re: [HACKERS] Serialization exception : Who else was involved?

2014-12-27 Thread Craig Ringer
On 12/02/2014 06:17 PM, Olivier MATROT wrote: I was wondering if there was a log level in PostgreSQL that could tell me which query was the trigger of a doomed transaction. It's not necessarily possible to tell which *query* in another transaction caused the current one to fail. It might not

Re: [HACKERS] Serialization exception : Who else was involved?

2014-12-27 Thread Craig Ringer
On 12/02/2014 06:17 PM, Olivier MATROT wrote: Serialization conflict detection is done in *src/backend/storage/lmgr/predicate.c*, where transactions that are doomed to fail are marked as such with *the SXACT_FLAG_DOOMED* flag. I simply added elog(...) calls with the NOTIFY level, each time

Re: [HACKERS] CATUPDATE confusion?

2014-12-27 Thread Stephen Frost
* Noah Misch (n...@leadboat.com) wrote: On Mon, Nov 24, 2014 at 04:28:46PM -0500, Adam Brightwell wrote: Perhaps this is not an issue but it seemed odd to me, especially after giving Peter's comment more thought. So, I suppose the question is whether or not a superuser check should be

Re: [HACKERS] pgaudit - an auditing extension for PostgreSQL

2014-12-27 Thread Simon Riggs
On 27 December 2014 at 08:47, Abhijit Menon-Sen a...@2ndquadrant.com wrote: But there's no way to say *don't* audit select on foo by simon. We can cover what it does and does not do in some doc examples. When submitted, pgaudit didn't have very complex auditing rules. Stephen's suggestion

Re: [HACKERS] pgaudit - an auditing extension for PostgreSQL

2014-12-27 Thread Stephen Frost
* Simon Riggs (si...@2ndquadrant.com) wrote: On 27 December 2014 at 08:47, Abhijit Menon-Sen a...@2ndquadrant.com wrote: But there's no way to say *don't* audit select on foo by simon. We can cover what it does and does not do in some doc examples. When submitted, pgaudit didn't have

Re: [HACKERS] CATUPDATE confusion?

2014-12-27 Thread Tom Lane
Stephen Frost sfr...@snowman.net writes: * Noah Misch (n...@leadboat.com) wrote: On Mon, Nov 24, 2014 at 04:28:46PM -0500, Adam Brightwell wrote: Perhaps this is not an issue but it seemed odd to me, especially after giving Peter's comment more thought. So, I suppose the question is whether

Re: [HACKERS] Better way of dealing with pgstat wait timeout during buildfarm runs?

2014-12-27 Thread Heikki Linnakangas
On 12/27/2014 12:16 AM, Alvaro Herrera wrote: Tom Lane wrote: The argument that autovac workers need fresher stats than anything else seems pretty dubious to start with. Why shouldn't we simplify that down to they use PGSTAT_STAT_INTERVAL like everybody else? The point of wanting fresher

Re: [HACKERS] INSERT ... ON CONFLICT {UPDATE | IGNORE}

2014-12-27 Thread Jeff Janes
On Tue, Dec 23, 2014 at 11:55 AM, Peter Geoghegan p...@heroku.com wrote: On Thu, Dec 18, 2014 at 9:20 AM, Jeff Janes jeff.ja...@gmail.com wrote: I've put this through an adaptation of my usual torture test, and it ran fine until wraparound shutdown. I'll poke at it more later. Could you

[HACKERS] Re: Using RTLD_DEEPBIND to handle symbol conflicts in loaded libraries

2014-12-27 Thread Noah Misch
On Wed, Nov 26, 2014 at 01:34:18PM +0200, Ants Aasma wrote: glibc-2.3.4+ has a flag called RTLD_DEEPBIND for dlopen that prefers symbols loaded by the library to those provided by the caller. Using this flag fixes my issue, PostgreSQL gets the ldap functions from libldap, Oracle client gets

Re: [HACKERS] INSERT ... ON CONFLICT {UPDATE | IGNORE}

2014-12-27 Thread Peter Geoghegan
On Sat, Dec 27, 2014 at 11:48 AM, Jeff Janes jeff.ja...@gmail.com wrote: Could you elaborate, please? What are the details of the torture test you're performing? The gist of it is that I increment a count column of a random row (via pk) in multiple connections simultaneously. This is great.

Re: [HACKERS] CATUPDATE confusion?

2014-12-27 Thread Stephen Frost
* Tom Lane (t...@sss.pgh.pa.us) wrote: Plan C (remove CATUPDATE altogether) also has some merit. But adding a superuser override there would be entirely pointless. This is be my recommendation. I do not see the point of carrying the option around just to confuse new users of pg_authid and

Re: [HACKERS] CATUPDATE confusion?

2014-12-27 Thread Tom Lane
Stephen Frost sfr...@snowman.net writes: * Tom Lane (t...@sss.pgh.pa.us) wrote: Plan C (remove CATUPDATE altogether) also has some merit. But adding a superuser override there would be entirely pointless. This is be my recommendation. I do not see the point of carrying the option around

Re: [HACKERS] CATUPDATE confusion?

2014-12-27 Thread Noah Misch
On Sat, Dec 27, 2014 at 06:26:02PM -0500, Tom Lane wrote: Stephen Frost sfr...@snowman.net writes: * Tom Lane (t...@sss.pgh.pa.us) wrote: Plan C (remove CATUPDATE altogether) also has some merit. But adding a superuser override there would be entirely pointless. This is be my

Re: [HACKERS] Initdb-cs_CZ.WIN-1250 buildfarm failures

2014-12-27 Thread Noah Misch
On Tue, Dec 23, 2014 at 03:32:59PM +0100, Tomas Vondra wrote: On 23.12.2014 15:21, Andrew Dunstan wrote: No, config_opts is what's passed to configure. Try something like: if ($branch eq 'REL9_0_STABLE') { $skip_steps{'pl-install-check'} = 1; } Applied to

Re: [HACKERS] Better way of dealing with pgstat wait timeout during buildfarm runs?

2014-12-27 Thread Tom Lane
Heikki Linnakangas hlinnakan...@vmware.com writes: On 12/27/2014 12:16 AM, Alvaro Herrera wrote: Tom Lane wrote: The argument that autovac workers need fresher stats than anything else seems pretty dubious to start with. Why shouldn't we simplify that down to they use PGSTAT_STAT_INTERVAL

Re: [HACKERS] pg_basebackup fails with long tablespace paths

2014-12-27 Thread Robert Haas
On Wed, Dec 24, 2014 at 8:12 AM, Peter Eisentraut pete...@gmx.net wrote: On 12/22/14 10:00 PM, Amit Kapila wrote: There is already a patch [1] in this CF which will handle both cases, so I am not sure if it is very good idea to go with a new tar format to handle this issue. I think it would

Re: [HACKERS] Misaligned BufferDescriptors causing major performance problems on AMD

2014-12-27 Thread Robert Haas
On Wed, Dec 24, 2014 at 11:20 AM, Andres Freund and...@2ndquadrant.com wrote: I just verified that I can still reproduce the problem: # aligned case (max_connections=401) afreund@axle:~$ pgbench -P 1 -h /tmp/ -p5440 postgres -n -M prepared -c 96 -j 96 -T 100 -S progress: 1.0 s, 405170.2

[HACKERS] Re: Better way of dealing with pgstat wait timeout during buildfarm runs?

2014-12-27 Thread Noah Misch
On Thu, Dec 25, 2014 at 09:14:36PM +0100, Andres Freund wrote: My guess is that a checkpoint happened at that time. Maybe it'd be a good idea to make pg_regress start postgres with log_checkpoints enabled? My guess is that we'd find horrendous 'sync' times. +1, independent of $SUBJECT. How

Re: [HACKERS] nls and server log

2014-12-27 Thread Robert Haas
On Wed, Dec 24, 2014 at 1:35 PM, Euler Taveira eu...@timbira.com.br wrote: Currently the same message goes to server log and client app. Sometimes it bothers me since I have to analyze server logs and discovered that lc_messages is set to pt_BR and to worse things that stup^H^H^H application

Re: [HACKERS] Better way of dealing with pgstat wait timeout during buildfarm runs?

2014-12-27 Thread Robert Haas
On Sat, Dec 27, 2014 at 7:55 PM, Tom Lane t...@sss.pgh.pa.us wrote: Heikki Linnakangas hlinnakan...@vmware.com writes: On 12/27/2014 12:16 AM, Alvaro Herrera wrote: Tom Lane wrote: The argument that autovac workers need fresher stats than anything else seems pretty dubious to start with. Why

Re: [HACKERS] Better way of dealing with pgstat wait timeout during buildfarm runs?

2014-12-27 Thread Tom Lane
Robert Haas robertmh...@gmail.com writes: On Sat, Dec 27, 2014 at 7:55 PM, Tom Lane t...@sss.pgh.pa.us wrote: This would have the effect of transferring all responsibility for dead-stats-entry cleanup to autovacuum. For ordinary users, I think that'd be just fine. It might be less fine

Re: [HACKERS] nls and server log

2014-12-27 Thread Tom Lane
Robert Haas robertmh...@gmail.com writes: On Wed, Dec 24, 2014 at 1:35 PM, Euler Taveira eu...@timbira.com.br wrote: Currently the same message goes to server log and client app. ... I'm thinking to carry both translated and untranslated messages if we ask to. We store the untranslated