Re: [BUGS] BUG #3845: tray icon that service is running
Цитат от 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] > PostgreSQL version: 8.3-beta4 > Operating system: WinfowsXP > Description: tray icon that service is running > Details: > > postgres needs icon in tray to show that service is running. to > stop/start/restart postgres maybe. > MSSQL and MySQL have such tray application. > thanks Huh? In the Windows world, the GUI is inseperable from the OS. Now, on a server, I can't imagine the point. I mean, do you sit, logged in to your server, watching the tray to see if PG is running or not? I can, however, see it being a nice addition for someone who's running PG on their desktop as part of a development environment. In any case, I doubt it deserves to be part of PostgreSQL proper. If someone is interested, probably a pgfoundry project would make sense. -- Bill Moran Collaborative Fusion Inc. [EMAIL PROTECTED] Phone: 412-422-3463x4023 ok. i just suggest it . i don't use postgres offten. but week ago i found some desktop application which uses postgres as backend SQL . so i don't sit logged on my server, i sit logged to my desktop :) it is accounting software. everything went fine. application worked and so on... i forgot about it and two days later i see in task manager that postgres is running. the bug was someting like suggestion.:) cheers PS. i don't care if you put tray icon or not! :) - Sportingbet.com 15,000 евро всяка седмица в награди от залози на Шампионска Лига! http://bg.sportingbet.com/t/index.aspx?affiliate=mailbg10
[BUGS] ctrl \ makes psql 8.2.5 dump core
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 key combination invokes nano's search and replace function. [EMAIL PROTECTED]:/var/www/wykids/training-calendar $ psql --version psql (PostgreSQL) 8.2.5 contains support for command-line editing [EMAIL PROTECTED]:/var/www/wykids/training-calendar $ psql wykids Welcome to psql 8.2.5, the PostgreSQL interactive terminal. Type: \copyright for distribution terms \h for help with SQL commands \? for help with psql commands \g or terminate with semicolon to execute query \q to quit [EMAIL PROTECTED] localhost# Quit (core dumped) The core file is less than a meg in size, so I can either upload it to our web site or e-mail it directly to someone if anyone is interested. Thanks, Jeff Ross ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [BUGS] ctrl \ makes psql 8.2.5 dump core
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 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 key combination invokes nano's search and replace function. [EMAIL PROTECTED]:/var/www/wykids/training-calendar $ psql --version psql (PostgreSQL) 8.2.5 contains support for command-line editing [EMAIL PROTECTED]:/var/www/wykids/training-calendar $ psql wykids Welcome to psql 8.2.5, the PostgreSQL interactive terminal. Type: \copyright for distribution terms \h for help with SQL commands \? for help with psql commands \g or terminate with semicolon to execute query \q to quit [EMAIL PROTECTED] localhost# Quit (core dumped) The core file is less than a meg in size, so I can either upload it to our web site or e-mail it directly to someone if anyone is interested. Thanks, Jeff Ross ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings Douglas Toltzman [EMAIL PROTECTED] (910) 526-5938
Re: [BUGS] ctrl \ makes psql 8.2.5 dump core
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. If somewhere it aborts without dumping core, it's because you have a zero "core size" ulimit setting. -- Alvaro Herrerahttp://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
Re: [BUGS] ctrl \ makes psql 8.2.5 dump core
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, 2008 11:42:26 AM Subject: [BUGS] ctrl \ makes psql 8.2.5 dump core 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 key combination invokes nano's search and replace function. [EMAIL PROTECTED]:/var/www/wykids/training-calendar $ psql --version psql (PostgreSQL) 8.2.5 contains support for command-line editing [EMAIL PROTECTED]:/var/www/wykids/training-calendar $ psql wykids Welcome to psql 8.2.5, the PostgreSQL interactive terminal. Type: \copyright for distribution terms \h for help with SQL commands \? for help with psql commands \g or terminate with semicolon to execute query \q to quit [EMAIL PROTECTED] localhost# Quit (core dumped) The core file is less than a meg in size, so I can either upload it to our web site or e-mail it directly to someone if anyone is interested. Thanks, Jeff Ross ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings Never miss a thing. Make Yahoo your home page. http://www.yahoo.com/r/hs ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [BUGS] ctrl \ makes psql 8.2.5 dump core
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 ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [BUGS] Duplicate values found when reindexing unique index
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 south. > > > To clarify a bit further -- on the production server, the data is > written to > > a 10-disk RAID 1+0, but the pg_xlog directory is symlinked to a > separate, > > dedicated SATA II disk. > > > There is a similar setup on the standby server, except that in addition > to > > the RAID for the data, and a separate SATA II disk for the pg_xlog, > there is > > another disk (also SATA II) dedicated for the archive of wal files > copied > > over from the production server. > It turns out that the separate SATA II disk was configured as a single-disk JBOD on the same controller as the 10-disk RAID 1+0. Since we've seen corruption in the data directory (on the RAID) and in the pg_xlog directory (on the SATA II disk) the RAID controller is one of the few common elements between those two partitions and hence is highly suspect, and may dispel some of the mystery with our situation. We will be replacing the RAID controller in short order. For what it is worth it is an Adaptec 31605 with a battery backup module. > > Oh. Maybe it's one of those disks' fault then. Although WAL corruption > would not lead to corruption of the primary DB as long as there were no > crash/replay events. Maybe there is more than one issue here, or maybe > it's the kernel's fault after all. > > Given the new information about the RAID controller is managing all the disks in the question (after all) -- if the RAID controller is going south, then there would be no need for a crash/replay event for that corruption to make it into the primary DB. Seems to be pretty damning evidence against the RAID controller, agreed? Mason
Re: [BUGS] BUG #3833: Index remains when table is dropped
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 issue - possible objections that I can think of are: 1/ Not a general solution to multi session dependent drop/create of objects other than tables (unless we do 2/) 2/ Using this approach in all object dropping code may result in deadlocks (but is this worse than dangling/mangled objects?) Now, I'm conscious that there could be other show stopper reasons for *not* doing this that I have not thought of, but figured I'd post in case the idea was useful. Thoughts? Cheers Mark *** src/backend/commands/tablecmds.c.orig Wed Jan 2 13:58:05 2008 --- src/backend/commands/tablecmds.c Wed Jan 2 13:46:43 2008 *** *** 514,519 --- 514,522 object.objectId = relOid; object.objectSubId = 0; + //Try a lock here! + LockRelationOid(relOid, ExclusiveLock); + performDeletion(&object, behavior); } ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [BUGS] Duplicate values found when reindexing unique index
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), > I'm starting to think that Occam's razor says you've got hardware > problems. Or maybe a kernel-level bug that is causing writes to get > discarded. FWIW, on a customer's setup we've seen something that looks very much like this: table pages being rewritten by something that I couldn't identify, but which certainly weren't normal table or index pages. On looking at your report and diagnosis, I'm inclined to think that they were WAL records due to the similarity and regularity. (I'll take a look again). I also wrote them off as hardware failure or kernel bugs. I don't think we've been seen the problem again. But what happened in the end was that the customer asked us whether we could make something about CRC'ing the files we use in order to detect system failure proactively. -- Alvaro Herrerahttp://www.CommandPrompt.com/ PostgreSQL Replication, Consulting, Custom Development, 24x7 support ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
