I am seeing buildfarm failures from the new regression tests added by
this patch. Would someone research why this is happening?

http://www.pgbuildfarm.org/cgi-bin/show_status.pl

---------------------------------------------------------------------------

bruce wrote:
>
> Patch applied. Thanks.
>
> ---------------------------------------------------------------------------
>
>
> Brendan Jurd wrote:
> > The attached patch implements my proposal to extend support for the
> > ISO week date calendar.
> >
> > I have added two new format fields for use with to_char, to_date and
> > to_timestamp:
> > - ID for day-of-week
> > - IDDD for day-of-year
> >
> > This makes it possible to convert ISO week dates to and from text
> > fully represented in either week ('IYYY-IW-ID') or day-of-year
> > ('IYYY-IDDD') format.
> >
> > I have also added an 'isoyear' field for use with extract / date_part.
> >
> > The patch includes documentation updates and some extra tests in the
> > regression suite for the new fields.
> >
> > I have tried to implement these features with as little disruption to
> > the existing code as possible. I built on the existing date2iso*
> > functions in src/backend/utils/adt/timestamp.c, and added a few
> > functions of my own, but I wonder if these functions would be more
> > appropriately located in datetime.c, alongside date2j and j2date?
> >
> > I'd also like to raise the topic of how conversion from text to ISO
> > week dates should be handled, where the user has specified a bogus
> > mixture of fields. Existing code basically ignores these issues; for
> > example, if a user were to call to_date('1998-01-01 2454050',
> > 'YYYY-MM-DD J') the function returns 2006-01-01, a result of setting
> > the year field from YYYY, then overwriting year, month and day with
> > the values from the Julian date in J, then setting the month and day
> > normally from MM and DD.
> >
> > 2006-01-01 is not a valid representation of either of the values the
> > user specified. Now you might say "ask a silly question, get a silly
> > answer"; the user shouldn't send nonsense arguments to to_date and
> > expect a sensible result. But perhaps the right way to respond to a
> > broken timestamp definition is to throw an error, rather than behave
> > as though everything has gone to plan, and return something which is
> > not correct.
> >
> > 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', since "the 250th Gregorian day
> > of the ISO year 2006" is total gibberish. But perhaps it should be
> > throwing an error message.
> >
> > That's all for now, thanks for your time.
> > BJ
>
> [ Attachment, skipping... ]
>
> >
> > ---------------------------(end of broadcast)---------------------------
> > TIP 2: Don't 'kill -9' the postmaster
>
> --
> Bruce Momjian <bruce@momjian.us> http://momjian.us
> EnterpriseDB http://www.enterprisedb.com
>
> + If your life is a hard drive, Christ can be your backup. +

--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://www.enterprisedb.com

+ If your life is a hard drive, Christ can be your backup. +

---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match

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.

I am heading to bed but when I wake up, if it still an issue, I will
revert the patch.

---------------------------------------------------------------------------

Bruce Momjian wrote:
>
> I am seeing buildfarm failures from the new regression tests added by
> this patch. Would someone research why this is happening?
>
> http://www.pgbuildfarm.org/cgi-bin/show_status.pl
>
> ---------------------------------------------------------------------------
>
> bruce wrote:
> >
> > Patch applied. Thanks.
> >
> > ---------------------------------------------------------------------------
> >
> >
> > Brendan Jurd wrote:
> > > The attached patch implements my proposal to extend support for the
> > > ISO week date calendar.
> > >
> > > I have added two new format fields for use with to_char, to_date and
> > > to_timestamp:
> > > - ID for day-of-week
> > > - IDDD for day-of-year
> > >
> > > This makes it possible to convert ISO week dates to and from text
> > > fully represented in either week ('IYYY-IW-ID') or day-of-year
> > > ('IYYY-IDDD') format.
> > >
> > > I have also added an 'isoyear' field for use with extract / date_part.
> > >
> > > The patch includes documentation updates and some extra tests in the
> > > regression suite for the new fields.
> > >
> > > I have tried to implement these features with as little disruption to
> > > the existing code as possible. I built on the existing date2iso*
> > > functions in src/backend/utils/adt/timestamp.c, and added a few
> > > functions of my own, but I wonder if these functions would be more
> > > appropriately located in datetime.c, alongside date2j and j2date?
> > >
> > > I'd also like to raise the topic of how conversion from text to ISO
> > > week dates should be handled, where the user has specified a bogus
> > > mixture of fields. Existing code basically ignores these issues; for
> > > example, if a user were to call to_date('1998-01-01 2454050',
> > > 'YYYY-MM-DD J') the function returns 2006-01-01, a result of setting
> > > the year field from YYYY, then overwriting year, month and day with
> > > the values from the Julian date in J, then setting the month and day
> > > normally from MM and DD.
> > >
> > > 2006-01-01 is not a valid representation of either of the values the
> > > user specified. Now you might say "ask a silly question, get a silly
> > > answer"; the user shouldn't send nonsense arguments to to_date and
> > > expect a sensible result. But perhaps the right way to respond to a
> > > broken timestamp definition is to throw an error, rather than behave
> > > as though everything has gone to plan, and return something which is
> > > not correct.
> > >
> > > 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', since "the 250th Gregorian day
> > > of the ISO year 2006" is total gibberish. But perhaps it should be
> > > throwing an error message.
> > >
> > > That's all for now, thanks for your time.
> > > BJ
> >
> > [ Attachment, skipping... ]
> >
> > >
> > > ---------------------------(end of broadcast)---------------------------
> > > TIP 2: Don't 'kill -9' the postmaster
> >
> > --
> > Bruce Momjian <bruce@momjian.us> http://momjian.us
> > EnterpriseDB http://www.enterprisedb.com
> >
> > + If your life is a hard drive, Christ can be your backup. +
>
> --
> Bruce Momjian <bruce@momjian.us> http://momjian.us
> EnterpriseDB http://www.enterprisedb.com
>
> + If your life is a hard drive, Christ can be your backup. +

--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://www.enterprisedb.com

+ If your life is a hard drive, Christ can be your backup. +

---------------------------(end of broadcast)---------------------------
TIP 1: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to majordomo@postgresql.org so that your
message can get through to the mailing list cleanly

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 ----
date_part( 'isoyear', d1) AS isoyear, date_part( 'week', d1) AS week,
date_part( 'dow', d1) AS dow
FROM TIMESTAMP_TBL WHERE d1 BETWEEN '1902-01-01' AND '2038-01-01';
! ERROR: relation "timestamp_tbl" does not exist
-- TO_CHAR()
SELECT '' AS to_char_1, to_char(d1, 'DAY Day day DY Dy dy MONTH Month month RM MON Mon mon')
FROM TIMESTAMPTZ_TBL;

http://buildfarm.postgresql.org/cgi-...-16%2005:15:01

How can the table fail to exist, and yet not report a problem when it
was created?

--
Alvaro Herrera http://www.CommandPrompt.com/
PostgreSQL Replication, Consulting, Custom Development, 24x7 support

---------------------------(end of broadcast)---------------------------
TIP 6: explain analyze is your friend

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:
>
> --- 724,730 ----
> date_part( 'isoyear', d1) AS isoyear, date_part( 'week', d1) AS week,
> date_part( 'dow', d1) AS dow
> FROM TIMESTAMP_TBL WHERE d1 BETWEEN '1902-01-01' AND '2038-01-01';
> ! ERROR: relation "timestamp_tbl" does not exist
> -- TO_CHAR()
> SELECT '' AS to_char_1, to_char(d1, 'DAY Day day DY Dy dy MONTH Month month RM MON Mon mon')
> FROM TIMESTAMPTZ_TBL;
>
> http://buildfarm.postgresql.org/cgi-...-16%2005:15:01
>
> How can the table fail to exist, and yet not report a problem when it
> was created?
>
>

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!

cheers

andrew

---------------------------(end of broadcast)---------------------------
TIP 7: You can help support the PostgreSQL project by donating at

http://www.postgresql.org/about/donate

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 http://www.CommandPrompt.com/
PostgreSQL Replication, Consulting, Custom Development, 24x7 support

---------------------------(end of broadcast)---------------------------
TIP 1: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to majordomo@postgresql.org so that your
message can get through to the mailing list cleanly

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 the timestamp_tbl to the
> timestamp test.

OK, will do. Thanks for the diagnosis.

--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://www.enterprisedb.com

+ If your life is a hard drive, Christ can be your backup. +

---------------------------(end of broadcast)---------------------------
TIP 6: explain analyze is your friend

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 guess the answer is to move the tests using the timestamp_tbl to the
> > timestamp test.
>
> OK, will do. Thanks for the diagnosis.

Actually I have a patch ready for it.

--
Alvaro Herrera http://www.CommandPrompt.com/
PostgreSQL Replication, Consulting, Custom Development, 24x7 support

---------------------------(end of broadcast)---------------------------
TIP 4: Have you searched our list archives?

http://archives.postgresql.org

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 :-)
>>>
>>> I'd guess the answer is to move the tests using the timestamp_tbl to the
>>> timestamp test.
>>>
>> OK, will do. Thanks for the diagnosis.
>>
>
> Actually I have a patch ready for it.
>
>

Well, the first question is "which table should these tests actually be
using, and why?" Then they can be changed or moved as appropriate.

cheers

andrew

---------------------------(end of broadcast)---------------------------
TIP 6: explain analyze is your friend

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 :-)
> > >
> > > I'd guess the answer is to move the tests using the timestamp_tbl to the
> > > timestamp test.
> >
> > OK, will do. Thanks for the diagnosis.
>
> Actually I have a patch ready for it.

OK, thanks, I will not do anything.

--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://www.enterprisedb.com

+ If your life is a hard drive, Christ can be your backup. +

---------------------------(end of broadcast)---------------------------
TIP 3: Have you checked our extensive FAQ?

http://www.postgresql.org/docs/faq

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 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.
> >>>
> >>OK, will do. Thanks for the diagnosis.
> >>
> >
> >Actually I have a patch ready for it.
> >
> >
>
> 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 the other hand, my thinking was that the submitter used the serial
schedule to test, so he wouldn't catch the problem because the timestamp
test comes before the timestamptz test and so there's no race condition
there. My conclusion would be that he intended to use the timestamp_tbl
table because that's what he did and it worked for him.

However, he did change one test from using the timestamptz_tbl into
using timestamp_tbl (and changed the to_char format in the process); I
fixed that by putting the new format in the timestamp test, and
restoring the original in timestamptz.

Lesson for today would be to make sure to run both the serial and the
parallel tests, several times, and that they both pass ...

--
Alvaro Herrera http://www.CommandPrompt.com/
The PostgreSQL Company - Command Prompt, Inc.

---------------------------(end of broadcast)---------------------------
TIP 3: Have you checked our extensive FAQ?

http://www.postgresql.org/docs/faq