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

Re: [COMMITTERS] pgsql: Assorted cleanups in preparation for using a map file to support

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Simon Riggs <simon(at)2ndquadrant(dot)com>
Cc: pgsql-hackers(at)postgreSQL(dot)org
Subject: Re: [COMMITTERS] pgsql: Assorted cleanups in preparation for using a map file to support
Date: 2010-02-03 15:48:20
Message-ID: 10922.1265212100@sss.pgh.pa.us (view raw or flat)
Thread:
Lists: pgsql-committerspgsql-hackers
Simon Riggs <simon(at)2ndQuadrant(dot)com> writes:
> On Wed, 2010-02-03 at 01:14 +0000, Tom Lane wrote:
>> 1. Get rid of inval.c's dependency on relfilenode, by not having it emit
>> smgr invalidations as a result of relcache flushes.  Instead, smgr sinval
>> messages are sent directly from smgr.c when an actual relation delete or
>> truncate is done.  This makes considerably more structural sense and allows
>> elimination of a large number of useless smgr inval messages that were
>> formerly sent even in cases where nothing was changing at the
>> physical-relation level.  Note that this reintroduces the concept of
>> nontransactional inval messages, but that's okay --- because the messages
>> are sent by smgr.c, they will be sent in Hot Standby slaves, just from a
>> lower logical level than before.

> Presumably this means that SHAREDINVALSMGR_ID messages are no longer
> part of the invalidation messages attached to a commit record?

Correct.

> If so, there is some minor code cleanup and comment changes in
> ProcessCommittedInvalidationMessages(). Would you like me to do that, or
> should we wait?

I saw that.  I didn't touch it because it's not directly relevant to
what I'm doing right now, but I would like to go back and see whether
that routine can't be got rid of completely.  It seems to me to be a
very klugy substitute for having enough information.  I'm inclined to
think that we should emit an sinval message (or maybe better a separate
WAL entry) for initfile removal, instead of trying to reverse-engineer
whether one happened.

			regards, tom lane

In response to

Responses

pgsql-hackers by date

Next:From: Michael LedfordDate: 2010-02-03 15:55:47
Subject: Re: Recent vendor SSL renegotiation patches break PostgreSQL
Previous:From: Chris CampbellDate: 2010-02-03 15:35:00
Subject: Re: Recent vendor SSL renegotiation patches break PostgreSQL

pgsql-committers by date

Next:From: Simon RiggsDate: 2010-02-03 16:21:26
Subject: Re: [COMMITTERS] pgsql: Assorted cleanups in preparation for using a map file to support
Previous:From: Michael MeskesDate: 2010-02-03 13:56:27
Subject: pgsql: Fixed some typos in ECPG regression test suite that resulted in

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