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

pgsql: During Hot Standby, set DatabasePath correctly during relcache

From: sriggs(at)postgresql(dot)org (Simon Riggs)
To: pgsql-committers(at)postgresql(dot)org
Subject: pgsql: During Hot Standby, set DatabasePath correctly during relcache
Date: 2010-01-09 16:49:27
Message-ID: 20100109164927.D3FC37541B9@cvs.postgresql.org (view raw or flat)
Thread:
Lists: pgsql-committers
Log Message:
-----------
During Hot Standby, set DatabasePath correctly during relcache init file
deletion, so that we attempt to unlink the correct filepath. unlink()
errors are ignorable there, so lack of a DatabasePath initialization step
did not cause visible problems until a related bug showed up on Solaris.  

Code refactored from xact_redo_commit() to
ProcessCommittedInvalidationMessages() in inval.c. Recovery may replay
shared invalidation messages for many databases, so we cannot 
SetDatabasePath() once as we do in normal backends. Read the databaseid
from the shared invalidation messages, then set DatabasePath 
temporarily before calling RelationCacheInitFileInvalidate().

Problem report by Robert Treat, analysis and fix by me.

Modified Files:
--------------
    pgsql/src/backend/access/transam:
        xact.c (r1.279 -> r1.280)
        (http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/backend/access/transam/xact.c?r1=1.279&r2=1.280)
    pgsql/src/backend/utils/cache:
        inval.c (r1.91 -> r1.92)
        (http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/backend/utils/cache/inval.c?r1=1.91&r2=1.92)
    pgsql/src/include/storage:
        sinval.h (r1.55 -> r1.56)
        (http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/include/storage/sinval.h?r1=1.55&r2=1.56)

pgsql-committers by date

Next:From: Tom LaneDate: 2010-01-09 16:55:00
Subject: Re: [COMMITTERS] pgsql: Also update ChangerLog file.
Previous:From: Andrew DunstanDate: 2010-01-09 15:25:41
Subject: pgsql: Provide regression testing for plperlu, and for plperl+plperlu

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