Re: [HACKERS] Restricting maximum keep segments by repslots
Kyotaro HORIGUCHI <horiguchi.kyotaro@lab.ntt.co.jp>
From: Kyotaro HORIGUCHI <horiguchi.kyotaro@lab.ntt.co.jp>
To: tgl@sss.pgh.pa.us
Cc: robertmhaas@gmail.com, sk@zsrv.org, michael.paquier@gmail.com,
andres@anarazel.de, peter.eisentraut@2ndquadrant.com,
pgsql-hackers@postgresql.org
Date: 2018-01-16T09:04:51Z
Lists: pgsql-hackers
I'm digressing...
At Mon, 15 Jan 2018 21:45:34 -0500, Tom Lane <tgl@sss.pgh.pa.us> wrote in <26718.1516070734@sss.pgh.pa.us>
> Robert Haas <robertmhaas@gmail.com> writes:
> > Since the "Stripping trailing CRs from patch" message is totally
> > harmless, I'm not sure why you should need to devote any effort to
> > avoiding it. Anyone who gets it should just ignore it.
I know that and totally agree to Robert but still I wonder why
(and am annoyed by) I sometimes receive such complain or even an
accusation that I sent an out-of-the-convention patch and I was
afraid that it is not actually common.
For thie reason I roughly counted up CT/CTE's that people here is
using for patches in my mail box this time and got the following
numbers. (Counted on attachments with a name "*.patch/diff".)
Rank : Freq : CT/CTE
1: 3308: application/octet-stream:base64
2: 1642: text/x-patch;charset=us-ascii:base64
3: 1286: text/x-diff;charset=us-ascii:7bit
* 4: 997: text/x-patch;charset=us-ascii:7bit
5: 497: text/x-diff;charset=us-ascii:base64
6: 406: text/x-diff:quoted-printable
7: 403: text/plain;charset=us-ascii:7bit
8: 389: text/x-diff:base64
9: 321: application/x-gzip:base64
10: 281: text/plain;charset=us-ascii:base64
<snip>
Total: attachments=11461 / mails=158121
The most common setting is application/octet-stream:base64 but
text/x-patch;charset=us-ascii:7bit is also one of ... the majority?
I'm convinced that my original setting is not so problematic so I
reverted it.
> Not sure, but that might be another situation in which "patch"
> works and "git apply" doesn't. (Feeling too lazy to test it...)
I was also afraid of that as I wrote upthread but it seems also a
needless fear.
regards,
--
Kyotaro Horiguchi
NTT Open Source Software Center
Commits
-
Save slot's restart_lsn when invalidated due to size
- 12e52ba5a76e 13.0 landed
- 0188bb82531f 14.0 landed
-
Fix checkpoint signalling
- 1816a1c6ffe4 13.0 landed
-
Check slot->restart_lsn validity in a few more places
- d0abe78d8427 13.0 landed
-
Allow users to limit storage reserved by replication slots
- c6550776394e 13.0 landed
-
Remove header noise from test_decoding test
- 69360b34589b 13.0 landed
-
Rework WAL-reading supporting structs
- 709d003fbd98 13.0 cited
-
Flip argument order in XLogSegNoOffsetToRecPtr
- a22445ff0be2 12.0 cited