Thread: pg_controldata output alignment regression
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Do we care that as of 9.5 pg_controldata output is not 100% aligned anymore? The culprit is: Current track_commit_timestamp setting: off Its value is shifted 2 characters to the right with respect to all the others. I think it ought to be fixed but thought I'd get opinions first. Joe - -- Crunchy Data - http://crunchydata.com PostgreSQL Support for Secure Enterprises Consulting, Training, & Open Source Development -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iQIcBAEBAgAGBQJV28z9AAoJEDfy90M199hlFUkP/3prO8QakKsHG4+kDu2td2Oj ITkOTm0fE67BxalHr2UkkH5kMrcbFaXsluzPbuCHW/i3VMemPiRaQmexpgoD7NUG qAmMv5BNSYaU02iRp9Ay32g9Ohoh/OrZfD8MNCWyvTmxVB730I1bhRxl308S+Y3J gqiy+qufVuTa4O65N2+5xGSUXpP352kL+/m6+xprb4LY7gaVpAoxd3wFrSj6A6O5 MJvOTHSoM67A8UXuCs2PVzyhb9U+egJ5IaAI7ItMgx7L+83ZziHEumqe3VYI+AW8 +vL5FtCl09rpE56npgG+2LxGSN/yhdiYOrSN3FqCG/UuuXKwwXnEv70i+71/NpAO Ychb/5c8pmo7dZFR6H6mbtWYDjdaGurtCwe2uEG9C41cXDpztYZHePMgFwCAKwdm syHGeWN9YWfKq8US2NkOiGcU2pTzoc6aQeU1U0lJSjEwCzn2d7aTTUJUxIHkLgcg 54GQ+qVbi4N+mmJ1ME39gK1tJObp4bEOGz1ZEryACi+xnneyfncxdP8lRaYwCkWS YkYLAi+Ojic/20Eha/d4DuWLMjsNUgfBY2InsT8R1bmMDRInfuEaffclrQrk662x GggmRkrJ0AQzLn+T8zo9N8G9veWeLy7He0gz2LtNCQzDKEIJ68FeIC/ZltJ14PF+ 9WivdTJa5W3pkAohatKF =Ax9S -----END PGP SIGNATURE-----
Joe Conway <mail@joeconway.com> writes:
> Do we care that as of 9.5 pg_controldata output is not 100% aligned
> anymore? The culprit is:
> Current track_commit_timestamp setting: off
> Its value is shifted 2 characters to the right with respect to all the
> others. I think it ought to be fixed but thought I'd get opinions first.
Seems to me we could s/Current //g, or s/ setting//g, or both,
and get rid of the problem without adding more whitespace.
regards, tom lane
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 08/24/2015 07:41 PM, Tom Lane wrote: > Joe Conway <mail@joeconway.com> writes: >> Do we care that as of 9.5 pg_controldata output is not 100% >> aligned anymore? The culprit is: Current track_commit_timestamp >> setting: off Its value is shifted 2 characters to the right with >> respect to all the others. I think it ought to be fixed but >> thought I'd get opinions first. > > Seems to me we could s/Current //g, or s/ setting//g, or both, and > get rid of the problem without adding more whitespace. I'd agree, except I think not everyone might be happy with that. The surrounding lines look like: 8<---------------- ... End-of-backup record required: no Current wal_level setting: minimal Current wal_log_hints setting: off Current max_connections setting: 100 Current max_worker_processes setting: 8 Current max_prepared_xacts setting: 0 Current max_locks_per_xact setting: 64 Current track_commit_timestamp setting: off Maximum data alignment: 8 Database block size: 8192 ... 8<---------------- So while changing that line to this would work... 8<---------------- ... Current max_locks_per_xact setting: 64 track_commit_timestamp setting: off Maximum data alignment: 8 ... 8<---------------- ... it does become inconsistent with the ones above. One possible solution is to abbreviate "Current" for all of them as "Cur.": 8<---------------- ... End-of-backup record required: no Cur. wal_level setting: minimal Cur. wal_log_hints setting: off Cur. max_connections setting: 100 Cur. max_worker_processes setting: 8 Cur. max_prepared_xacts setting: 0 Cur. max_locks_per_xact setting: 64 Cur. track_commit_timestamp setting: off Maximum data alignment: 8 Database block size: 8192 ... 8<---------------- Of course that breaks backward compatibility if you believe it is important here. Otherwise maybe: 8<---------------- ... End-of-backup record required: no Current wal_level setting: minimal Current wal_log_hints setting: off Current max_connections setting: 100 Current max_worker_processes setting: 8 Current max_prepared_xacts setting: 0 Current max_locks_per_xact setting: 64 Cur. track_commit_timestamp setting: off Maximum data alignment: 8 Database block size: 8192 ... 8<---------------- Joe - -- Crunchy Data - http://crunchydata.com PostgreSQL Support for Secure Enterprises Consulting, Training, & Open Source Development -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iQIcBAEBAgAGBQJV3KUiAAoJEDfy90M199hlPmAP+wSn1w+l4YhPlkuk0tZVN5Vl LpmXD3uGi0WXrt21jQgCaXdj3QeLPzrK9Pu5QDyHODpGexZ7j1lJiTl0cXxQ8CuK LwyPlNr5nzoRGru+g4aRElzGr1unSPI4K8m7nVH2KTw/mmByR+RCQu6CPGqnOZ1+ 4EtW/9svO4hw+YxhjRRdyQwP7XVhI1Og4jryp6kOdzmYbO0K+uMZo8+xFvRg4Sr5 u7iyJe1xUgrsqQhvbRh+eguV0+d/ykDGgodEEPfEEcmvxxQEDvhQ9STM8eEEoK1v sz1/ObFbJ3GrzVZB5Mse6+uFwQB6JqJBvCrnkuH43d9U2NKikR5vm8VJ48yxvwd7 VZLXodAQmudlt0nJdL7vRGoOBt/gztSkuWvl+4y206GRdWcvkNFKTKyvnpoZdW+7 KIaz0D2mWeC/Hr5j84pTLPcfF3ezz+HdUHDmuSt7HX+fH3CSzhGlcoCMZdgZIIKM 1a2RHN8r3sF0U/hyKFjpFetq28Pgnrhardn7Y4U4qveCfwRopF4grNYYrfqreQ0a xxi0bXb81iWX5HvvnWh82/NmG9qH+YhLaHqovvR/5+iXKpcv1do+oSVz0uKwaSen 4gcE7JiWELrhp6+iftzt2U0X69Xd5KeluScjaxeOaQsAYW53pHvOLk5c56RrHVim WZiPEkdGZffETA0SCaZL =hV8z -----END PGP SIGNATURE-----
Joe Conway <mail@joeconway.com> writes:
> On 08/24/2015 07:41 PM, Tom Lane wrote:
>> Seems to me we could s/Current //g, or s/ setting//g, or both, and
>> get rid of the problem without adding more whitespace.
> I'd agree, except I think not everyone might be happy with that. The
> surrounding lines look like:
I was suggesting getting rid of "Current" in *all* the entries. What
value does it add?
regards, tom lane
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 08/25/2015 10:28 AM, Tom Lane wrote: > Joe Conway <mail@joeconway.com> writes: >> On 08/24/2015 07:41 PM, Tom Lane wrote: >>> Seems to me we could s/Current //g, or s/ setting//g, or both, >>> and get rid of the problem without adding more whitespace. > >> I'd agree, except I think not everyone might be happy with that. >> The surrounding lines look like: > > I was suggesting getting rid of "Current" in *all* the entries. > What value does it add? I agree, it adds no value, and is a simple solution. Does anyone out there object to a non-backward compatible change to pg_controldata output? Joe - -- Crunchy Data - http://crunchydata.com PostgreSQL Support for Secure Enterprises Consulting, Training, & Open Source Development -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iQIcBAEBAgAGBQJV3KaTAAoJEDfy90M199hlv+gP/Rgbhvj6Vg06zPokyUXTLMiw LHmZedhOv2XaPW5e1uj7P/8d4y+NjSt7bWnQ2P6ONqNk9SkgQTGS1QIlvShUQDAj 312Lct83xYnJrukBfqzLoeDavPM7GPUiJal4yEixREDYElNa7bwTO/bIFWuAdx9F xJYAwLsWW9AnbTroRn4pgOTpr9YvP/pk0WS7s1wQCmMKbyBRtTYb2yfn+p2NYJS1 /nFJPzIzuRjjVH4U43PZuWuESoW5RUKQQXYQn6FdrgcBPRMWA02blzRTKvuuX19T XXqb0HS+Ge8QpeqofAW6RuCHsvHClYex99PfCyUCAf6t9HOpY6w/dd2RWqExw8zV TrhSJnB0gVI0dONXrew/AwhTc4hy6oeHkSDZd/h6RldwrUMspXbDrjBdmUIo66Dq SinE9OrBXbS2lbDPMmYIWJLbkHn2bjKi8Bs3yBSxmqCnZclAHQefF5TqcxYRB3gD +U0QGuAcCjmKVGE+q33DnIUdSe64uBKP0zRpEWpHw3ENrtwgqR3dfrsTZwLxtMij R6XCOOJQEIw8Gh3nULxwk4sar7zFG+hQqGcZ5IHlAvj4Cjis67qMLTqXyBItQP7x TrVn+UJv4J0t1lCYAt1Cxv11kVictiqBzS1E9JcOJBhAgQguh88HddlnWmj1kVBi lryNq+HsH/lZbc0HwkB9 =crEM -----END PGP SIGNATURE-----
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 08/25/2015 10:32 AM, Joe Conway wrote: > On 08/25/2015 10:28 AM, Tom Lane wrote: >> I was suggesting getting rid of "Current" in *all* the entries. >> What value does it add? > > I agree, it adds no value, and is a simple solution. > > Does anyone out there object to a non-backward compatible change > to pg_controldata output? ...specifically the attached. Will commit/push to 9.5 and HEAD in a few hours barring any objections. Joe - -- Crunchy Data - http://crunchydata.com PostgreSQL Support for Secure Enterprises Consulting, Training, & Open Source Development -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iQIcBAEBAgAGBQJV3LM6AAoJEDfy90M199hlzwUP/0EeobxsxidorFS/4RQRXeWN Gb879a7brwAIuEZVqP9BdlzhfPWrGx98vyRHvQ4jbcNXXO3fe5xTqklXdSMAJD5L 0hF1+DIVHg+SuZ7hJiW0wl1y0b8OIs2w7WOHwi39ZFV1//dbJkV8DkWG0Ty2Roxf JXqBrFOLP0nu6sS3jx2tCkGtkAL5b0FvZw6aFiuxvVUYFW8U36VjCVgZ6aEN+7Jn zvMrMsBtH/AxfhPWd8BblsBhC3+ShPPdG8rE9RHSBwX6qBWlJnf3WAiEjuj6p7Wk kQluJwxWU13s/IKjqmES+H04fEUeqTNouRDlCEKim7o5d7E1FNDS0gCcQ0oIftco dtTf192K91+xtnsnQrgODkrk/tZpnCr7ay0LHI+ydIOtmqgX1g3RchoTL37zMohK sDLEo3aTM4f6mLV2Qbh9ETizcssJuZJoSKKo51icLxbXXUrv8CuU5yniXAm8NM0a MwyVfJL3gjQhEcP3aRIbvCRVqtQJK2Y8Qiff5uDQ+9Nl3ApdIVuyEp+w9pvK/55Z w3MdZt5cjphIANjayqfA2B4nSvLE3RC7caJr0HS10yvFAzP2Go4HQUA1t7RFCYI0 zww+ZQ2hrIdiSZu61QnO1DR49WZrQPd1Z/W9gzHHqTFO1IYf+XxBliQk0mTbZUiN v2DJhvBV2zMhS0jjrVvV =6223 -----END PGP SIGNATURE-----
Attachment
Joe Conway wrote: > Does anyone out there object to a non-backward compatible change to > pg_controldata output? I don't (and thanks for taking care of it), but as I recall, pg_upgrade reads and interprets pg_controldata output so it may need adjustment too. -- Álvaro Herrera http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 08/25/2015 11:28 AM, Alvaro Herrera wrote: > Joe Conway wrote: > >> Does anyone out there object to a non-backward compatible change >> to pg_controldata output? > > I don't (and thanks for taking care of it), but as I recall, > pg_upgrade reads and interprets pg_controldata output so it may > need adjustment too. Thanks for the heads up. There are lots of controldata items pg_upgrade is interested in, but AFAICS none of these are included. Now maybe they should be, but they are not currently referenced. (Bruce added to the thread:we're talking about: "Current wal_level setting" "Current wal_log_hints setting" "Current max_connectionssetting" "Current max_worker_processes setting" "Current max_prepared_xacts setting" "Current max_locks_per_xactsetting" "Current track_commit_timestamp setting" ) Joe - -- Crunchy Data - http://crunchydata.com PostgreSQL Support for Secure Enterprises Consulting, Training, & Open Source Development -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iQIcBAEBAgAGBQJV3MCnAAoJEDfy90M199hli+4P/1fTAXs1yiPga/5MPDoU8yuZ 8mHEvc+6fDXfkb8wk3GEiRjbhenhqkwFhLOBRDCWqKgzLT0rENp8fgm44gnNkim2 cGyz2ZOl5cqVqgZMziiLEhxlojbCLGKB8UOYM2176tBvkxx6NbhY8kjdaOoc6lXX 88n+PWaVdEwaIvYYMGfQjaxgVJxBJBBoRMNjYXhmgqBo3RNE0gwJfjEUNk7VzSnp w+tWrhgBIsHDyg12PnB/X3Wo5220N8rmN11ShDIUxhG5TJj3+u9W3iLB94lP8U2l hmdqsLkbYp5sptkYcFW1d3twOvJwqM0TIezLqTsHRWDtL2u0qOF6IGg9KsFBwbLg g6YcDUUw8UmrX3QmeytKzecbbvi2j1hg8h7kleWG86MwipbX2V1GHohBT3Ih2Srf Aw4poaYC94VKY+kKpMM+0901JOC064PguT/6Cud6QcujxGWrzzZJWmbbfXSlS+DZ 5xVco7e9XeYGQoA2CfhPiBZc1Mb7ZZYv1ptvK5NW64NQBlgrwQEwSa1YUkLvA+/Y mlCXgC8/w6A1QE4sRdQKzKqN1MRxcvnZKIVM/F0KepagIxU9IWUBh+qE98LjZWsM /02fyZPLt1COZnqDQSfGXdA7QgMLOm6Tfl0v3A7iv6qUT+hxiP5TonhPcJk2u0IM E81K2fX6gOcsdQGtqKql =nbOs -----END PGP SIGNATURE-----
Joe Conway wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 I should have gotten my key signed when I had the chance :-( > On 08/25/2015 11:28 AM, Alvaro Herrera wrote: > > Joe Conway wrote: > > > >> Does anyone out there object to a non-backward compatible change > >> to pg_controldata output? > > > > I don't (and thanks for taking care of it), but as I recall, > > pg_upgrade reads and interprets pg_controldata output so it may > > need adjustment too. > > Thanks for the heads up. There are lots of controldata items > pg_upgrade is interested in, but AFAICS none of these are included. > Now maybe they should be, but they are not currently referenced. Well, if there's no compatibility hit then I don't think it's worth worrying about. -- Álvaro Herrera http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 08/25/2015 12:41 PM, Alvaro Herrera wrote: > Joe Conway wrote: >> On 08/25/2015 11:28 AM, Alvaro Herrera wrote: >>> Joe Conway wrote: >>> >>>> Does anyone out there object to a non-backward compatible >>>> change to pg_controldata output? >>> >>> I don't (and thanks for taking care of it), but as I recall, >>> pg_upgrade reads and interprets pg_controldata output so it >>> may need adjustment too. >> >> Thanks for the heads up. There are lots of controldata items >> pg_upgrade is interested in, but AFAICS none of these are >> included. Now maybe they should be, but they are not currently >> referenced. > > Well, if there's no compatibility hit then I don't think it's > worth worrying about. Committed and pushed to HEAD and 9.5 Joe - -- Crunchy Data - http://crunchydata.com PostgreSQL Support for Secure Enterprises Consulting, Training, & Open Source Development -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iQIcBAEBAgAGBQJV3RrPAAoJEDfy90M199hlL+AQAJIChfxiDf08OqclgAHAcVr4 j5RKou1aeDJSHfDOoH4+f9wd8jaQawVzk/7pEy8aiumF4nioGcNcgVnG7w4qgHvf vt7w41YZStd08fvwuXr37lr1sMnPQLWGwWFx5VecTgXPveLSdh8sWZyxrXBoL7Z3 2lJx8RByjyDYB/wj2Ci0MRtk2s8vapFkHDwHPKvmx/i0neMgbqaXu0WKTLaNfOUy IIK1G5o0VHK4Qes3omtzfyTGLC299o1zfhW1Klk3uPukWliYiAjJfw1L8vAwLl0F MFJZb+EaLKl5EbQMRPSPCyHN/XxbEgmuTNFvAqhbUDYmOOPOgBLbIg8ke/w0s0g2 fEpzDFGKmsiSdYj17BZ6jp+xafIGaN8+seWcTyNaMDrqG9WEGx3AkcBUxgXfForY LyCOuZn1aS6hgQvVH5uiGg0QIHN0ZmzFBOTYUE+tUPetnQskC94IUT1rFRm1XH9I T/+JD/EYEoRiosZyeFfx+Zf+caL9KmtrUutGP7OXuNBBNyiTq26QifDZjfG5Fd8b IIxgeZQ3u0vWeTDuP148QrtioSj/IToUKhmn/kZvMwq6XxHhErA8Sc5zgzTE0dIi X4cYRcFESmCzEoDtAASaulpDIxSMVMp5GPWumCyK8CPHIqq7c8lNNqfM2ljdrGjR 1tfHRhq8/BFPrjT1fcrR =WaIR -----END PGP SIGNATURE-----