On Jul 11, 2009, at 12:12 AM, Tom Lane wrote:
Theo Schlossnagle writes:
I would think it would be txns that would be reading that table, but
I'm thinking it is a bit to aggressive. Am I reading the code wrong
there? I'm thinking it should be more selective about vxids it
chooses to block o
On Fri, Jul 10, 2009 at 2:48 PM, Tom Lane wrote:
> "Kevin Grittner" writes:
>> You do, but it's been pretty rare in my experience, and we're
>> considering alternatives which give a lot less flexibility that this.
>
> I dunno about "considering". We've already wasted vastly more time on
> this th
On Fri, Jul 10, 2009 at 2:44 PM, Jaime
Casanova wrote:
> On Fri, Jul 10, 2009 at 10:22 AM, Robert Haas wrote:
>> I took a look at this and it seems that #3 can be implemented with
>> essentially no additional code (the handful of lines I added where
>> more than balanced out by some simplifications
Theo Schlossnagle writes:
> I would think it would be txns that would be reading that table, but
> I'm thinking it is a bit to aggressive. Am I reading the code wrong
> there? I'm thinking it should be more selective about vxids it
> chooses to block on. I'd expect it to block on vxids to
We just ran into a case where we were performing two concurrent index
builds on two different tables in two different schemas in the same
database (no relational constraints between them).
One of the index builds locked on the other.
The first index build started...
The second index build st
On Fri, 10 Jul 2009 19:51:31 -0400
Tom Lane wrote:
> Josh Berkus writes:
> > I'd suggest that we publish an official policy, with the following dates
> > for "EOL":
>
> I have no objection to setting an EOL date for 7.4 now, but I think it
> is premature to set EOL dates for later versions. I
On Jul 10, 2009, at 5:39 PM, Tom Lane wrote:
I don't mind the idea of saying "our intention is to support new
releases for about five years", or something equally squishy.
But a list of dates in black and white does not look reasonable,
especially not dates that are four or five years out for ve
Tom Lane wrote:
Andrew Dunstan writes:
I think we can avoid most of these problems by making a "best effort"
policy rather than a hard promise. But it can be moderately specific
about what we will make best efforts towards. I agree that anyone who
wants a hard promise should be getting co
Andrew Dunstan writes:
> I think we can avoid most of these problems by making a "best effort"
> policy rather than a hard promise. But it can be moderately specific
> about what we will make best efforts towards. I agree that anyone who
> wants a hard promise should be getting commercial supp
Tom Lane wrote:
But on the whole I think we should NOT have such a policy, at all.
If we'd enunciated such a thing in 2005, we'd still be on the hook to
support 8.0 on Windows; or else have had to go back on our word. The
truth of the matter is that the community will make reasonable efforts
t
On Jul 10, 2009, at 6:01 PM, Josh Berkus wrote:
All,
I'd suggest that we publish an official policy, with the following
dates for "EOL":
7.4 2009-08-01
8.0 2010-02-01
8.1 2011-01-01
8.2 2012-01-01
8.3 2013-03-01
8.4 2014-08-01
EOL would be defined as:
"After the above dates,
David E. Wheeler wrote:
> On Jul 10, 2009, at 4:01 PM, Josh Berkus wrote:
>
> > All,
> >
> > I'd suggest that we publish an official policy, with the following
> > dates for "EOL":
> >
> > 7.4 2009-08-01
> > 8.0 2010-02-01
> > 8.1 2011-01-01
> > 8.2 2012-01-01
> > 8.3 2013-03-01
> > 8.
Josh Berkus writes:
> I'd suggest that we publish an official policy, with the following dates
> for "EOL":
> 7.4 2009-08-01
> 8.0 2010-02-01
> 8.1 2011-01-01
> 8.2 2012-01-01
> 8.3 2013-03-01
> 8.4 2014-08-01
I have no objection to setting an EOL date for 7.4 now, but I think it
is
On Jul 10, 2009, at 4:01 PM, Josh Berkus wrote:
All,
I'd suggest that we publish an official policy, with the following
dates for "EOL":
7.4 2009-08-01
8.0 2010-02-01
8.1 2011-01-01
8.2 2012-01-01
8.3 2013-03-01
8.4 2014-08-01
EOL would be defined as:
"After the above dates, t
All,
Gabrielle of PDXPUG volunteered that PUG to hold a "code sprint" in
coordination with a commitfest sometime soon. For that event, the
PDXPUG members would take on a dozen or so patches, compile and review
them and submit the results.
The reason I mention this here is that they would ne
All,
I'd suggest that we publish an official policy, with the following dates
for "EOL":
7.4 2009-08-01
8.0 2010-02-01
8.1 2011-01-01
8.2 2012-01-01
8.3 2013-03-01
8.4 2014-08-01
EOL would be defined as:
"After the above dates, the PostgreSQL Project will not promise to
provide
Tom Lane wrote:
> "Kevin Grittner" writes:
>> You do, but it's been pretty rare in my experience, and we're
>> considering alternatives which give a lot less flexibility that this.
>
> I dunno about "considering". We've already wasted vastly more time on
> this than it's worth. AFAIR there has
On Jul 10, 2009, at 11:03 AM, Joshua Tolley wrote:
Am I the only one having problems building 8.1 from git? (Am I the
only one
building 8.1 from git?) In a clean repository, I've checked out
REL8_1_STABLE,
configured with only one argument, to set --prefix, and make gives
me this:
While n
>> I think we might be better off just
leaving the closed commitfests up on the wiki, and putting a notice on
the app saying "commitfests prior to July 2009 can be found at
wiki.postgresql.org".
+1. That's why we're switching technogies at the beginning of a dev cycle.
--
Josh Berkus
Postgr
"Kevin Grittner" writes:
> You do, but it's been pretty rare in my experience, and we're
> considering alternatives which give a lot less flexibility that this.
I dunno about "considering". We've already wasted vastly more time on
this than it's worth. AFAIR there has never been one single user
On Fri, Jul 10, 2009 at 10:22 AM, Robert Haas wrote:
> I took a look at this and it seems that #3 can be implemented with
> essentially no additional code (the handful of lines I added where
> more than balanced out by some simplifications in ruleutils.c). Of
> course you still don't have to like
On Jul 10, 2009, at 12:06 PM, Tom Lane wrote:
Robert Haas writes:
I took a look at this and it seems that #3 can be implemented with
essentially no additional code (the handful of lines I added where
more than balanced out by some simplifications in ruleutils.c). Of
course you still don't ha
Am I the only one having problems building 8.1 from git? (Am I the only one
building 8.1 from git?) In a clean repository, I've checked out REL8_1_STABLE,
configured with only one argument, to set --prefix, and make gives me this:
make[4]: Entering directory
`/home/josh/devel/pgsrc/pg81/src/backen
Tom Lane wrote:
> "Kevin Grittner" writes:
>> treat parentheses around JOIN operations as optimizer hints.
>
> That's a *truly* horrid idea, as sometimes you need them simply to
> get the precedence correct.
You do, but it's been pretty rare in my experience, and we're
considering alternative
"Kevin Grittner" writes:
> Actually, if we were going to add fine-grained optimizer hints for
> this (which I'm not at all convinced is a good idea), I'd be tempted
> to go with what I saw a few years ago in SAP-DB (later rebranded as
> MySQL Max-DB): treat parentheses around JOIN operations as op
Robert Haas wrote:
> At any rate the particular choice of keyword seems rather
> insignificant; I picked it because it was already a keyword and
> seemed vaguely appropriate, but it could easily be changed.
Actually, if we were going to add fine-grained optimizer hints for
this (which I'm n
On Sun, Jan 25, 2009 at 6:57 PM, Mark Kirkwood wrote:
>
> So here is my initial attempt at this, at this point merely to spark
> discussion (attached patch)
>
this patch doesn't apply cleanly to head... can you update it, please?
--
Atentamente,
Jaime Casanova
Soporte y capacitación de PostgreSQ
On Jul 10, 2009, at 11:48 AM, Dimitri Fontaine media.com> wrote:
Hi,
Le 10 juil. 09 à 17:22, Robert Haas a écrit :
I took a look at this and it seems that #3 can be implemented with
essentially no additional code (the handful of lines I added where
more than balanced out by some simplification
Robert Haas writes:
> I took a look at this and it seems that #3 can be implemented with
> essentially no additional code (the handful of lines I added where
> more than balanced out by some simplifications in ruleutils.c). Of
> course you still don't have to like it. :-)
You're right, I don't.
Hi,
Le 10 juil. 09 à 17:22, Robert Haas a écrit :
I took a look at this and it seems that #3 can be implemented with
essentially no additional code (the handful of lines I added where
more than balanced out by some simplifications in ruleutils.c). Of
course you still don't have to like it. :-)
Stefan Kaltenbrunner wrote:
Robert Haas wrote:
On Jul 9, 2009, at 5:53 PM, Dave Page wrote:
On Thu, Jul 9, 2009 at 11:31 PM, Robert Haas
wrote:
On Jul 9, 2009, at 5:07 PM, Peter Eisentraut wrote:
On Thursday 09 July 2009 19:06:35 Brendan Jurd wrote:
Your login details for the app == you
http://www.sigaev.ru/misc/polygon-0.2.gz
Patch fixes wrong algorithms of contains and overlap operations over polygons.
Regression tests contain an examples of such polygons.
--
Teodor Sigaev E-mail: teo...@sigaev.ru
2009/4/26 Brendan Jurd :
> I've done some work updating Pavel's sci notation patch for to_char().
That patch again, now with a couple of minor tweaks to make it apply
cleanly against the current HEAD.
Cheers,
BJ
_3.diff.bz2
Description: BZip2 compressed data
--
Sent via pgsql-hackers mail
On Wed, Jul 8, 2009 at 4:57 PM, Tom Lane wrote:
> Well, the reason I'm not voting for #3 is that it looks like a lot of
> work to implement something that would basically be a planner hint,
> which I'm generally against; furthermore, it's a hint that there's been
> no demand for. (We're not even c
On Jul 9, 2009, at 12:35 PM, Brendan Jurd wrote:
We don't AFAIK collect data about these events. However, we could
have certain actions trigger the creation of an automated comment
(e.g., "Status changed to Committed by petere") and let the
aforementioned comment view suffice for a "history".
Robert Haas wrote:
On Jul 9, 2009, at 5:53 PM, Dave Page wrote:
On Thu, Jul 9, 2009 at 11:31 PM, Robert Haas
wrote:
On Jul 9, 2009, at 5:07 PM, Peter Eisentraut wrote:
On Thursday 09 July 2009 19:06:35 Brendan Jurd wrote:
Your login details for the app == your community login == your wik
On Fri, Jul 10, 2009 at 2:23 AM, Robert Haas wrote:
>> We have a wildcard cert for the domain. I'm going on vacation at the
>> weekend, and have to wrap up a bunch of stuff at work tomorrow, but if
>> you talk nicely to Stefan...
>
> Stefan, you are mighty and have powerful administration skills.
The SE-PostgreSQL patches are updated as follows:
[1/5] http://sepgsql.googlecode.com/files/sepgsql-01-sysatt-8.5devel-r2163.patch
[2/5] http://sepgsql.googlecode.com/files/sepgsql-02-core-8.5devel-r2163.patch
[3/5] http://sepgsql.googlecode.com/files/sepgsql-03-gram-8.5devel-r2163.patch
[4/5] htt
38 matches
Mail list logo
