Re: pg_restore 7.4.7 locks itself out
От | Alban Hertroys |
---|---|
Тема | Re: pg_restore 7.4.7 locks itself out |
Дата | |
Msg-id | 443A8452.2090604@magproductions.nl обсуждение исходный текст |
Ответ на | Re: pg_restore 7.4.7 locks itself out (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: pg_restore 7.4.7 locks itself out
(Peter Eisentraut <peter_e@gmx.net>)
|
Список | pgsql-general |
Tom Lane wrote: > Alban Hertroys <alban@magproductions.nl> writes: > >>postgres 15092 0.0 0.3 43692 12924 ? D 14:11 0:00 postgres: >>postgres vh3_live [local] INSERT > > > This process is not blocked on a lock: it's waiting for disk I/O. > > Thoughts that come to mind include (1) it's going fine and you're not > patient enough; (2) something wrong with your disk drive; (3) DB is > mounted across NFS and you're having network problems. Really? I've been waiting for it to finish ever since, amounting to almost 4 hours now. It doesn't seem to have progressed one bit since it started. Well, I'll let it run overnight and see what has happened by tomorrow morning. As for points (2) and (3); I was logged in on the machine where the database lives, which is AFAIK on a SATA RAID configuration of some type (don't know the details). If it's a mirror (and I believe it is), that kind of makes the bad-disk scenario not too plausible, and I'd think we would have noticed something like that in other ways too. That server handles most of our diskless machines - one of which I'm using (No, I wasn't restoring from there...). >>I suppose this may be fixed in a newer version, but our sysadmin'd >>prefer to stay with versions packaged by the distributor (Debian in this >>case). > > If your sysadmin wants to use 7.4.7 rather than 7.4.<latest>, he needs > swift application of a cluestick. I'll grant that there might be > application-compatibility reasons to stay on 7.4.*, but not to avoid > being up to date in that release series. See > http://developer.postgresql.org/docs/postgres/release-7-4-12.html > and following pages. Well, in this case it seems like the debian package maintainers could use a thorough bat with the cluestick - but I'm biased against debian, so that could be prejudice... <rant> OTOH, our sysadmin can be rather stubborn - I'm in the process of convincing him that it's a bad idea to rely on filesystem backups of the pg data directory for restoring a DB, or at least stop the database while doing so. I'd much rather he'd use dumps, but apparently that takes disk space - no matter how little, apparently. His response is that he's restored the databases twice already this way, and things didn't break - I wonder how he can be sure about that... Trouble is, if he does break the database, I'll be the one to receive the complaints :( Stubborn he is... </rant> Regards, -- Alban Hertroys alban@magproductions.nl magproductions b.v. T: ++31(0)534346874 F: ++31(0)534346876 M: I: www.magproductions.nl A: Postbus 416 7500 AK Enschede // Integrate Your World //
В списке pgsql-general по дате отправления: