Horton

Thread

  1. v7.1.1 branched and released on Tuesday ...

    Marc G. Fournier <scrappy@hub.org> — 2001-04-27T18:22:12Z

    As Tom's mentioned the other day, we're looking at doing up v7.1.1 on
Tuesday, and starting in on v7.2 ...

Does anyone have any outstanding fixes for v7.1.x that they want to see in
*before* we do this release?  Any points unresolved that anyone knows
about that we need to look at?



Marc G. Fournier                   ICQ#7615664               IRC Nick: Scrappy
Systems Administrator @ hub.org
primary: scrappy@hub.org           secondary: scrappy@{freebsd|postgresql}.org

  2. Re: v7.1.1 branched and released on Tuesday ...

    bpalmer <bpalmer@crimelabs.net> — 2001-04-27T19:32:28Z

    >
> Does anyone have any outstanding fixes for v7.1.x that they want to see in
> *before* we do this release?  Any points unresolved that anyone knows
> about that we need to look at?

Is there a list of what IS getting changed?  Can this be posted somewhere
or is the changelist enough?

- Brandon

b. palmer,  bpalmer@crimelabs.net
pgp:  www.crimelabs.net/bpalmer.pgp5

  3. Re: v7.1.1 branched and released on Tuesday ...

    Jan Wieck <janwieck@yahoo.com> — 2001-04-27T20:18:19Z

    The Hermit Hacker wrote:
>
> As Tom's mentioned the other day, we're looking at doing up v7.1.1 on
> Tuesday, and starting in on v7.2 ...
>
> Does anyone have any outstanding fixes for v7.1.x that they want to see in
> *before* we do this release?  Any points unresolved that anyone knows
> about that we need to look at?

    The  RI-oddness  thing.  Tom  objected  to my first trial and
    hasn't responded to my last reply yet. Well, and  noone  else
    lost  a  single word where I'd expected at least a *shrug* or
    two.


Jan

--

#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me.                                  #
#================================================== JanWieck@Yahoo.com #



_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com

  4. Re: v7.1.1 branched and released on Tuesday ...

    Thomas Lockhart <lockhart@alumni.caltech.edu> — 2001-04-27T23:35:04Z

    > Does anyone have any outstanding fixes for v7.1.x that they want to see in
> *before* we do this release?  Any points unresolved that anyone knows
> about that we need to look at?

Nothing serious, but I would like to apply a patch to allow IDENT
strings (e.g. 'hour') to be accepted by the SQL92 EXTRACT() function. We
accept those for date_part(), which is what EXTRACT() is translated to
by the parser, and it seems to be a reasonable to the standard.

                             - Thomas

  5. Re: v7.1.1 branched and released on Tuesday ...

    Thomas Lockhart <lockhart@alumni.caltech.edu> — 2001-04-28T01:04:34Z

    > Nothing serious, but I would like to apply a patch to allow IDENT
> strings (e.g. 'hour') to be accepted by the SQL92 EXTRACT() function. We
> accept those for date_part(), which is what EXTRACT() is translated to
> by the parser, and it seems to be a reasonable to the standard.

... reasonable *extension* to the standard.

  6. Re: Re: v7.1.1 branched and released on Tuesday ...

    Peter Eisentraut <peter_e@gmx.net> — 2001-04-28T22:30:10Z

    Thomas Lockhart writes:

> Nothing serious, but I would like to apply a patch to allow IDENT
> strings (e.g. 'hour') to be accepted by the SQL92 EXTRACT() function. We
> accept those for date_part(), which is what EXTRACT() is translated to
> by the parser, and it seems to be a reasonable to the standard.

But why does that need to go into 7.1.1?

-- 
Peter Eisentraut   peter_e@gmx.net   http://funkturm.homeip.net/~peter

  7. Re: v7.1.1 branched and released on Tuesday ...

    Thomas Lockhart <lockhart@alumni.caltech.edu> — 2001-04-30T15:02:08Z

    > > Nothing serious, but I would like to apply a patch to allow IDENT
> > strings (e.g. 'hour') to be accepted by the SQL92 EXTRACT() function. We
> > accept those for date_part(), which is what EXTRACT() is translated to
> > by the parser, and it seems to be a reasonable to the standard.
> But why does that need to go into 7.1.1?

Does not "need to". But it is non-invasive, extremely low risk, gets the
behavior to match the docs, and gets it off my desk and into the main
tree.

                        - Thomas

  8. Re: Re: v7.1.1 branched and released on Tuesday ...

    Tom Lane <tgl@sss.pgh.pa.us> — 2001-04-30T16:03:56Z

    Thomas Lockhart <lockhart@alumni.caltech.edu> writes:
> Nothing serious, but I would like to apply a patch to allow IDENT
> strings (e.g. 'hour') to be accepted by the SQL92 EXTRACT() function. We
> accept those for date_part(), which is what EXTRACT() is translated to
> by the parser, and it seems to be a reasonable to the standard.

>> But why does that need to go into 7.1.1?

> Does not "need to". But it is non-invasive, extremely low risk, gets the
> behavior to match the docs, and gets it off my desk and into the main
> tree.

If the current behavior does not match the docs then it qualifies as a
bug fix ;-).  I have no objections to this one.

Thomas, what do you think of the persistent reports of date conversion
problems at DST boundaries, eg, Ayal Leibowitz's report today in
pgsql-bugs?  I cannot reproduce any such problem --- and my local
timezone database claims that MET DST transitions are the last week of
March, never the first week of April, anyway.  There's something funny
going on there.

			regards, tom lane

  9. Re: v7.1.1 branched and released on Tuesday ...

    Peter Eisentraut <peter_e@gmx.net> — 2001-04-30T16:12:36Z

    Thomas Lockhart writes:

> > > Nothing serious, but I would like to apply a patch to allow IDENT
> > > strings (e.g. 'hour') to be accepted by the SQL92 EXTRACT() function. We
> > > accept those for date_part(), which is what EXTRACT() is translated to
> > > by the parser, and it seems to be a reasonable to the standard.
> > But why does that need to go into 7.1.1?
>
> Does not "need to". But it is non-invasive, extremely low risk, gets the
> behavior to match the docs, and gets it off my desk and into the main
> tree.

Hehe, match the docs?  The docs used to be perfectly accurate until you
changed them.

-- 
Peter Eisentraut   peter_e@gmx.net   http://funkturm.homeip.net/~peter

  10. Re: Re: v7.1.1 branched and released on Tuesday ...

    Thomas Lockhart <lockhart@alumni.caltech.edu> — 2001-04-30T17:58:54Z

    > Thomas, what do you think of the persistent reports of date conversion
> problems at DST boundaries, eg, Ayal Leibowitz's report today in
> pgsql-bugs?  I cannot reproduce any such problem --- and my local
> timezone database claims that MET DST transitions are the last week of
> March, never the first week of April, anyway.  There's something funny
> going on there.

Yes. I tried the example on 7.0.2 (and 7.1) and could not get it to
misbehave. I was guessing that it involves string->date conversion,
which may pass through timestamp to get there, but it looks like there
is an explicit text->date conversion function so time zone should just
never be involved. Really!

                   - Thomas

  11. Re: v7.1.1 branched and released on Tuesday ...

    Thomas Lockhart <lockhart@alumni.caltech.edu> — 2001-04-30T17:59:34Z

    > Hehe, match the docs?  The docs used to be perfectly accurate until you
> changed them.

;)

  12. Re: v7.1.1 branched and released on Tuesday ...

    Tom Lane <tgl@sss.pgh.pa.us> — 2001-04-30T22:41:28Z

    The Hermit Hacker <scrappy@hub.org> writes:
> Does anyone have any outstanding fixes for v7.1.x that they want to see in
> *before* we do this release?  Any points unresolved that anyone knows
> about that we need to look at?

FWIW, I've finished committing all the bug fixes I have pending.

There are several worrisome unresolved bug reports, but AFAIK none are
for reproducible conditions, and I don't think we can make any more
progress on them without more information.  I doubt we should hold up
the 7.1.1 release while waiting to see if we get any.

We do have that not-quite-done QNX4 port patch in hand.  Perhaps we
should give Bernd another day to respond to the comments on that and
squeeze it into 7.1.1.

			regards, tom lane

  13. Re: v7.1.1 branched and released on Tuesday ...

    Bruce Momjian <pgman@candle.pha.pa.us> — 2001-04-30T23:03:44Z

    > The Hermit Hacker <scrappy@hub.org> writes:
> > Does anyone have any outstanding fixes for v7.1.x that they want to see in
> > *before* we do this release?  Any points unresolved that anyone knows
> > about that we need to look at?
> 
> FWIW, I've finished committing all the bug fixes I have pending.
> 
> There are several worrisome unresolved bug reports, but AFAIK none are
> for reproducible conditions, and I don't think we can make any more
> progress on them without more information.  I doubt we should hold up
> the 7.1.1 release while waiting to see if we get any.
> 
> We do have that not-quite-done QNX4 port patch in hand.  Perhaps we
> should give Bernd another day to respond to the comments on that and
> squeeze it into 7.1.1.

There will surely be a 7.1.2.  I vote against waiting for it.

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

  14. Re: v7.1.1 branched and released on Tuesday ...

    Tom Lane <tgl@sss.pgh.pa.us> — 2001-04-30T23:12:16Z

    Bruce Momjian <pgman@candle.pha.pa.us> writes:
>> We do have that not-quite-done QNX4 port patch in hand.  Perhaps we
>> should give Bernd another day to respond to the comments on that and
>> squeeze it into 7.1.1.

> There will surely be a 7.1.2.  I vote against waiting for it.

Possibly, but one hopes 7.1.2 will be a few months away ...

Given the triviality of the objections to Bernd's patch, I expect he can
turn it around pretty quickly.  I do not want to wait more than a day
for it.

			regards, tom lane

  15. date conversion (was Re: Re: v7.1.1 branched and released on Tuesday ...)

    Tom Lane <tgl@sss.pgh.pa.us> — 2001-05-01T00:51:58Z

    Thomas Lockhart <lockhart@alumni.caltech.edu> writes:
>> Thomas, what do you think of the persistent reports of date conversion
>> problems at DST boundaries, eg, Ayal Leibowitz's report today in
>> pgsql-bugs?  I cannot reproduce any such problem --- and my local
>> timezone database claims that MET DST transitions are the last week of
>> March, never the first week of April, anyway.  There's something funny
>> going on there.

> Yes. I tried the example on 7.0.2 (and 7.1) and could not get it to
> misbehave. I was guessing that it involves string->date conversion,
> which may pass through timestamp to get there, but it looks like there
> is an explicit text->date conversion function so time zone should just
> never be involved. Really!

I dug through the conversions involved (basically date_in and date_out).
AFAICS the only place where timezone could possibly get involved is that
DecodeDateTime attempts to derive a timezone for the given date/time.
It does this by calling mktime() (line 878 in datetime.c in current
sources).  If mktime() screws up and alters the tm->tm_mday field then
we'd see the reported behavior.  I really don't see any other place that
it could be happening.

A platform-specific bug in mktime would do nicely to explain why we
can't reproduce the problem, too ... OTOH, it's hard to believe such a
bug would have persisted across several RedHat releases, which seems to
be necessary to explain the reports.

			regards, tom lane

  16. Re: date conversion (was Re: Re: v7.1.1 branched and released on Tuesday ...)

    Thomas Lockhart <lockhart@alumni.caltech.edu> — 2001-05-01T00:55:55Z

    > I dug through the conversions involved (basically date_in and date_out).
> AFAICS the only place where timezone could possibly get involved is that
> DecodeDateTime attempts to derive a timezone for the given date/time.
> It does this by calling mktime() (line 878 in datetime.c in current
> sources).  If mktime() screws up and alters the tm->tm_mday field then
> we'd see the reported behavior.  I really don't see any other place that
> it could be happening.

Yes. It is possible to call DecodeDateTime() so that it *never* tries to
derive a time zone (call with the last argument set to NULL), but that
also causes it to reject date/time strings which have an explicit time
zone. We certainly would want to accept something like

  select date('1993-04-02 04:05:06 PST');

(even though for a date-only result it is overspecified), so calling
with NULL is not the right thing to do (I tried it, then realized the
bad effect).

> A platform-specific bug in mktime would do nicely to explain why we
> can't reproduce the problem, too ... OTOH, it's hard to believe such a
> bug would have persisted across several RedHat releases, which seems to
> be necessary to explain the reports.

It is also hard to see how such a bug would not be similarly manifested
in Mandrake, Debian, etc etc.

For this particular problem, I'd like to see the "DateStyle" setting,
the time zone setting, an example of the problem (does not require a
table, but just a date string conversion), and the output of "zdump -v"
for the timezone in question.

I'm not sure how to handle date/time bug reports which are not
reproducible on our machines. Certainly date/time issues are the most
problematic in terms of number of bug reports, but they are also
probably the most sensitive to machine configuration and user's
location, so all in all I think the types are doing very well. I don't
want to sound complacent, but it is probably sufficient to fix
reproducible problems to keep our date/time data types viable, and we
are doing far more than that over time :)

                         - Thomas

  17. Re: v7.1.1 branched and released on Tuesday ...

    Marc G. Fournier <scrappy@hub.org> — 2001-05-01T02:12:56Z

    On Mon, 30 Apr 2001, Tom Lane wrote:

> The Hermit Hacker <scrappy@hub.org> writes:
> > Does anyone have any outstanding fixes for v7.1.x that they want to see in
> > *before* we do this release?  Any points unresolved that anyone knows
> > about that we need to look at?
>
> FWIW, I've finished committing all the bug fixes I have pending.
>
> There are several worrisome unresolved bug reports, but AFAIK none are
> for reproducible conditions, and I don't think we can make any more
> progress on them without more information.  I doubt we should hold up
> the 7.1.1 release while waiting to see if we get any.
>
> We do have that not-quite-done QNX4 port patch in hand.  Perhaps we
> should give Bernd another day to respond to the comments on that and
> squeeze it into 7.1.1.

How about I do another end of week release?  Give Bernd until Friday to
sort through the patch with everyone without it being rushed ...

  18. Sorry, need to restart postmaster at db.hub.org (fts.postgresql.org)

    Oleg Bartunov <oleg@sai.msu.su> — 2001-05-01T07:17:05Z

    Hi,

just noticed Marc has restarted postmaster at db.hub.org and
forget to specify -e option (European format!) for backend. That's why
fts.postgresql.org  doesn't works properly. I've sent message to him
but probably better if somebody could talk with Marc or
restart corresponding postamaster at db.hub.rg.

	Regards,
		Oleg
_____________________________________________________________
Oleg Bartunov, sci.researcher, hostmaster of AstroNet,
Sternberg Astronomical Institute, Moscow University (Russia)
Internet: oleg@sai.msu.su, http://www.sai.msu.su/~megera/
phone: +007(095)939-16-83, +007(095)939-23-83

  19. Re: [HACKERS] Re: date conversion (was Re: Re: v7.1.1 branched and released on Tuesday ...)

    Tom Lane <tgl@sss.pgh.pa.us> — 2001-05-01T14:14:56Z

    I extracted from Ayal the info that he was using timezone
'Asia/Jerusalem'.  That zone has the interesting property that
the DST transitions happen *at midnight*, not at a sane hour like 2AM.
I suspect that that is triggering various & sundry bugs in older
versions of mktime().

On a relatively recent Linux (LinuxPPC 2000/Q4) the worst misbehavior
I can find is

	regression=# select timestamp('1993-04-02');
	       timestamp        
	------------------------
	 1993-04-02 01:00:00+03
	(1 row)

which is about the best we can do, seeing as how midnight local time
just plain does not exist on that date in that timezone.

However on an older Linux (RedHat 5.1) I get:

	regression=# select timestamp('1993-04-02');
	       timestamp        
	------------------------
	 2027-04-11 17:45:25+03
	(1 row)

which is a tad startling.  Tracing through DecodeDateTime tells the
tale:

(gdb) s
875                                     mktime(tm);
(gdb) p *tm
$2 = {tm_sec = 0, tm_min = 0, tm_hour = 0, tm_mday = 2, tm_mon = 3, 
  tm_year = 93, tm_wday = 0, tm_yday = 0, tm_isdst = -1, 
  tm_gmtoff = -1073745925, tm_zone = 0x81420c0 "\203\ffE\001"}
(gdb) n
876                                     tm->tm_year += 1900;
(gdb) p *tm
$3 = {tm_sec = 0, tm_min = 0, tm_hour = 0, tm_mday = 2, tm_mon = 3, 
  tm_year = 93, tm_wday = 0, tm_yday = 0, tm_isdst = -1, 
  tm_gmtoff = -1073745925, tm_zone = 0x81420c0 "\203\ffE\001"}
(gdb) s
877                                     tm->tm_mon += 1;
(gdb) s
880                                     *tzp = -(tm->tm_gmtoff);               /* tm_gmtoff is

Ooops.

I recommend that all uses of tm->tm_gmtoff from mktime() be guarded
along the lines of
	if (tm->tm_isdst >= 0)
		believe gmtoff
	else
		assume GMT

However, this still does not account for the reported failure of date()
since that code path doesn't use the returned value of *tzp --- and
indeed I get the right thing from select date('1993-04-02'), despite
the failure of mktime().  Probably the behavior of mktime() in this
situation varies across different glibc releases.  Would some other
folk try

	set timezone to 'Asia/Jerusalem';
	select timestamp('1993-04-02');
	select date('1993-04-02');

and report what you see?

BTW, I also see

	regression=# select timestamp(date('1993-04-02'));
	ERROR:  Unable to convert date to tm

which is just what you'd expect if mktime() fails for this input;
I suppose there's nothing we can do about that except advise people
to update to a less broken libc...

			regards, tom lane

  20. Re: Sorry, need to restart postmaster at db.hub.org (fts.postgresql.org)

    Thomas Lockhart <lockhart@alumni.caltech.edu> — 2001-05-02T04:26:18Z

    > just noticed Marc has restarted postmaster at db.hub.org and
> forget to specify -e option (European format!) for backend. That's why
> fts.postgresql.org  doesn't works properly. I've sent message to him
> but probably better if somebody could talk with Marc or
> restart corresponding postamaster at db.hub.rg.

Hmm. Might be a good time to consider using ISO time formats ;)

Could I help with something in that regard?

                    - Thomas

  21. Re: v7.1.1 branched and released on Tuesday ...

    Roberto Mello <rmello@cc.usu.edu> — 2001-05-02T05:02:09Z

    On Mon, Apr 30, 2001 at 07:12:16PM -0400, Tom Lane wrote:
> 
> > There will surely be a 7.1.2.  I vote against waiting for it.
> 
> Possibly, but one hopes 7.1.2 will be a few months away ...

	Is there a chance for the %TYPE patch for PL/pgSQL to make it into
7.1.2?

	-Roberto
-- 
+----| http://fslc.usu.edu USU Free Software & GNU/Linux Club |------+
  Roberto Mello - Computer Science, USU - http://www.brasileiro.net 
       http://www.sdl.usu.edu - Space Dynamics Lab, Developer    
Junior, quit playing with your floppy!

  22. Re: v7.1.1 branched and released on Tuesday ...

    Tom Lane <tgl@sss.pgh.pa.us> — 2001-05-02T05:10:39Z

    Roberto Mello <rmello@cc.usu.edu> writes:
> 	Is there a chance for the %TYPE patch for PL/pgSQL to make it into
> 7.1.2?

We are not in the habit of putting new features into dot-releases.
I'd have to vote against this, particularly seeing that the patch
in question is unreviewed and untested...

			regards, tom lane

  23. Re: [HACKERS] Re: date conversion (was Re: Re: v7.1.1 branched and released on Tuesday ...)

    Thomas Lockhart <lockhart@alumni.caltech.edu> — 2001-05-10T13:22:32Z

    > I extracted from Ayal the info that he was using timezone
> 'Asia/Jerusalem'.  That zone has the interesting property that
> the DST transitions happen *at midnight*, not at a sane hour like 2AM.
> I suspect that that is triggering various & sundry bugs in older
> versions of mktime().

Ahhh! So "GMT+2" was just an approximation, eh? :/

> On a relatively recent Linux (LinuxPPC 2000/Q4) the worst misbehavior
> I can find is
...
> However on an older Linux (RedHat 5.1) I get:
...
> I recommend that all uses of tm->tm_gmtoff from mktime() be guarded
> along the lines of
>         if (tm->tm_isdst >= 0)
>                 believe gmtoff
>         else
>                 assume GMT

I'm not sure that tm_isdst == -1 is a legitimate indicator for mktime()
failure on all platforms; it indicates "don't know", but afaik there is
no defined behavior for the rest of the fields in that case. Can we be
assured that for all platforms the other fields are not damaged?

> However, this still does not account for the reported failure of date()
> since that code path doesn't use the returned value of *tzp --- and
> indeed I get the right thing from select date('1993-04-02'), despite
> the failure of mktime().  Probably the behavior of mktime() in this
> situation varies across different glibc releases.
...
> which is just what you'd expect if mktime() fails for this input;
> I suppose there's nothing we can do about that except advise people
> to update to a less broken libc...

Not sure how much code we should put in to guard for cases we can't even
test (RH 5.1 is pretty old).

                       - Thomas

  24. Re: [HACKERS] Re: date conversion (was Re: Re: v7.1.1 branched and released on Tuesday ...)

    Tom Lane <tgl@sss.pgh.pa.us> — 2001-05-10T13:55:50Z

    Thomas Lockhart <lockhart@alumni.caltech.edu> writes:
> I'm not sure that tm_isdst == -1 is a legitimate indicator for mktime()
> failure on all platforms; it indicates "don't know", but afaik there is
> no defined behavior for the rest of the fields in that case. Can we be
> assured that for all platforms the other fields are not damaged?

We can't; further investigation showed that another form of the problem
was mktime() setting the y/m/d/h/m/s fields one hour earlier than what
it was given --- ie, pass it 00:00:00 of a DST forward transition date,
get back neither 00:00:00 nor 01:00:00 (either of which would be
plausible) but 23:00:00 of the day before!

What I did about this was to coalesce all of the three or four places
that use mktime just to probe for DST status into a single routine
(DetermineLocalTimeZone) that is careful to pass mktime a copy of the
original struct tm.  No matter how brain dead the system mktime is,
it can't screw up the other fields that way ;-).  Then we trust
tm_isdst and tm_gmtoff only if tm_isdst >= 0.  Possibly we'll find
that it'd be a good idea to test also for return value == -1, but
the tm_isdst test seems to be sufficient for the known bug cases.

> Not sure how much code we should put in to guard for cases we can't even
> test (RH 5.1 is pretty old).

Yeah, but the above-described behavior is reported on RH 7.1 (by two
different people).  I'm afraid we can't ignore that...

			regards, tom lane