[reposting with gzipped patch]
Here is a patch further cleaning up dummy process startup and the
bootstrap code itself a little.
I've tested it manually giving erroneous input and it behaves in the
same ways as the original. Of course, it still manages to bootstrap
normally and passes regression
Bruce Momjian escribió:
>
> Followup --- something weird is going on. I am seeing _random_ failures
> of the regression tests here in that same place, and the build farm
> seems to fail in the same place, but with different row counts.
This failure is pretty interesting:
--- 724,730
d
Here is a patch further cleaning up dummy process startup and the
bootstrap code itself a little.
I've tested it manually giving erroneous input and it behaves in the
same ways as the original. Of course, it still manages to bootstrap
normally and passes regression tests.
This patches removes a
Am Freitag, 16. Februar 2007 08:02 schrieb Jeremy Drake:
> On Thu, 15 Feb 2007, Peter Eisentraut wrote:
> > I have no strong opinion about how matches are returned. Seeing the
> > definitional difficulties that you point out, it may be fine to return
> > them unordered. But then all "matches" fun
Alvaro Herrera wrote:
Bruce Momjian escribió:
Followup --- something weird is going on. I am seeing _random_ failures
of the regression tests here in that same place, and the build farm
seems to fail in the same place, but with different row counts.
This failure is pretty interesting:
Andrew Dunstan escribió:
> Looks to me like the timestamptz test relies on the timestamp test (for
> timestamp_tbl) but they are set to run in parallel, so we have a race
> condition. Oops!
Good catch :-)
I'd guess the answer is to move the tests using the timestamp_tbl to the
timestamp test.
Alvaro Herrera wrote:
> Andrew Dunstan escribi?:
>
> > Looks to me like the timestamptz test relies on the timestamp test (for
> > timestamp_tbl) but they are set to run in parallel, so we have a race
> > condition. Oops!
>
> Good catch :-)
>
> I'd guess the answer is to move the tests using t
Bruce Momjian escribió:
> Alvaro Herrera wrote:
> > Andrew Dunstan escribi?:
> >
> > > Looks to me like the timestamptz test relies on the timestamp test (for
> > > timestamp_tbl) but they are set to run in parallel, so we have a race
> > > condition. Oops!
> >
> > Good catch :-)
> >
> > I'd g
Alvaro Herrera wrote:
Bruce Momjian escribió:
Alvaro Herrera wrote:
Andrew Dunstan escribi?:
Looks to me like the timestamptz test relies on the timestamp test (for
timestamp_tbl) but they are set to run in parallel, so we have a race
condition. Oops!
Good catch :-)
Alvaro Herrera wrote:
> Bruce Momjian escribi?:
> > Alvaro Herrera wrote:
> > > Andrew Dunstan escribi?:
> > >
> > > > Looks to me like the timestamptz test relies on the timestamp test (for
> > > > timestamp_tbl) but they are set to run in parallel, so we have a race
> > > > condition. Oops!
>
FAST PostgreSQL wrote:
> On Fri, 16 Feb 2007 11:50, Tom Lane wrote:
>> "FAST PostgreSQL" <[EMAIL PROTECTED]> writes:
>>> The second variable is of interest. We need to specify a table in the
>>> insert command. My preferred option is for the user to give one and he
>>> can create it if and when he
Andrew Dunstan escribió:
> Alvaro Herrera wrote:
> >Bruce Momjian escribió:
> >
> >>Alvaro Herrera wrote:
> >>
> >>>Andrew Dunstan escribi?:
> >>>
> >>>
> Looks to me like the timestamptz test relies on the timestamp test (for
> timestamp_tbl) but they are set to run in paralle
Bruce Momjian escribió:
Maybe now would be an appropriate time to discuss the open questions in
the submitting email:
> > Brendan Jurd wrote:
> > > I have tried to implement these features with as little disruption to
> > > the existing code as possible. I built on the existing date2iso*
> > >
On Fri, Feb 16, 2007 at 01:19:55PM +0100, Peter Eisentraut wrote:
> Am Freitag, 16. Februar 2007 08:02 schrieb Jeremy Drake:
> > On Thu, 15 Feb 2007, Peter Eisentraut wrote:
> > > I have no strong opinion about how matches are returned. Seeing
> > > the definitional difficulties that you point out
Alvaro Herrera wrote:
> > > > The same situation can arise if the user mixes ISO and Gregorian data;
> > > > how should Postgres deal with something like to_date('2006-250',
> > > > 'IYYY-DDD')? The current behaviour in my patch is actually to assume
> > > > that the user meant to say 'IYYY-IDDD',
Am Freitag, 16. Februar 2007 17:11 schrieb David Fetter:
> > As for the regexp_matches() function, it seems to me that it returns
> > too much information at once. What is the use case for getting all
> > of prematch, fullmatch, matches, and postmatch in one call?
>
> If not in one call, how would
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> Andrew Dunstan escribió:
>> Well, the first question is "which table should these tests actually be
>> using, and why?" Then they can be changed or moved as appropriate.
> I just committed my patch before reading this comment. Maybe it was
> rushed.
On Fri, Feb 16, 2007 at 05:54:47PM +0100, Peter Eisentraut wrote:
> Am Freitag, 16. Februar 2007 17:11 schrieb David Fetter:
> > > As for the regexp_matches() function, it seems to me that it
> > > returns too much information at once. What is the use case for
> > > getting all of prematch, fullma
David Fetter wrote:
The question is, what is the use case? If there is one in Perl, can
this proposed function API support it?
Perl makes the following variables available in any regex match,
although it optimizes some cases for when they're not there:
$1, ... $n (captured matches in pa
David Fetter wrote:
> > The question is, what is the use case? If there is one in Perl,
> > can this proposed function API support it?
>
> Perl makes the following variables available in any regex match,
That is not a use case.
--
Peter Eisentraut
http://developer.postgresql.org/~petere/
-
On Fri, Feb 16, 2007 at 01:03:32PM -0500, Andrew Dunstan wrote:
> David Fetter wrote:
> >>
> >>The question is, what is the use case? If there is one in Perl, can
> >>this proposed function API support it?
> >>
> >
> >Perl makes the following variables available in any regex match,
> >although
Applied.
---
Bruce Momjian wrote:
>
> I did some research on this item from October, 2006. I was struck by
> the memset of 2344 for every proc title change on popular platforms like
> Linux.
>
> The attached patch reduces
At the risk of starting trouble, is there some reason this was added to
contrib and not put on pgfoundry ?
On Thursday 08 February 2007 10:09, Bruce Momjian wrote:
> Patch applied. Thanks.
>
> ---
>
> Simon Riggs wrote:
> >
Robert Treat wrote:
> At the risk of starting trouble, is there some reason this was added to
> contrib and not put on pgfoundry ?
I thought the idea was that it was integral to using PITR, but might
change so it was put in /contrib.
>
> On Thursday 08 February 2007 10:09, Bruce Momjian wrote:
On 2/12/2007 11:43 AM, Tom Lane wrote:
Greg Smith <[EMAIL PROTECTED]> writes:
Right now when you run pgbench, the results vary considerably from run to
run even if you completely rebuild the database every time. I've found
that a lot of that variation comes from two things:
This is a real is
On Fri, 16 Feb 2007, Peter Eisentraut wrote:
> Am Freitag, 16. Februar 2007 08:02 schrieb Jeremy Drake:
> > Does this version sufficiently address your concerns?
>
> I don't think anyone asked for the start position and length in the result of
> regexp_split(). The result should be an array of te
On 2/17/07, Tom Lane <[EMAIL PROTECTED]> wrote:
Yes, it was: you now have two duplicate tests in timestamp.sql, and
no corresponding test in timestamptz.sql. It looks to me like the
submitter intended to be testing timestamp_tbl in the former file
and the same tests against timestamptz_tbl in th
Bruce Momjian wrote:
I have tested this patch but it generates regression failures.
There was some code drift, so I am attaching an updated version of the
patch, and the regression diffs. The 'four' column is an 'int4' so my
guess is that somehow the wrong aggregate is being called.
Good cat
Mark Kirkwood wrote:
> Bruce Momjian wrote:
> > I have tested this patch but it generates regression failures.
> >
> > There was some code drift, so I am attaching an updated version of the
> > patch, and the regression diffs. The 'four' column is an 'int4' so my
> > guess is that somehow the wro
Brendan Jurd wrote:
> On 2/17/07, Tom Lane <[EMAIL PROTECTED]> wrote:
> > Yes, it was: you now have two duplicate tests in timestamp.sql, and
> > no corresponding test in timestamptz.sql. It looks to me like the
> > submitter intended to be testing timestamp_tbl in the former file
> > and the same
Brendan Jurd escribió:
> On 2/17/07, Tom Lane <[EMAIL PROTECTED]> wrote:
> >Yes, it was: you now have two duplicate tests in timestamp.sql, and
> >no corresponding test in timestamptz.sql. It looks to me like the
> >submitter intended to be testing timestamp_tbl in the former file
> >and the same
Patch applied. Thanks.
---
Mark Kirkwood wrote:
> Bruce Momjian wrote:
> > I have tested this patch but it generates regression failures.
> >
> > There was some code drift, so I am attaching an updated version of the
> >
Seems the consensus was this was a good idea, and not feature-creep.
It needs SGML documentation, which I will add.
Your patch has been added to the PostgreSQL unapplied patches list at:
http://momjian.postgresql.org/cgi-bin/pgpatches
It will be applied as soon as one of the PostgreSQL
On 2/17/07, Alvaro Herrera <[EMAIL PROTECTED]> wrote:
Thanks for the clarification. Would you have a look at the tests as
they are now and confirm that that's what you wanted?
Yes, the tests in HEAD right now are what I wanted. Although, while I
was in there I did notice a minor thing (anoth
Applied.
---
Brendan Jurd wrote:
> On 2/17/07, Alvaro Herrera <[EMAIL PROTECTED]> wrote:
> > Thanks for the clarification. Would you have a look at the tests as
> > they are now and confirm that that's what you wanted?
> >
Nice test case. I did some research and realized that there is an
incorrect use of rint() in the code. The problem is that you can't
rint() if you can't overflow to the next units, and you can't rint() if
you might need to print the lesser units. In this case, we hit both of
those problems, so
Your patch has been added to the PostgreSQL unapplied patches list at:
http://momjian.postgresql.org/cgi-bin/pgpatches
It will be applied as soon as one of the PostgreSQL committers reviews
and approves it.
---
Pa
37 matches
Mail list logo
