Цитат от Bill Moran <[EMAIL PROTECTED]>:
"Usama Dar" <[EMAIL PROTECTED]> wrote:
On Dec 30, 2007 3:51 AM, Bozhan <[EMAIL PROTECTED]> wrote:
>
> The following bug has been logged online:
>
> Bug reference: 3845
> Logged by: Bozhan
> Email address: [EMAIL PROTECTED]
> Post
Hi all,
I found out this morning that entering CTRL \ at the psql prompt will
make psql dump core. The is reproducible on the two machines I have
here. Another server running downtown just quits without dumping core.
All are running 8.2.5 on OpenBSD.
I thought I was in the editor, and that k
On OS X (10.4.11) with Postgres 8.2.4, control-\ in psql just quits
(drops back to shell prompt).
On Jan 3, 2008, at 12:42 PM, Jeff Ross wrote:
Hi all,
I found out this morning that entering CTRL \ at the psql prompt
will make psql dump core. The is reproducible on the two machines I
hav
Jeff Ross wrote:
> Hi all,
>
> I found out this morning that entering CTRL \ at the psql prompt will make
> psql dump core. The is reproducible on the two machines I have here.
> Another server running downtown just quits without dumping core.
This is normal and expected. Ctrl-\ is SIGABRT. I
I believe this is expected behavior the Ctrl-\ keystroke will cause a SIGQUIT
to the current process. Any program that doesn't explicitly handle SIGQUIT
will abort.
Regards,
Shelby Cain
- Original Message
From: Jeff Ross <[EMAIL PROTECTED]>
To: PostgreSQL
Sent: Thursday, January 3,
Shelby Cain wrote:
I believe this is expected behavior the Ctrl-\ keystroke will cause a SIGQUIT
to the current process. Any program that doesn't explicitly handle SIGQUIT
will abort.
Regards,
Shelby Cain
Okay, thanks for the reply, and sorry for the noise.
Jeff
-
Hi everyone --
Sorry to revisit a dead horse, but I wanted to clear up some misinformation
--
On Dec 31, 2007 5:35 PM, Tom Lane <[EMAIL PROTECTED]> wrote:
> "Mason Hale" <[EMAIL PROTECTED]> writes:
> >> This could be the kernel's fault, but I'm wondering whether the
> >> RAID controller is going
I encountered this bug recently - and thought I'd have a try at seeing
what might fix it.
Taking an exclusive lock on the to-be-dropped table immediately (i.e in
RemoveRel) seems to be enough to prevent the drop starting while an
index is being created in another session. So it "fixes" the iss
Tom Lane escribió:
> Given this, and the index corruption you showed before (the wrong
> sibling link, which would represent index breakage quite independent of
> what was in the heap), and the curious contents of your WAL files
> (likewise not explainable by anything going wrong within a table),
