Re: gitweb is no longer a real-time view

Alvaro Herrera <alvherre(at)2ndquadrant(dot)com> writes:
> Andres Freund wrote:
>> I think the most realistic way to resolve this is to push the current
>> anongit state to master and cherry-pick
>> bc61878682051678ade5f59da7bfd90ab72ce13b ontop it. That way only
>> committers need to deal with rebasing their branches and not everyone
>> else.

> I agree this seems the sanest course of action, but I think it would be
> better to install defenses in the master repo so that forced pushes are
> no longer allowed *before* rebasing gitmaster; otherwise some other
> committer could clobber things again if they don't force-pull their
> trees.

Agreed. I'm astonished that we had this configured this way in the
first place.

FWIW, I noticed something about a "forced update" when I did a git pull
after Kevin's commits. I failed to pay enough attention though. Now
that I look, the xml fix is not in my local history either, and I don't
know what bc61878682051678ade5f59da7bfd90ab72ce13b is because none of
the recent commits have that hash according to my repo:

$ git status
# On branch master
nothing to commit (working directory clean)
$ git log
commit d63977eea3ab18fdec05e370b633d10b9fd20179
Author: Kevin Grittner <kgrittn(at)postgresql(dot)org>
Date: Sun Mar 3 18:38:44 2013 -0600

Remove accidentally-committed .orig file.

commit 3bf3ab8c563699138be02f9dc305b7b77a724307
Author: Kevin Grittner <kgrittn(at)postgresql(dot)org>
Date: Sun Mar 3 18:23:31 2013 -0600

Add a materialized view relations.

A materialized view has a rule just like a view and a heap and
other physical properties like a table. The rule is only used to
populate the table, references in queries refer to the
materialized data.

This is a minimal implementation, but should still be useful in
many cases. Currently data is only populated "on demand" by the
CREATE MATERIALIZED VIEW and REFRESH MATERIALIZED VIEW statements.
It is expected that future releases will add incremental updates
with various timings, and that a more refined concept of defining
what is "fresh" data will be developed. At some point it may even
be possible to have queries use a materialized in place of
references to underlying tables, but that requires the other
above-mentioned features to be working first.

Much of the documentation work by Robert Haas.
Review by Noah Misch, Thom Brown, Robert Haas, Marko Tiikkaja
Security review by KaiGai Kohei, with a decision on how best to
implement sepgsql still pending.

commit b15a6da29217b14f02895af1d9271e84415a91ae
Author: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Date: Sun Mar 3 19:05:47 2013 -0500

Get rid of any toast table when converting a table to a view.

Also make sure other fields of the view's pg_class entry are appropriate
for a view; it shouldn't have relfrozenxid set for instance.

This ancient omission isn't believed to have any serious consequences in
versions 8.4-9.2, so no backpatch. But let's fix it before it does bite
us in some serious way. It's just luck that the case doesn't cause
problems for autovacuum. (It did cause problems in 8.3, but that's out
of support.)

Andres Freund

commit 2b78d101d1d6b1d8533a7b7aeff4d82b10a915f8
Author: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Date: Sun Mar 3 17:39:58 2013 -0500

Fix SQL function execution to be safe with long-lived FmgrInfos.

regards, tom lane