git.postgresql.org not finding a commit - Mailing list pgsql-www

From Jim Nasby
Subject git.postgresql.org not finding a commit
Date
Msg-id 54628102.2010804@BlueTreble.com
Whole thread Raw
Responses Re: git.postgresql.org not finding a commit  (Alvaro Herrera <alvherre@2ndquadrant.com>)
List pgsql-www
Details below, but
http://git.postgresql.org/gitweb/?p=postgresql.git&a=search&h=HEAD&st=commit&s=0ac5ad5134f2769ccbaefec73844f8504c4d6182
showsnothing, but that commit does exist:
 

decibel@decina:[15:12]~/pgsql/HEAD/src/backend (master=)$git log 0ac5ad5134f2769ccbaefec73844f8504c4d6182|head -n1
commit 0ac5ad5134f2769ccbaefec73844f8504c4d6182

Our github mirror doesn't show that commit in it's search either :(

-------- Original Message --------
Subject: Re: [HACKERS] tracking commit timestamps
Date: Tue, 11 Nov 2014 15:18:17 -0600
From: Jim Nasby <Jim.Nasby@BlueTreble.com>
To: Alvaro Herrera <alvherre@2ndquadrant.com>
CC: Robert Haas <robertmhaas@gmail.com>, Petr Jelinek <petr@2ndquadrant.com>, Steve Singer <steve@ssinger.info>, Andres
Freund<andres@2ndquadrant.com>, Michael Paquier <michael.paquier@gmail.com>, Anssi Kääriäinen
<anssi.kaariainen@thl.fi>,Simon Riggs <simon@2ndquadrant.com>, Heikki Linnakangas <hlinnakangas@vmware.com>, "Pg
Hackers"<pgsql-hackers@postgresql.org>, Jaime Casanova <jaime@2ndquadrant.com>
 

On 11/11/14, 2:03 PM, Alvaro Herrera wrote:
> Jim Nasby wrote:
>> On 11/10/14, 7:40 AM, Alvaro Herrera wrote:
>
>>> Ah, right.  So AFAIK we don't need to keep anything older than
>>> RecentXmin or something like that -- which is not too old.  If I recall
>>> correctly Josh Berkus was saying in a thread about pg_multixact that it
>>> used about 128kB or so in <= 9.2 for his customers; that one was also
>>> limited to RecentXmin AFAIR.  I think a similar volume of commit_ts data
>>> would be pretty acceptable.  Moreso considering that it's turned off by
>>> default.
>>
>> FWIW, AFAICS MultiXacts are only truncated after a (auto)vacuum process is able to advance datminmxid, which will
(now)only happen when an entire relation has been scanned (which should be infrequent).
 
>>
>> I believe the low normal space usage is just an indication that most databases don't use many MultiXacts.
>
> That's in 9.3.  Prior to that, they were truncated much more often.

Well, we're talking about a new feature, so I wasn't looking in back branches. ;P

> Maybe you've not heard enough about this commit:
>
> commit 0ac5ad5134f2769ccbaefec73844f8504c4d6182

Interestingly, git.postgresql.org hasn't either:
http://git.postgresql.org/gitweb/?p=postgresql.git&a=search&h=HEAD&st=commit&s=0ac5ad5134f2769ccbaefec73844f8504c4d6182

The commit is certainly there though...
decibel@decina:[15:12]~/pgsql/HEAD/src/backend (master=)$git log 0ac5ad5134f2769ccbaefec73844f8504c4d6182|head -n1
commit 0ac5ad5134f2769ccbaefec73844f8504c4d6182
-- 
Jim Nasby, Data Architect, Blue Treble Consulting
Data in Trouble? Get it in Treble! http://BlueTreble.com


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





pgsql-www by date:

Previous
From: Robins Tharakan
Date:
Subject: Reattempt download when fetch gets a 301 - during Registration
Next
From: Alvaro Herrera
Date:
Subject: Re: git.postgresql.org not finding a commit