Skip site navigation (1) Skip section navigation (2)

Re: Can someone verify CVS tip on Win32?

From: Reini Urban <rurban(at)x-ray(dot)at>
To: pgsql-hackers-win32(at)postgresql(dot)org
Subject: Re: Can someone verify CVS tip on Win32?
Date: 2004-11-18 12:09:17
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers-win32
Tom Lane schrieb:
> Andrew Dunstan <andrew(at)dunslane(dot)net> writes:
>>Tom Lane wrote:
>>>Hmm ... I have a theory about it, but I'm not sure how to reproduce the
>>>problem.  How many databases have you created in the installation that
>>>the contrib installcheck is running against?  
>>Just what make installcheck / make contrib installcheck  runs.
> OK.  I still haven't been able to reproduce it, but the place where it
> is failing is consistent with my theory, which is:
> 1. CREATE DATABASE creates a pg_database row for "regression" that is
> the last or nearly last row that will fit into block 0 of pg_database.
> It then flushes this block to disk to ensure that new backends can see
> the row in GetRawDatabaseInfo.
> 2. then does several ALTER DATABASE operations.  These
> will mark the original row dead and make a new row.  At the end of this,
> I hypothesize that the live copy of the "regression" row is in
> pg_database block 1, not block 0.  And it's not been flushed to disk,
> because ALTER DATABASE fails to do that.
> 3. (Here's the hard-to-reproduce part.)  Assume that something causes
> block 0, but not block 1, of pg_database to be flushed from shared
> buffers to disk.
> 4. Now, an incoming backend will see the original pg_database row for
> "regression" as committed dead, so it'll ignore it.  It can't see the
> live row because that's not been flushed to disk; it's only in shared
> buffers.  Ergo, GetRawDatabaseInfo fails.
> The problem goes away as soon as a checkpoint happens, but it's still
> possible for the regression tests to fail this way.
> A reasonable theory about step 3 is that the bgwriter chooses to write
> out block 0 at just the right time.  This would happen infrequently
> enough to explain why we've not seen this reported before.
> This theory explains why the failure consistently happens at the same
> place in the test sequence, and why that place is machine-architecture
> dependent: it can only happen when a certain number of pg_database rows
> have been created and deleted, and the magic number depends on the
> machine MAXALIGN value because that affects the size of the rows.
> The fix of course is that ALTER DATABASE must flush pg_database to disk,
> just as RENAME does.

This also explains my strange regression problems on cygwin. Thanks for 
the change. Everything looks much easier now.

Reini Urban

In response to

pgsql-hackers-win32 by date

Next:From: ctnanDate: 2004-11-18 19:18:20
Subject: There's any version that work on Windows 2000??
Previous:From: Tom LaneDate: 2004-11-18 01:24:23
Subject: Re: Can someone verify CVS tip on Win32?

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group