From: Tom Lane <tgl@sss.pgh.pa.us>
To: Alvaro Herrera <alvherre@2ndquadrant.com>
cc: Andres Freund <andres@2ndquadrant.com>,
	Magnus Hagander <magnus@hagander.net>,
	Kevin Grittner <kgrittn@mail.com>, Peter Eisentraut <peter_e@gmx.net>,
	PostgreSQL WWW <pgsql-www@postgresql.org>,
	Stephen Frost <sfrost@snowman.net>
Subject: Re: gitweb is no longer a real-time view
In-reply-to: <20130304143349.GX9507@alvh.no-ip.org>
References: <19759.1362357835@sss.pgh.pa.us>
	<20130304020324.GE16142@tamriel.snowman.net>
	<2480.1362363162@sss.pgh.pa.us>
	<20130304023335.GH16142@tamriel.snowman.net>
	<CABUevEwfw24iF9-czueLSmdFQwck012qfVmLXcoKbG37xG56jQ@mail.gmail.com>
	<CABUevEzM2F8qAxVds9Me-41L5BqeEGO4DuosCQhC0C6v05HPUw@mail.gmail.com>
	<20130304125013.GB3943@awork2.anarazel.de>
	<20130304143349.GX9507@alvh.no-ip.org>
Comments: In-reply-to Alvaro Herrera <alvherre@2ndquadrant.com>
	message dated "Mon, 04 Mar 2013 11:33:49 -0300"
Date: Mon, 04 Mar 2013 09:40:38 -0500
Message-ID: <4725.1362408038@sss.pgh.pa.us>
Precedence: bulk
Sender: pgsql-www-owner@postgresql.org

Alvaro Herrera <alvherre@2ndquadrant.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@postgresql.org>
Date:   Sun Mar 3 18:38:44 2013 -0600

    Remove accidentally-committed .orig file.

commit 3bf3ab8c563699138be02f9dc305b7b77a724307
Author: Kevin Grittner <kgrittn@postgresql.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@sss.pgh.pa.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@sss.pgh.pa.us>
Date:   Sun Mar 3 17:39:58 2013 -0500

    Fix SQL function execution to be safe with long-lived FmgrInfos.
    
			regards, tom lane


-- 
Sent via pgsql-www mailing list (pgsql-www@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-www