Re: sloppy back-patching of column-privilege leak

Stephen Frost <sfrost(at)snowman(dot)net> writes:
> * Alvaro Herrera (alvherre(at)2ndquadrant(dot)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(at)leadboat(dot)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(dot)linnakangas(at)iki(dot)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 client usually issues the
IDENTIFY_SYSTEM command, which used to return the current WAL insert
position. That's not suitable for 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 position instead.

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(at)gmx(dot)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
at least 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