Re: [HACKERS] md.c is feeling much better now, thank you

I have just committed changes that address the problem of relcache
entries not being updated promptly after another backend issues
a shared-invalidation report. LockRelation() now checks for sinval
reports just after acquiring a lock, and the relcache entry will be
updated if necessary --- or, if the relation has actually disappeared
entirely, an elog(ERROR) will occur.

As a side effect of the relcache update, the underlying md.c/fd.c files
will be closed, and then reopened if necessary. This should solve our
concerns about vacuum.c not being able to truncate relations safely.

There is still some potential for misbehavior as a result of the fact
that the parser looks at relcache entries without bothering to obtain
any kind of lock on the relation. For example:

-- In backend #1:
regression=> create table z1 (f1 int4);
CREATE
regression=> select * from z1;
f1
--
(0 rows)

regression=> begin;
BEGIN

-- In backend #2:
regression=> alter table z1 add column f2 int4;
ADD
regression=>

-- In backend #1:
regression=> select * from z1;
f1
--
(0 rows)

-- parser uses un-updated relcache entry and sees only one column in z1.
-- However, the relcache *will* get updated as soon as we either lock a
-- table or do the CommandCounterIncrement() at end of query, so a second
-- try sees the new info:
regression=> select * from z1;
f1|f2
--+--
(0 rows)

regression=> end;
END

The window for problems is pretty small: you have to be within a
transaction (otherwise the StartTransaction will notice the sinval
report), and your very first query after the other backend does
ALTER TABLE has to reference the altered table. So I'm not sure
this is worth worrying about. But perhaps the parser ought to obtain
the weakest possible lock on each table referenced in a query before
it does any looking at the attributes of the table. Comments?

I believe these changes ought to be committed into REL6_5 as well,
but it might be wise to test them a little more in current first.
Or would people find it easier to test them against 6.5 databases?
In that case maybe I should just commit them now...

regards, tom lane