Re: pg_restore 7.4.7 locks itself out

Tom Lane wrote:
> Alban Hertroys <alban(at)magproductions(dot)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(at)magproductions(dot)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 //