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;
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
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
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
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
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
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
* 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
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
* 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
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
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
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
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
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.
* 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
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
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
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
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
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
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
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
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
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
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
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
27 matches
Mail list logo
