From: Giles Lean on 5 Apr 2010 00:11 Josh Berkus <josh(a)agliodbs.com> wrote: > Could this be an issue with VirtualBox? Have you used this VM for > testing before? As I've hit a few bugs in VirtualBox, this is a definite possibility. (So is Tom's suggestion of inconsistent sources.) Because I could, I just installed a new CentOS 5.4 (no updates, 64 bit) VM on VirtualBox 3.1.6 hosted on OX X 10.5.8 (Leopard) with bridged networking. I installed postgresql-9.0alpha5-revised.tar.bz2, compiled it with the default options, ran 'make check' and everything passed: ======================= All 122 tests passed. ======================= I'm not sure that this helps much as it doesn't rule out VirtualBox, but my experience with it running Linux has been positive. I do reboot the host at the first hint of trouble and that fixes many ills; VirtualBox is not what I would consider production ready, but it's competitive and I switched to it from Parallels which I'd paid for. I'd trial VMware but it doesn't claim to support the *BSDs which is a feature I need, and I've seen at least one report where it didn't work well with FreeBSD. That's hearsay, of course, but it makes me cautious, particularly when I've got something that works "well enough". Regards, Giles -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Devrim =?ISO-8859-1?Q?G=DCND=DCZ?= on 5 Apr 2010 07:28 On Sun, 2010-04-04 at 12:19 -0400, Tom Lane wrote: > Hitoshi Harada <umi.tanuki(a)gmail.com> writes: > > I cannot figure out at all what is wrong. Have any idea? > > Since nobody else is reporting this, it seems like it must be either > something messed up about your system, or something wrong with your > copy of the PG sources. The only times that I see this issue over the last years is when I build PostgreSQL RPMs in the xen-based virtual machines. It is rare, and it happens when there are 10+ parallel builds. ....I'm pretty sure that it is related to the available resources during build time... -- Devrim GÃNDÃZ PostgreSQL DanıÅmanı/Consultant, Red Hat Certified Engineer PostgreSQL RPM Repository: http://yum.pgrpms.org Community: devrim~PostgreSQL.org, devrim.gunduz~linux.org.tr http://www.gunduz.org Twitter: http://twitter.com/devrimgunduz
From: Hitoshi Harada on 5 Apr 2010 11:49 2010/4/5 Giles Lean <giles.lean(a)pobox.com>: > > Josh Berkus <josh(a)agliodbs.com> wrote: > >> Could this be an issue with VirtualBox? Have you used this VM for >> testing before? > > I'm not sure that this helps much as it doesn't rule out > VirtualBox, but my experience with it running Linux has > been positive. I do reboot the host at the first hint of > trouble and that fixes many ills; VirtualBox is not what > I would consider production ready, but it's competitive > and I switched to it from Parallels which I'd paid for. Just note, I rebooted the guest VM today and retried but things are as before. The host reboot doesn't affect either. I also tried another CentOS5.4 VM on the same VirtualBox and succeeded to build. Another RHEL Server 5.2 (Tikanga) x86_64 real machine can also build alpha5. Seems quite hopeless but it's surely reproducible. Regards, -- Hitoshi Harada -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Giles Lean on 5 Apr 2010 21:10 Hitoshi Harada <umi.tanuki(a)gmail.com> wrote: > Just note, I rebooted the guest VM today and retried but things are as > before. The host reboot doesn't affect either. Bad luck. :-( > I also tried another CentOS5.4 VM on the same VirtualBox and succeeded > to build. Another RHEL Server 5.2 (Tikanga) x86_64 real machine can > also build alpha5. Well, that sounds like a workaround: at least you can continue work, although it doesn't leave a lot of confidence that you won't have to reinstall _another_ virtual machine from time to time. :-( > Seems quite hopeless but it's surely reproducible. They always are, but it can take a while. Back when I used to work in kernel support we had one problem take a year. We were Not Pleased, to put it mildly. (Nor was the main customer seeing it.) We got to the answer in the end, but oh boy, it was ugly on the way, and not our finest moment. (Answer was that someone left 'volatile' off a variable declaration, so it was a race condition. A race condition that came and went as code around the incorrect line of code was changed, so only some patch levels were affected. Plus, like any race condition, customers either tended never to see it or tended to hit it semi-regularly. It was .... difficult. It was't me who solved it; fortunately qsomeone else "owned" it and eventually thought to disassemble all the different patch levels. (He was looking for a compiler bug, unsurprisingly; when the problem first occurred he had only one patch version to deal with as well, so that approach didn't suggest itself first off, and everyone (where "everyone" was quite a lot of people) overlooked the missing 'volatile' during code reviews.) Back to VirtualBox: it blew up on me _again_ yesterday, refusing to boot FreeBSD as anything but 32 bit, no matter how I coaxed it and no matter that it had been running a 64bit installation for weeks before that. As booting a FreeBSD 64 bit kernel in 32 bit mode doesn't work (surprise!) I have exorcised VirtualBox from my system (like Parallels before it, which was even worse), and am deciding today qwhat real hardware I shall buy to replace VirtualBox. (Before anyone suggests VMware Fusion: they're honest enough to admit to not supporting one of the operating systems I care about, so that's not a solution, unfortunately.) So I can't test with VirtualBox anymore to help out, sorry. Giles -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
First
|
Prev
|
Pages: 1 2 Prev: "pg_stat_tmp/pgstat.stat": Stale NFS file handle Next: [HACKERS] Nice hint on table aliasing! |