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

Testing needed for recent tablespace hacking

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: pgsql-hackers-win32(at)postgresql(dot)org
Subject: Testing needed for recent tablespace hacking
Date: 2004-08-29 22:26:24
Message-ID: 16275.1093818384@sss.pgh.pa.us (view raw or flat)
Thread:
Lists: pgsql-hackerspgsql-hackers-win32
Would someone check that I didn't break the Windows port with this
recent commit:

  Log Message:
  -----------
  Add WAL logging for CREATE/DROP DATABASE and CREATE/DROP TABLESPACE.
  Fix TablespaceCreateDbspace() to be able to create a dummy directory
  in place of a dropped tablespace's symlink.  This eliminates the open
  problem of a PANIC during WAL replay when a replayed action attempts
  to touch a file in a since-deleted tablespace.  It also makes for a
  significant improvement in the usability of PITR replay.

I had to do some fooling around with platform-specific code, so it's
possible that things are broken.  Please test that the above-mentioned
four commands still work.  Also see if they work when WAL-replayed.
(The easy way to check this is to do one and then "kill -9" the backend
as soon as it completes.)  One test case for the former PANIC bug is to
run the regression tests using "make installcheck", then immediately
start another backend and kill -9 it (you must do this before a
checkpoint occurs in order to exercise the bug case).

Some code I'm particularly worried about is in DROP TABLESPACE:

    /*
     * Okay, try to remove the symlink.  We must however deal with the
     * possibility that it's a directory instead of a symlink --- this
     * could happen during WAL replay (see TablespaceCreateDbspace),
     * and it is also the normal case on Windows.
     */
    if (lstat(location, &st) == 0 && S_ISDIR(st.st_mode))
    {
        if (rmdir(location) < 0)
            ereport(ERROR,
                    (errcode_for_file_access(),
                     errmsg("could not remove directory \"%s\": %m",
                            location)));
    }
    else
    {
        if (unlink(location) < 0)
            ereport(ERROR,
                    (errcode_for_file_access(),
                     errmsg("could not unlink symbolic link \"%s\": %m",
                            location)));
    }

Is there any reason lstat() wouldn't work on Windows?

			regards, tom lane

Responses

pgsql-hackers by date

Next:From: Greg Sabino MullaneDate: 2004-08-29 22:29:19
Subject: Re: psql questions: SQL, progname, copyright dates
Previous:From: Mike RylanderDate: 2004-08-29 22:05:28
Subject: Re: FYI: 8.0beta2 on Monday

pgsql-hackers-win32 by date

Next:From: Johan Paul GluttingDate: 2004-08-30 06:07:48
Subject: Re: pg_dump and pg_restore in batch scripts
Previous:From: Marc G. FournierDate: 2004-08-29 02:47:34
Subject: Re: pgsql-server: Update that 8.0 will support MS Win

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