Re: race condition for drop schema cascade?

From: "Jim Buttafuoco" <jim(at)contactbda(dot)com>
To: Andrew Dunstan <andrew(at)dunslane(dot)net>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Kurt Roeckx <Q(at)ping(dot)be>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: race condition for drop schema cascade?
Date: 2004-12-29 20:47:28
Message-ID: 20041229204422.M98299@contactbda.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Andrew/all

I have not seen any problems on my MIPS systems since the rebuild ext3 (I ran badblocks during fs creation). I should
have the alpha running about soon, the disk died and I am waiting a replacement. I do believe there is a floating
point problem with older alpha's out there. The seems to have a problem with INFINITY and NAN's. I did some checking
on the net and the problem seems know (with no solution). Maybe something can go into the readme or such. If anyone
is interested in looking at this for > pg8.0 I can give SSH access in a week or so.

Jim

---------- Original Message -----------
From: Andrew Dunstan <andrew(at)dunslane(dot)net>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Kurt Roeckx <Q(at)ping(dot)be>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Sent: Wed, 29 Dec 2004 13:05:26 -0500
Subject: Re: [HACKERS] race condition for drop schema cascade?

> Tom Lane wrote:
>
> >Andrew Dunstan <andrew(at)dunslane(dot)net> writes:
> >
> >
> >>You're right - my query was not sufficiently specific. There have in
> >>fact been 4 failures:
> >>
> >>
> >
> >
> >
> >>pgbuildfarm=# select sysname, snapshot, stage, branch from build_status
> >>where log ~ 'tablespace "testspace" is not empty.*tablespace "testspace"
> >>is not empty' and not log ~ 'No space left';
> >> sysname | snapshot | stage | branch
> >> --------+---------------------+--------------+--------
> >> hare | 2004-12-09 05:15:05 | Check | HEAD
> >> otter | 2004-12-11 15:50:09 | Check | HEAD
> >> otter | 2004-12-15 15:50:10 | Check | HEAD
> >> gibbon | 2004-12-28 23:55:05 | InstallCheck | HEAD
> >>
> >>
> >
> >Why does the last show as an "install" failure?
> >
> >
>
> We run the standard regression suite twice - the failure on Gibbon
> occurred on the second of these. Clearly this is very transient.
>
> >Anyway, given the small number of machines involved, I'm once again
> >wondering what filesystem they are using. They wouldn't be running
> >the check over NFS, by any chance, for instance?
> >
> >The theory that is in my mind is that the bgwriter could have written
> >out a page for the table in the test tablespace, and thereby be holding
> >an open file pointer for it. On standard Unix filesystems this would
> >not disrupt the backend's ability to unlink the table at the DROP stage,
> >but I'm wondering about nonstandard filesystems ...
> >
> >
> >
>
> Jim Buttafuoco reported on December 16th that he had rebuilt the
> filesystem on his MIPS box - I assume this means that he isn't using
> NFS. In any case, we have not seen the problem since then. His Alpha box
> has not been reporting buildfarm results since before then.
>
> The Cygwin box is running on NTFS - and we know we've encountered plenty
> of problems with unlinking on Windows.
>
> I know it's not much to go on.
>
> cheers
>
> andrew
>
> ---------------------------(end of broadcast)---------------------------
> TIP 3: if posting/reading through Usenet, please send an appropriate
> subscribe-nomail command to majordomo(at)postgresql(dot)org so that your
> message can get through to the mailing list cleanly
------- End of Original Message -------

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Jim Buttafuoco 2004-12-29 20:49:27 Re: race condition for drop schema cascade?
Previous Message Tom Lane 2004-12-29 18:54:52 Re: pg_class changes for group ownership