Tom Lane wrote:
>"Oliver Elphick" <[EMAIL PROTECTED]> writes:
>>> FATAL 2: Checkpoint lock is busy while data base is shutting down
>> It's not just on Alpha; I've seen that on my i386 Linux system.
>FWIW, I do *not* see this behavior on HPUX. It seems perfectly
>reproducible on the
"Oliver Elphick" <[EMAIL PROTECTED]> writes:
>> Smart Shutdown request at Thu Dec 28 02:41:49 2000
>> DEBUG: shutting down
>> FATAL 2: Checkpoint lock is busy while data base is shutting down
>> Shutdown failed - abort
> It's not just on Alpha; I've seen that on my i386 Linux system.
Oooh, th
Tom Lane wrote:
...
>system. Curiously, however, the system fails when you try to shut
>it down:
>
>Smart Shutdown request at Thu Dec 28 02:41:49 2000
>DEBUG: shutting down
>FATAL 2: Checkpoint lock is busy while data base is shutting down
>Shutdown failed - abort
>
>I have no
On 27 Dec 2000 at 21:45 (-0500), Tom Lane wrote:
| Brent Verner <[EMAIL PROTECTED]> writes:
| > | Hm. I thought I'd fixed that. Are you up to date on
| > | src/backend/utils/adt/oid.c ? Current CVS has rev 1.42.
|
| > yup. got that version -- 1.42 2000/12/22 21:36:09 tgl
|
| You're right, it
Brent Verner <[EMAIL PROTECTED]> writes:
> | Hm. I thought I'd fixed that. Are you up to date on
> | src/backend/utils/adt/oid.c ? Current CVS has rev 1.42.
> yup. got that version -- 1.42 2000/12/22 21:36:09 tgl
You're right, it was still broken :-(. I think I've got it now, though.
Oliver
Brent Verner <[EMAIL PROTECTED]> writes:
> these are the steps leading up the the assignment of the fscked
> fcache->fcinfo.arg[i] at execQual.c:603, which is what will eventually
> blow up ExecEvalFieldSelect.
That looks OK as far as it goes. Inside ExecEvalVar, you need to look
at the tuple_ty
Brent Verner <[EMAIL PROTECTED]> writes:
> after hours in the gdb-hole, I see this... maybe a clue? :)
I don't think that comment means anything. Possibly it's a leftover
from a time when there was something unportable there. But if att_align
were broken on Alphas, you'd have a lot worse proble
On 26 Dec 2000 at 23:41 (-0500), Tom Lane wrote:
| Brent Verner <[EMAIL PROTECTED]> writes:
| > | Please apply it locally and let me know what you find.
|
| > what I'm seeing now is much the same.
|
| Drat. More to do, then.
after hours in the gdb-hole, I see this... maybe a clue? :)
src/incl
On 26 Dec 2000 at 23:41 (-0500), Tom Lane wrote:
| Brent Verner <[EMAIL PROTECTED]> writes:
| > | Please apply it locally and let me know what you find.
|
| > what I'm seeing now is much the same.
|
| Drat. More to do, then.
|
| > i've been in circles trying to figure out where fcinfo->arg is
On 26 Dec 2000 at 23:41 (-0500), Tom Lane wrote:
| Brent Verner <[EMAIL PROTECTED]> writes:
| > | Please apply it locally and let me know what you find.
|
| > what I'm seeing now is much the same.
sorry, I sent the previous email w/o the details of the different
behavior. Inside ExecEvalFieldSe
Brent Verner <[EMAIL PROTECTED]> writes:
> | Please apply it locally and let me know what you find.
> what I'm seeing now is much the same.
Drat. More to do, then.
> i've been in circles trying to figure out where fcinfo->arg is filled.
> can you point me toward that?
See src/backend/utils/fm
On 26 Dec 2000 at 14:41 (-0500), Tom Lane wrote:
| I wrote:
| > ... What I'm thinking about doing is setting typmod of
| > an entire-tuple function argument to sizeof(Pointer), rather than
| > the default -1, to indicate that a pointer representation is being
| > used. Comments, hackers?
|
| Her
12 matches
Mail list logo
