Horton

Thread

Commits

  1. Fix pg_replication_slot example output

  1. Documentaion fix.

    Kyotaro HORIGUCHI <horiguchi.kyotaro@lab.ntt.co.jp> — 2018-07-31T10:09:09Z

    Hello.

I found that an example output in the following page is not
correct for the version.

https://www.postgresql.org/docs/10/static/warm-standby.html

postgres=# SELECT * FROM pg_replication_slots;
>   slot_name  | slot_type | datoid | database | active | xmin | restart_lsn | confirmed_flush_lsn
> -------------+-----------+--------+----------+--------+------+-------------+---------------------
>  node_a_slot | physical  |        |          | f      |      |             |

The correct one is

>   slot_name  | plugin | slot_type | datoid | database | temporary | active | active_pid | xmin | catalog_xmin | restart_lsn | confirmed_flush_lsn 
> -------------+--------+-----------+--------+----------+-----------+--------+------------+------+--------------+-------------+---------------------
>  node_a_slot |        | physical  |        |          | f         | f      |            |      |              |             | 

From 9.4, 9.5, 9.6 and 10 and later have an example output wrong
in individual way of the version. I'm not sure how the
documentation was updated but each of the attached patches fixes
the version designated in the file name.

But, just fixing it makes the line seemingly a bit too long..

regards.

-- 
Kyotaro Horiguchi
NTT Open Source Software Center

  2. Re: Documentaion fix.

    Alvaro Herrera <alvherre@2ndquadrant.com> — 2018-07-31T14:59:14Z

    On 2018-Jul-31, Kyotaro HORIGUCHI wrote:

> But, just fixing it makes the line seemingly a bit too long..

How about pasting it like this?

alvherre=# select * from pg_replication_slots \gx
─[ RECORD 1 ]───────┬────────────
slot_name           │ node_a_slot
plugin              │ 
slot_type           │ physical
datoid              │ 
database            │ 
temporary           │ f
active              │ f
active_pid          │ 
xmin                │ 
catalog_xmin        │ 
restart_lsn         │ 
confirmed_flush_lsn │ 

-- 
Álvaro Herrera                https://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

  3. Re: Documentaion fix.

    Michael Paquier <michael@paquier.xyz> — 2018-07-31T17:47:32Z

    On Tue, Jul 31, 2018 at 10:59:14AM -0400, Alvaro Herrera wrote:
> How about pasting it like this?
> 
> alvherre=# select * from pg_replication_slots \gx
> ─[ RECORD 1 ]───────┬────────────
> slot_name           │ node_a_slot
> plugin              │ 
> slot_type           │ physical
> datoid              │ 
> database            │ 
> temporary           │ f
> active              │ f
> active_pid          │ 
> xmin                │ 
> catalog_xmin        │ 
> restart_lsn         │ 
> confirmed_flush_lsn │ 

Each time this catalog is changed, this would become incorrect.  My
suggestion would be to change the query to that and call it a day:
SELECT slot_name, slot_type, active FROM pg_replication_slots;
--
Michael

  4. Re: Documentaion fix.

    Kyotaro HORIGUCHI <horiguchi.kyotaro@lab.ntt.co.jp> — 2018-08-01T04:04:37Z

    At Wed, 1 Aug 2018 02:47:32 +0900, Michael Paquier <michael@paquier.xyz> wrote in <20180731174732.GD2878@paquier.xyz>
> On Tue, Jul 31, 2018 at 10:59:14AM -0400, Alvaro Herrera wrote:
> > How about pasting it like this?
> > 
> > alvherre=# select * from pg_replication_slots \gx
> > ─[ RECORD 1 ]───────┬────────────
> > slot_name           │ node_a_slot
> > plugin              │ 
> > slot_type           │ physical
> > datoid              │ 
> > database            │ 
> > temporary           │ f
> > active              │ f
> > active_pid          │ 
> > xmin                │ 
> > catalog_xmin        │ 
> > restart_lsn         │ 
> > confirmed_flush_lsn │ 
> 
> Each time this catalog is changed, this would become incorrect.  My
> suggestion would be to change the query to that and call it a day:
> SELECT slot_name, slot_type, active FROM pg_replication_slots;

Yeah, I'm also concerned about the unstability. I didn't came up
with a list of columns that makes sense at that time but I
rethought on that.

> slot_name           │ required
> plugin              │ <not requried for physical slots>
> slot_type           │ required
> datoid              │ <not requried>
> database            │ <not requried>
> temporary           │ <not requried>
> active              │ required?
> active_pid          │ <not requried>
> xmin                │ <not requried>
> catalog_xmin        │ <not requried>
> restart_lsn         │ better to be shown?
> confirmed_flush_lsn │ <not requried for physical slots>

The query and the result with four columns fit the current width.

regards.

-- 
Kyotaro Horiguchi
NTT Open Source Software Center

  5. Re: Documentaion fix.

    Michael Paquier <michael@paquier.xyz> — 2018-08-02T19:13:56Z

    On Wed, Aug 01, 2018 at 01:04:37PM +0900, Kyotaro HORIGUCHI wrote:
> The query and the result with four columns fit the current width.

Just wondering, what is your reason behind the addition of restart_lsn?
This part of the documentation focuses on slot creation, so slot_name,
slot_type and active would be representative enough, no?
--
Michael

  6. Re: Documentaion fix.

    Kyotaro HORIGUCHI <horiguchi.kyotaro@lab.ntt.co.jp> — 2018-08-03T07:23:13Z

    At Fri, 3 Aug 2018 04:13:56 +0900, Michael Paquier <michael@paquier.xyz> wrote in <20180802191356.GB2247@paquier.xyz>
> On Wed, Aug 01, 2018 at 01:04:37PM +0900, Kyotaro HORIGUCHI wrote:
> > The query and the result with four columns fit the current width.
> 
> Just wondering, what is your reason behind the addition of restart_lsn?
> This part of the documentation focuses on slot creation, so slot_name,
> slot_type and active would be representative enough, no?

The first reason was the example looks having a bit too many
space around only with three other columns.

A more serious reason is that I wanted to show a slot with what
properties is created in the example and I thought that
restart_lsn and temporary are significant. Howerver restart_lsn
is always a part of the pg_replication_slots, we don't have
"temprary" before 10. Addition to that, adding it makes the
SELECT line stick out of the width.

That said, I don't object to reduce the columns. Please find the
attached.

regards.

-- 
Kyotaro Horiguchi
NTT Open Source Software Center

  7. Re: Documentaion fix.

    Alvaro Herrera <alvherre@2ndquadrant.com> — 2018-08-03T20:37:05Z

    On 2018-Aug-03, Kyotaro HORIGUCHI wrote:

> That said, I don't object to reduce the columns. Please find the
> attached.

Thanks, pushed.

-- 
Álvaro Herrera                https://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

  8. Re: Documentaion fix.

    Michael Paquier <michael@paquier.xyz> — 2018-08-03T20:58:52Z

    On Fri, Aug 03, 2018 at 04:37:05PM -0400, Alvaro Herrera wrote:
> On 2018-Aug-03, Kyotaro HORIGUCHI wrote: 
>> That said, I don't object to reduce the columns. Please find the
>> attached.
> 
> Thanks, pushed.

Thanks Alvaro for keeping the three-column version, I was going to look
at the proposed patch and push as you did, until I noticed that you
showed up :)
--
Michael

  9. Re: Documentaion fix.

    Kyotaro HORIGUCHI <horiguchi.kyotaro@lab.ntt.co.jp> — 2018-08-09T04:03:02Z

    At Sat, 4 Aug 2018 05:58:52 +0900, Michael Paquier <michael@paquier.xyz> wrote in <20180803205852.GB20967@paquier.xyz>
> On Fri, Aug 03, 2018 at 04:37:05PM -0400, Alvaro Herrera wrote:
> > On 2018-Aug-03, Kyotaro HORIGUCHI wrote: 
> >> That said, I don't object to reduce the columns. Please find the
> >> attached.
> > 
> > Thanks, pushed.
> 
> Thanks Alvaro for keeping the three-column version, I was going to look
> at the proposed patch and push as you did, until I noticed that you
> showed up :)

Thanks.

# I noticed that the subject has typo..

regards.

-- 
Kyotaro Horiguchi
NTT Open Source Software Center

  10. Re: Documentaion fix.

    Alvaro Herrera <alvherre@2ndquadrant.com> — 2018-08-09T19:58:09Z

    On 2018-Aug-09, Kyotaro HORIGUCHI wrote:

> # I noticed that the subject has typo..

Yeah.  I suggest never changing subject lines, because Gmail has the
nasty (mis-)feature of making such a response into a completely new
thread.  I don't know if Google paid mail service behaves in the same
way.

So if you change Subject, please do include a URL to the previous thread
if necessary, for the benefit of people reading on Gmail.  

I wouldn't worry about this for any other individual email provider, but
Gmail is by far the largest fraction of subscribers :-(  I guess this
shows just how much better Google made webmail systems than what existed
at the time.

-- 
Álvaro Herrera                https://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

  11. Re: Documentaion fix.

    Michael Paquier <michael@paquier.xyz> — 2018-08-10T16:51:18Z

    On Thu, Aug 09, 2018 at 03:58:09PM -0400, Alvaro Herrera wrote:
> Yeah.  I suggest never changing subject lines, because Gmail has the
> nasty (mis-)feature of making such a response into a completely new
> thread.  I don't know if Google paid mail service behaves in the same
> way.

If one uses Gmail with another client like mutt, then those don't get
broken.  I don't know about Thunderbird which I believe people use a
lot.

> So if you change Subject, please do include a URL to the previous thread
> if necessary, for the benefit of people reading on Gmail.

+1.

> I wouldn't worry about this for any other individual email provider, but
> Gmail is by far the largest fraction of subscribers :-(  I guess this
> shows just how much better Google made webmail systems than what existed
> at the time.

If something is free, you are the product, still I have to admit that
Gmail is not especially bad.
--
Michael

  12. Re: Documentaion fix.

    Alvaro Herrera <alvherre@2ndquadrant.com> — 2018-08-15T17:35:56Z

    On 2018-Aug-03, Alvaro Herrera wrote:

> On 2018-Aug-03, Kyotaro HORIGUCHI wrote:
> 
> > That said, I don't object to reduce the columns. Please find the
> > attached.
> 
> Thanks, pushed.

I had failed to push in the 9.4 branch.  Done now.

-- 
Álvaro Herrera                https://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

  13. Re: Documentaion fix.

    Michael Paquier <michael@paquier.xyz> — 2018-08-16T00:14:24Z

    On Wed, Aug 15, 2018 at 02:35:56PM -0300, Alvaro Herrera wrote:
> I had failed to push in the 9.4 branch.  Done now.

Thanks Alvaro for working on the details.  I would not have bothered
much myself as the set of columns was correct in 9.4, but for
consistency's sake that makes sense.
--
Michael