On Sat, Aug 29, 2009 at 6:00 AM, Tom Lane wrote:
> Attached is a patch that removes the use of the flat auth file during
> client authentication, instead using regular access to the pg_auth
> catalogs. As previously discussed, this implies pushing the
> authentication work down to InitPostgres. I
On Thu, Aug 27, 2009 at 01:12:20PM -0400, Robert Haas wrote:
> This is pretty cool, IMO. Admittedly, it does seem hard to bottle it,
> but you managed it, so it's not completely impossible. What you could
> for this kind of thing is a series of patches and driver scripts, so
> you build PostgreSQ
On Sat, 2009-08-29 at 01:00 -0400, Tom Lane wrote:
> Attached is a patch that removes the use of the flat auth file during
> client authentication, instead using regular access to the pg_auth
> catalogs. As previously discussed, this implies pushing the
> authentication work down to InitPostgres
On Fri, 2009-08-28 at 14:44 -0700, Jeff Janes wrote:
> I'd previously implemented this just by copying and pasting and making
> some changes, perhaps not the most desirable way but I thought adding
> another parameter to all existing invocations would be a bit
> excessive.
That's the way I would
* Simon Riggs (si...@2ndquadrant.com) wrote:
> I get the feeling that part of the inspiration for this is that Hot
> Standby must maintain this file. If not, I'm curious as to the reasons
> for doing this. No objections however, just curiosity.
The impetus for these changes was the performance com
Greg Stark writes:
> On Sat, Aug 29, 2009 at 6:00 AM, Tom Lane wrote:
>> ... I didn't yet do anything
>> about the idea of falling back to connecting to "postgres" when the
>> specified target DB doesn't exist, but other than that small change
>> I think it's about ready to go.
> Falling back to
Simon Riggs writes:
> Specifically, should I remove the parts of the HS patch that refresh
> those files?
Yes. This was the last part that I was afraid might have insurmountable
problems. There are some bits yet to do but they're in the nature of
crank-turning, I believe. I think it's a good b
new one at http://zlew.org/postgresql_static_check/scan-build-2009-08-29-3/
archive at :
http://zlew.org/postgresql_static_check/postgresql_static_check_29thAugust2009.tar.xz
as always, comments are welcomed. And constructive explanation of any
wrong-results will be relayed to clang-checker d
We still have things like this showing "division by zero":
Assert(activeTapes > 0);
1913slotsPerTape = (state->memtupsize - state->mergefirstfree) /
activeTapes;
It looks like if you marked ExceptionalCondition() as never returning
then it should hide this.
--
greg
http://mit.edu
On 29 Aug 2009, at 17:35, Greg Stark wrote:
We still have things like this showing "division by zero":
Assert(activeTapes > 0);
1913 slotsPerTape = (state->memtupsize - state->mergefirstfree) /
activeTapes;
It looks like if you marked ExceptionalCondition() as never returning
then it sho
Oh, I think I see what's happening. Our assertions can still be turned
off at run-time with the variable assert_enabled.
Hm, you would have to replace assert_enabled with a #define in
postgres.h and then do something about the guc.c code which assigns to
it.
On another note is there any way to m
Robert Haas wrote:
> Both committers and non-committers are currently suffering from the
> fact that there is not a lot of time in the year which is set aside
> for development, i.e. neither CommitFest-time nor beta-time. To fix
> this problem, we can:
>
> 1. Make CommitFests shorter.
> 2. Make C
Tom Lane wrote:
> "Kevin Grittner" writes:
> > Robert Haas wrote:
> >> The final CommitFest began November 11, 2008. It closed March 25,
> >> 2009 (+ 144 days). Beta1 was released April 15, 2009 (+ 21 days).
>
> > I'm not entirely clear on what was happening during the 21 days
> > between th
Alvaro Herrera wrote:
> Jan Urba?ski wrote:
> > Patch -p1 attached.
>
> Applied, thanks
Backpatched to 8.4.X, which is the only backbranch where this fix is
needed.
--
Bruce Momjian http://momjian.us
EnterpriseDB http://enterprisedb.com
+ If your life
On Sat, 2009-08-29 at 09:00 -0400, Stephen Frost wrote:
> * Simon Riggs (si...@2ndquadrant.com) wrote:
> > I get the feeling that part of the inspiration for this is that Hot
> > Standby must maintain this file. If not, I'm curious as to the reasons
> > for doing this. No objections however, just
On Sat, 2009-08-29 at 11:19 -0400, Tom Lane wrote:
> Simon Riggs writes:
> > Specifically, should I remove the parts of the HS patch that refresh
> > those files?
>
> Yes. This was the last part that I was afraid might have insurmountable
> problems. There are some bits yet to do but they're i
On Sat, Aug 29, 2009 at 4:02 AM, Simon Riggs wrote:
>
> On Fri, 2009-08-28 at 14:44 -0700, Jeff Janes wrote:
>
> > I'd previously implemented this just by copying and pasting and making
> > some changes, perhaps not the most desirable way but I thought adding
> > another parameter to all existing
Tom Lane escreveu:
Adriano Lange writes:
I need to control the size of a memory context on the fly and take
some actions when
the used memory exceeds a defined size.
The existing places that do that sort of thing do their own counting
of how much they've allocated.
I have seen that the Allo
On Fri, Aug 28, 2009 at 8:07 PM, Simon Riggs wrote:
> WALInsertLock is heavily contended and likely always will be even if we
> apply some of the planned fixes.
I've lost any earlier messages, could you resend the raw data on which
this is based?
> Some callers of WALInsertLock are more important
Greg Stark wrote:
> On Fri, Aug 28, 2009 at 8:07 PM, Simon Riggs wrote:
>> WALInsertLock is heavily contended and likely always will be even if we
>> apply some of the planned fixes.
>
> I've lost any earlier messages, could you resend the raw data on which
> this is based?
I don't have any point
20 matches
Mail list logo
