Обсуждение: Debian problem...
Ran into a problem. I hosed up postgresql by deleting the data directory. So I thought I would just uninstall and reinstall postgres using Debian packages. Now I have nothing working. Wondering if anyone here has any suggestions on what to do with a Debian installation. If not, I'm checking that list too, but it might be a while...
* Tom Allison (tom@tacocat.net) wrote:
> I hosed up postgresql by deleting the data directory.
erp. That's no good.
> So I thought I would just uninstall and reinstall postgres using Debian
> packages.
> Now I have nothing working.
Huh, odd, that'd normally work, I think.
> Wondering if anyone here has any suggestions on what to do with a Debian
> installation.
Do a full purge of the package and then reinstall it? I could maybe see
an issue if you didn't purge it due to the leftover symlinks in /etc...
You could also try doing a manual pg_createcluster, possibly with a
pg_dropcluster before it to make sure everything gets cleaned out.
Enjoy,
Stephen
Вложения
There's likely someone here that can help you, if you can give us some more info. To start with, did the uninstall even work? Ron Tom Allison wrote: > Ran into a problem. > > I hosed up postgresql by deleting the data directory. > So I thought I would just uninstall and reinstall postgres using > Debian packages. > > Now I have nothing working. > > Wondering if anyone here has any suggestions on what to do with a > Debian installation. > If not, I'm checking that list too, but it might be a while... > > ---------------------------(end of broadcast)--------------------------- > TIP 3: Have you checked our extensive FAQ? > > http://www.postgresql.org/docs/faq >
Maybe some Debian specific commands will help: pg_lsclusters: list clusters you have on the machine; pg_dropcluster: drop an existing cluster; pg_createcluster: create new cluster. Regards. Tom Allison wrote: > Ran into a problem. > > I hosed up postgresql by deleting the data directory. > So I thought I would just uninstall and reinstall postgres using Debian > packages. > > Now I have nothing working. > > Wondering if anyone here has any suggestions on what to do with a Debian > installation. > If not, I'm checking that list too, but it might be a while... > > ---------------------------(end of broadcast)--------------------------- > TIP 3: Have you checked our extensive FAQ? > > http://www.postgresql.org/docs/faq >
I was able get my database working again. Never figured out why... On Sep 11, 2007, at 12:52 AM, 李彦 Ian Li wrote: > > Maybe some Debian specific commands will help: > pg_lsclusters: list clusters you have on the machine; > pg_dropcluster: drop an existing cluster; > pg_createcluster: create new cluster. > > Regards. > > Tom Allison wrote: >> Ran into a problem. >> I hosed up postgresql by deleting the data directory. >> So I thought I would just uninstall and reinstall postgres using >> Debian packages. >> Now I have nothing working. >> Wondering if anyone here has any suggestions on what to do with a >> Debian installation. >> If not, I'm checking that list too, but it might be a while... >> ---------------------------(end of >> broadcast)--------------------------- >> TIP 3: Have you checked our extensive FAQ? >> http://www.postgresql.org/docs/faq > > > ---------------------------(end of > broadcast)--------------------------- > TIP 1: if posting/reading through Usenet, please send an appropriate > subscribe-nomail command to majordomo@postgresql.org so that > your > message can get through to the mailing list cleanly
On Sep 11, 2007, at 5:49 AM, Tom Allison wrote: > > I was able get my database working again. > Never figured out why... My database data (sorry about the redundancy there) is sitting on a RAID1 array with LVM and ReiserFS. I've heard some dissention about the use of ReiserFS and was wondering: true? alternatives?
Hi, Tom Allison schrieb: > > On Sep 11, 2007, at 5:49 AM, Tom Allison wrote: > >> >> I was able get my database working again. >> Never figured out why... > > My database data (sorry about the redundancy there) is sitting on a > RAID1 array with LVM and ReiserFS. > > I've heard some dissention about the use of ReiserFS and was wondering: No problem with RazorFS if your hardware does not fail. But if... chances are you have to use your backup. Alternatively you could use XFS but I'm not sure if it performs better on failing hardware. I guess not. Regards Tino
On 9/12/07, Tino Wildenhain <tino@wildenhain.de> wrote: > Alternatively you could use XFS but I'm not sure if it performs > better on failing hardware. I guess not. Actually I've seen anecdotal evidence that XFS with its aggressive write-caching has caused data-loss in the event of power-failures. I'm not certain how sensible Reiser, which is optimised for efficiency with small files, would be for a postgres data directory in terms of performance. ext3 or jfs maybe? > Regards > Tino Cheers, Andrej
On Sep 12, 2007, at 3:52 AM, Tino Wildenhain wrote: > > Hi, > > Tom Allison schrieb: >> On Sep 11, 2007, at 5:49 AM, Tom Allison wrote: >>> >>> I was able get my database working again. >>> Never figured out why... >> My database data (sorry about the redundancy there) is sitting on >> a RAID1 array with LVM and ReiserFS. >> I've heard some dissention about the use of ReiserFS and was >> wondering: > > No problem with RazorFS if your hardware does not fail. But if... > chances are you have to use your backup. > > Alternatively you could use XFS but I'm not sure if it performs > better on failing hardware. I guess not. > > Regards > Tino Well, when one is looking at hardware failure, the performance doesn't really matter that much. Is EXT3 better for dealing with a RAID1 failure? I know reiserfs does better performance wise, but there's no point in going fast if you can't steer.
On Sep 28, 2007, at 5:09 AM, Tom Allison wrote: > I know reiserfs does better performance wise, but there's no point > in going fast if you can't steer. I recently had to replace 16 Western Digital 10kRPM SATA drives with Hitachi 7.2kRPM drives because the WD drives kept randomly (and falsely) reporting failure to the RAID system. The performance loss was noticeable, but the reliability was more important.