On 05/10/2011 01:07 PM, Richard Broersma wrote:
> 0:003> G
> (4ac.158): Access violation - code c0000005 (first chance)
> First chance exceptions are reported before any exception handling.
> This exception may be expected and handled.
> eax=ffffffff ebx=fffffff4 ecx=ffffffff edx=fffffffd esi=00000000 edi=00000000
> eip=0063b890 esp=00d4f614 ebp=00d4f7c0 iopl=0 nv up ei ng nz na pe cy
> cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 efl=00010287
> postgres!datebsearch+0x30:
> 0063b890 0fbe0c97 movsx ecx,byte ptr [edi+edx*4] ds:0023:fffffff4=??
> 0:000> ~*k
>
> . 0 Id: 4ac.158 Suspend: 1 Teb: 7ffdf000 Unfrozen
> ChildEBP RetAddr
> 00d4f620 0063d738 postgres!datebsearch+0x30
> [c:\pginstaller-repo\postgres.windows\src\backend\utils\adt\datetime.c
> @ 3579]
>
That's interesting...it's going crazy here:
3565 /* datebsearch()
3566 * Binary search -- from Knuth (6.2.1) Algorithm B. Special
case like this
3567 * is WAY faster than the generic bsearch().
3568 */
3569 static const datetkn *
3570 datebsearch(const char *key, const datetkn *base, int nel)
3571 {
3572 const datetkn *last = base + nel - 1,
3573 *position;
3574 int result;
3575
3576 while (last >= base)
3577 {
3578 position = base + ((last - base) >> 1);
3579 result = key[0] - position->token[0];
So something about that is getting really confused when searching back
to negative infinity, but seemingly only on Windows.
Thanks for the great detective work help, I'll bounce this over to
pgsql-hackers where more people will see it.
--
Greg Smith 2ndQuadrant US greg@2ndQuadrant.com Baltimore, MD
