Robert Haas writes:
> On Wed, Dec 24, 2014 at 1:35 PM, Euler Taveira 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 messages if the new GUC (say
>> server_
Robert Haas writes:
> On Sat, Dec 27, 2014 at 7:55 PM, Tom Lane 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 though for people who
>> disable autov
On Sat, Dec 27, 2014 at 7:55 PM, Tom Lane wrote:
> Heikki Linnakangas 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
On Wed, Dec 24, 2014 at 1:35 PM, Euler Taveira 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 parse some error m
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 11:20 AM, Andres Freund 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 tps, lat 0.195 ms st
On Wed, Dec 24, 2014 at 8:12 AM, Peter Eisentraut 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 stil
Heikki Linnakangas 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 like everybod
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;
> > }
>
On Sat, Dec 27, 2014 at 06:26:02PM -0500, Tom Lane wrote:
> Stephen Frost 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.
Stephen Frost 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 just to confus
* 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
On Sat, Dec 27, 2014 at 11:48 AM, Jeff Janes 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. In general, I s
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 Tue, Dec 23, 2014 at 11:55 AM, Peter Geoghegan wrote:
> On Thu, Dec 18, 2014 at 9:20 AM, Jeff Janes 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 elaborate, please? What are th
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 s
Stephen Frost 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
>>> or not
* Simon Riggs (si...@2ndquadrant.com) wrote:
> On 27 December 2014 at 08:47, Abhijit Menon-Sen 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 au
On 27 December 2014 at 08:47, Abhijit Menon-Sen 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 improves that considerab
* 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 b
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 ti
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 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
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 25 December 2014 at 10:42, Abhijit Menon-Sen 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 not fully realis
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 t
On 25 December 2014 at 17:09, Jaime Casanova wrote:
> On Thu, Dec 25, 2014 at 5:42 AM, Abhijit Menon-Sen
> 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;
>>
>> ...and the server would audit
27 matches
Mail list logo
