Re: sloppy back-patching of column-privilege leak - Mailing list pgsql-hackers

Stephen Frost <sfrost@snowman.net> writes:
> * Alvaro Herrera (alvherre@2ndquadrant.com) wrote:
>> FWIW using different commit messages for different branches is a
>> mistake.  The implicit policy we have is that there is one message,
>> identical for all branches, that describe how the patch differs in each
>> branch whenever necessary.  Note that the git_changelog output that
>> Robert pasted is not verbatim from the tool; what it actually prints is
>> three separate entries, one for each different message you used, which
>> is not what is supposed to occur.

> Ok, thanks.  That's certainly easy enough to do and I'll do so in the
> future.  I could have sworn I'd seen cases where further clarification
> was done for branch-specific commits but perhaps something else was
> different there.

Some people do it differently when the per-branch commits are very much
different, but what Alvaro suggests is certainly handy when it comes time
to make release notes ;-).

>> I say this policy is implicit because I don't recall it being spelled
>> out anywhere, but since it's embodied in git_changelog's working
>> principle it's important we stick to it.

> I have to admit that I've never really used git_changelog.

It's pretty handy.  The output for a couple of recent commits looks like

Author: Noah Misch <noah@leadboat.com>
Branch: master [a7a4adcf8] 2015-02-06 23:14:27 -0500
   Assert(PqCommReadingMsg) in pq_peekbyte().      Interrupting pq_recvbuf() can break protocol sync, so its callers
all  deserve this assertion.  The one pq_peekbyte() caller suffices already.
 

Author: Heikki Linnakangas <heikki.linnakangas@iki.fi>
Branch: master [ff16b40f8] 2015-02-06 11:26:50 +0200
Branch: REL9_4_STABLE [3bc4c6942] 2015-02-06 11:27:12 +0200
Branch: REL9_3_STABLE [5f0ba4abb] 2015-02-06 11:32:16 +0200
Branch: REL9_2_STABLE [2af568c6b] 2015-02-06 11:32:37 +0200
Branch: REL9_1_STABLE [0d36d9f2b] 2015-02-06 11:32:42 +0200
   Report WAL flush, not insert, position in replication IDENTIFY_SYSTEM      When beginning streaming replication, the
clientusually issues the   IDENTIFY_SYSTEM command, which used to return the current WAL insert   position. That's not
suitablefor the intended purpose of that field,   however. pg_receivexlog uses it to start replication from the
reported  point, but if it hasn't been flushed to disk yet, it will fail. Change   IDENTIFY_SYSTEM to report the flush
positioninstead.      Backpatch to 9.1 and above. 9.0 doesn't report any WAL position.
 

Heikki's five commits got merged into one entry because they had identical
log-message texts and were committed on the same day.  Further back in the
output you find things like

Author: Peter Eisentraut <peter_e@gmx.net>
Branch: master [1332bbb30] 2015-02-01 22:36:44 -0500
Branch: REL9_4_STABLE Release: REL9_4_1 [0ca8cc581] 2015-02-01 22:40:13 -0500
Branch: REL9_3_STABLE Release: REL9_3_6 [6b9b705c9] 2015-02-01 22:40:25 -0500
Branch: REL9_2_STABLE Release: REL9_2_10 [040f5ef50] 2015-02-01 22:40:36 -0500
Branch: REL9_1_STABLE Release: REL9_1_15 [2b0d33599] 2015-02-01 22:40:45 -0500
Branch: REL9_0_STABLE Release: REL9_0_19 [b09ca8834] 2015-02-01 22:40:53 -0500
   doc: Improve claim about location of pg_service.conf      The previous wording claimed that the file was always in
/etc,but of   course this varies with the installation layout.  Write instead that it   can be found via `pg_config
--sysconfdir`. Even though this is still   somewhat incorrect because it doesn't account of moved installations, it
atleast conveys that the location depends on the installation.
 

which show the first actual release incorporating each patch.  So even
if you're not writing release notes, it's mighty handy for identifying
when/whether a given patch has shipped.  I tend to run this once a week
or so and keep the output around in a text file for quick searching.
        regards, tom lane