Обсуждение: slotname vs slot_name
Hi, Due to the opened window of the pg_control/catalog version bump a chance has opened to fix a inconsistency I've recently been pointed towards: Namely that replication slots are named 'slot_name' in one half of the cases and 'slotname' in the other. That's in views, SRF columns, function parameters and the primary_slotname recovery.conf parameter. My personal tendency would be to make it slot_name everywhere except the primary_slotname recovery.conf parameter. There we already have precedent for shortening names. Other opinions? Greetings, Andres Freund -- Andres Freund http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training & Services
On Thu, Jun 5, 2014 at 8:24 AM, Andres Freund <andres@2ndquadrant.com> wrote: > Hi, > > Due to the opened window of the pg_control/catalog version bump a chance > has opened to fix a inconsistency I've recently been pointed > towards: > Namely that replication slots are named 'slot_name' in one half of the > cases and 'slotname' in the other. That's in views, SRF columns, > function parameters and the primary_slotname recovery.conf parameter. > > My personal tendency would be to make it slot_name everywhere except the > primary_slotname recovery.conf parameter. There we already have > precedent for shortening names. > > Other opinions? I like using "slot_name" everywhere, i.e, even in recovery.conf. primary_slot_name seems not so long name. BTW, what about also renaming pg_llog directory? I'm afraid that a user can confuse pg_log with pg_llog. Regards, -- Fujii Masao
Hi, On Thu, Jun 5, 2014 at 10:57 AM, Fujii Masao <masao.fujii@gmail.com> wrote: > I like using "slot_name" everywhere, i.e, even in recovery.conf. > primary_slot_name seems not so long name. > > BTW, what about also renaming pg_llog directory? I'm afraid that > a user can confuse pg_log with pg_llog. > Recently I came across this while tab-completing pg_log ;-) I remember asking to document pg_llog elsewhere. -- Amit
On 06/05/2014 05:09 AM, Amit Langote wrote: > Hi, > > On Thu, Jun 5, 2014 at 10:57 AM, Fujii Masao <masao.fujii@gmail.com> wrote: >> I like using "slot_name" everywhere, i.e, even in recovery.conf. >> primary_slot_name seems not so long name. >> >> BTW, what about also renaming pg_llog directory? I'm afraid that >> a user can confuse pg_log with pg_llog. >> > > Recently I came across this while tab-completing pg_log ;-) > I remember asking to document pg_llog elsewhere. +1 for renaming pg_llog. We have all heard the stories of people deleting pg_clog because "it's just logs". I feel that pg_llog might be an even greater risk at that (although the consequences are not as serious as deleting pg_clog. pg_ldecoding ? - Heikki
On 05/06/14 10:11, Heikki Linnakangas wrote: > On 06/05/2014 05:09 AM, Amit Langote wrote: >> Hi, >> >> On Thu, Jun 5, 2014 at 10:57 AM, Fujii Masao <masao.fujii@gmail.com> >> wrote: >>> I like using "slot_name" everywhere, i.e, even in recovery.conf. >>> primary_slot_name seems not so long name. >>> +1 >>> BTW, what about also renaming pg_llog directory? I'm afraid that >>> a user can confuse pg_log with pg_llog. >>> >> >> Recently I came across this while tab-completing pg_log ;-) >> I remember asking to document pg_llog elsewhere. > > +1 for renaming pg_llog. We have all heard the stories of people > deleting pg_clog because "it's just logs". I feel that pg_llog might be > an even greater risk at that (although the consequences are not as > serious as deleting pg_clog. > > pg_ldecoding ? > pg_lcse or pg_lcset ? -- Petr Jelinek http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services
Hi, On Thu, 2014-06-05 at 10:57 +0900, Fujii Masao wrote: > BTW, what about also renaming pg_llog directory? I'm afraid that > a user can confuse pg_log with pg_llog. +1. I hit this while testing 9.4 this week. Should be confusing for many end-users. Regards, -- Devrim GÜNDÜZ Principal Systems Engineer @ EnterpriseDB: http://www.enterprisedb.com PostgreSQL Danışmanı/Consultant, Red Hat Certified Engineer Twitter: @DevrimGunduz , @DevrimGunduzTR
<p dir="ltr"><br /> On Jun 5, 2014 10:22 AM, "Devrim Gündüz" <<a href="mailto:devrim@gunduz.org">devrim@gunduz.org</a>>wrote:<br /> ><br /> ><br /> > Hi,<br /> ><br /> >On Thu, 2014-06-05 at 10:57 +0900, Fujii Masao wrote:<br /> > > BTW, what about also renaming pg_llog directory?I'm afraid that<br /> > > a user can confuse pg_log with pg_llog.<br /> ><br /> > +1. I hit this whiletesting 9.4 this week. Should be confusing for many<br /> > end-users.<br /> ><p dir="ltr">+500. We already havetwo directories that users remove to get free space thinking it's safe because it's just log files. We don't need onemore :-) <p dir="ltr">/Magnus
On Thu, Jun 5, 2014 at 5:27 PM, Magnus Hagander <magnus@hagander.net> wrote: > > On Jun 5, 2014 10:22 AM, "Devrim Gündüz" <devrim@gunduz.org> wrote: >> >> >> Hi, >> >> On Thu, 2014-06-05 at 10:57 +0900, Fujii Masao wrote: >> > BTW, what about also renaming pg_llog directory? I'm afraid that >> > a user can confuse pg_log with pg_llog. >> >> +1. I hit this while testing 9.4 this week. Should be confusing for many >> end-users. >> > > +500. We already have two directories that users remove to get free space > thinking it's safe because it's just log files. We don't need one more :-) Adding a +1 on top of this already-huge stack. -- Michael
On 2014-06-05 10:57:58 +0900, Fujii Masao wrote: > On Thu, Jun 5, 2014 at 8:24 AM, Andres Freund <andres@2ndquadrant.com> wrote: > > Hi, > > > > Due to the opened window of the pg_control/catalog version bump a chance > > has opened to fix a inconsistency I've recently been pointed > > towards: > > Namely that replication slots are named 'slot_name' in one half of the > > cases and 'slotname' in the other. That's in views, SRF columns, > > function parameters and the primary_slotname recovery.conf parameter. > > > > My personal tendency would be to make it slot_name everywhere except the > > primary_slotname recovery.conf parameter. There we already have > > precedent for shortening names. > > > > Other opinions? > > I like using "slot_name" everywhere, i.e, even in recovery.conf. > primary_slot_name seems not so long name. It also has the advantage that we can add a couple more slot_* options later. Will do that. > BTW, what about also renaming pg_llog directory? I'm afraid that > a user can confuse pg_log with pg_llog. We have: * pg_ldecoding (Heikki) * pg_lcse or pg_lcset (Petr) * pg_logical (Andres) I like, what a surprise, my own suggestion best. The name seems more versatile because it's not restricted to decoding. Greetings, Andres Freund -- Andres Freund http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training & Services
On Thu, Jun 5, 2014 at 7:57 PM, Andres Freund <andres@2ndquadrant.com> wrote: > We have: > * pg_ldecoding (Heikki) > * pg_lcse or pg_lcset (Petr) > * pg_logical (Andres) pg_decoding, simply? -- Michael
On 2014-06-05 20:02:38 +0900, Michael Paquier wrote: > On Thu, Jun 5, 2014 at 7:57 PM, Andres Freund <andres@2ndquadrant.com> wrote: > > We have: > > * pg_ldecoding (Heikki) > > * pg_lcse or pg_lcset (Petr) > > * pg_logical (Andres) > pg_decoding, simply? I don't like it much, because it's pretty much restricted for data used during decoding. So we'll potentially need a different directory for related features (replication identifiers, apply, ...). Greetings, Andres Freund -- Andres Freund http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training & Services
On Thu, Jun 5, 2014 at 12:57 PM, Andres Freund <andres@2ndquadrant.com> wrote:
On 2014-06-05 10:57:58 +0900, Fujii Masao wrote:It also has the advantage that we can add a couple more slot_* options
> On Thu, Jun 5, 2014 at 8:24 AM, Andres Freund <andres@2ndquadrant.com> wrote:
> > Hi,
> >
> > Due to the opened window of the pg_control/catalog version bump a chance
> > has opened to fix a inconsistency I've recently been pointed
> > towards:
> > Namely that replication slots are named 'slot_name' in one half of the
> > cases and 'slotname' in the other. That's in views, SRF columns,
> > function parameters and the primary_slotname recovery.conf parameter.
> >
> > My personal tendency would be to make it slot_name everywhere except the
> > primary_slotname recovery.conf parameter. There we already have
> > precedent for shortening names.
> >
> > Other opinions?
>
> I like using "slot_name" everywhere, i.e, even in recovery.conf.
> primary_slot_name seems not so long name.
later. Will do that.We have:
> BTW, what about also renaming pg_llog directory? I'm afraid that
> a user can confuse pg_log with pg_llog.
* pg_ldecoding (Heikki)
* pg_lcse or pg_lcset (Petr)
* pg_logical (Andres)
I like, what a surprise, my own suggestion best. The name seems more
versatile because it's not restricted to decoding.
I don't care too much really, either one is find - but if I should vote, I'll split my vote between pg_locical and pg_ldecoding, I don't like lcse and lcset very much.
Magnus Hagander
Me: http://www.hagander.net/
Work: http://www.redpill-linpro.com/
On 06/05/2014 01:57 PM, Andres Freund wrote: > On 2014-06-05 10:57:58 +0900, Fujii Masao wrote: >> On Thu, Jun 5, 2014 at 8:24 AM, Andres Freund <andres@2ndquadrant.com> wrote: >>> Hi, >>> >>> Due to the opened window of the pg_control/catalog version bump a chance >>> has opened to fix a inconsistency I've recently been pointed >>> towards: >>> Namely that replication slots are named 'slot_name' in one half of the >>> cases and 'slotname' in the other. That's in views, SRF columns, >>> function parameters and the primary_slotname recovery.conf parameter. >>> >>> My personal tendency would be to make it slot_name everywhere except the >>> primary_slotname recovery.conf parameter. There we already have >>> precedent for shortening names. >>> >>> Other opinions? >> >> I like using "slot_name" everywhere, i.e, even in recovery.conf. >> primary_slot_name seems not so long name. > > It also has the advantage that we can add a couple more slot_* options > later. Will do that. > >> BTW, what about also renaming pg_llog directory? I'm afraid that >> a user can confuse pg_log with pg_llog. > > We have: > * pg_ldecoding (Heikki) > * pg_lcse or pg_lcset (Petr) > * pg_logical (Andres) > > I like, what a surprise, my own suggestion best. The name seems more > versatile because it's not restricted to decoding. The problem with pg_logical is that it's not restricted to much at all ;-), "logical" is an awfully generic name. BTW, the stuff that we have in pg_llog are not really logs at all, so pg_llog was always a misnomer. - Heikki
On 06/05/2014 02:10 PM, Magnus Hagander wrote: > On Thu, Jun 5, 2014 at 12:57 PM, Andres Freund <andres@2ndquadrant.com> > wrote: > >> We have: >> * pg_ldecoding (Heikki) >> * pg_lcse or pg_lcset (Petr) >> * pg_logical (Andres) >> >> I like, what a surprise, my own suggestion best. The name seems more >> versatile because it's not restricted to decoding. >> > I don't care too much really, either one is find - but if I should vote, > I'll split my vote between pg_locical and pg_ldecoding, I don't like lcse > and lcset very much. pg_changesets ? - Heikki
On 2014-06-05 14:12:31 +0300, Heikki Linnakangas wrote: > On 06/05/2014 01:57 PM, Andres Freund wrote: > >On 2014-06-05 10:57:58 +0900, Fujii Masao wrote: > >We have: > >* pg_ldecoding (Heikki) > >* pg_lcse or pg_lcset (Petr) > >* pg_logical (Andres) > > > >I like, what a surprise, my own suggestion best. The name seems more > >versatile because it's not restricted to decoding. > > The problem with pg_logical is that it's not restricted to much at all ;-), > "logical" is an awfully generic name. So is base/, global/, pg_stat/,... I don't think we need uber-descriptive names here. I do think it's descriptive enough that unrelated data won't be looked for in there. And imo that's the case. > BTW, the stuff that we have in pg_llog are not really logs at all, so > pg_llog was always a misnomer. I'm not fighting for it :). Greetings, Andres Freund -- Andres Freund http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training & Services
On 2014-06-05 12:57:57 +0200, Andres Freund wrote: > On 2014-06-05 10:57:58 +0900, Fujii Masao wrote: > > I like using "slot_name" everywhere, i.e, even in recovery.conf. > > primary_slot_name seems not so long name. > > It also has the advantage that we can add a couple more slot_* options > later. Will do that. Ok. Here's a patch using slot_name everywhere user visible. There's a couple of places in the code where 'slotname' is still used, but those look more consistent that way in their context. I'll push that later unless somebody suggests changes. It's much easier to review changes after applying them when using --word-diff=color --word-diff-regex='[^[:space:]\<\>\,]+' as parameters to git diff/show. Greetings, Andres Freund -- Andres Freund http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services
Вложения
On Thu, Jun 5, 2014 at 7:12 AM, Heikki Linnakangas <hlinnakangas@vmware.com> wrote: >>> BTW, what about also renaming pg_llog directory? I'm afraid that >>> a user can confuse pg_log with pg_llog. >> >> We have: >> * pg_ldecoding (Heikki) >> * pg_lcse or pg_lcset (Petr) >> * pg_logical (Andres) >> >> I like, what a surprise, my own suggestion best. The name seems more >> versatile because it's not restricted to decoding. > > The problem with pg_logical is that it's not restricted to much at all ;-), > "logical" is an awfully generic name. True. But we don't have anything else with which it's liable to be confused. > BTW, the stuff that we have in pg_llog are not really logs at all, so > pg_llog was always a misnomer. Also true. For my part, I'd strongly prefer a name based on the term "logical decoding". This feature has lots of names (change-set extraction, logical replication, blah blah) and I worked pretty hard to make sure that the core patch as committed referred to it in just one way (logical decoding) everywhere. I'd rather not call this pg_lcse or pg_lcset or something like that because now we're introducing other terminology that's not used elsewhere. I'll defer to the group on whether it should be called pg_logical or pg_logicaldecoding or pg_logical_decoding or pg_ldecoding or pg_logdec or pg_lOgIcAl___DECODing, but it should be something somehow based on that term. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
Robert Haas wrote: > > BTW, the stuff that we have in pg_llog are not really logs at all, so > > pg_llog was always a misnomer. > > Also true. > > For my part, I'd strongly prefer a name based on the term "logical > decoding". This feature has lots of names (change-set extraction, > logical replication, blah blah) and I worked pretty hard to make sure > that the core patch as committed referred to it in just one way > (logical decoding) everywhere. I'd rather not call this pg_lcse or > pg_lcset or something like that because now we're introducing other > terminology that's not used elsewhere. I'll defer to the group on > whether it should be called pg_logical or pg_logicaldecoding or > pg_logical_decoding or pg_ldecoding or pg_logdec or > pg_lOgIcAl___DECODing, but it should be something somehow based on > that term. There is no reason not to use long names, so I think pg_logical_decoding is fine. -- Álvaro Herrera http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services
Alvaro Herrera <alvherre@2ndquadrant.com> writes:
> Robert Haas wrote:
>> For my part, I'd strongly prefer a name based on the term "logical
>> decoding".
> There is no reason not to use long names, so I think pg_logical_decoding
> is fine.
+1
regards, tom lane
On June 5, 2014 7:43:06 PM CEST, Tom Lane <tgl@sss.pgh.pa.us> wrote: >Alvaro Herrera <alvherre@2ndquadrant.com> writes: >> Robert Haas wrote: >>> For my part, I'd strongly prefer a name based on the term "logical >>> decoding". > >> There is no reason not to use long names, so I think >pg_logical_decoding >> is fine. > >+1 Still not a fan oft having decoding in the name. I've at least one patch pending (replication identifiers, submitted a couplemonths back) that will need to stash a couple of files somewhere. And it's for the apply side, not the decoding side. Andres -- Please excuse brevity and formatting - I am writing this on my mobile phone. Andres Freund http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services
On 05/06/14 19:56, Andres Freund wrote: > On June 5, 2014 7:43:06 PM CEST, Tom Lane <tgl@sss.pgh.pa.us> wrote: >> Alvaro Herrera <alvherre@2ndquadrant.com> writes: >>> Robert Haas wrote: >>>> For my part, I'd strongly prefer a name based on the term "logical >>>> decoding". >> >>> There is no reason not to use long names, so I think >> pg_logical_decoding >>> is fine. >> >> +1 > > Still not a fan oft having decoding in the name. I've at least one patch pending (replication identifiers, submitted acouple months back) that will need to stash a couple of files somewhere. And it's for the apply side, not the decoding side. > Personally I like your suggestion of pg_logical -- Petr Jelinek http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services
On Fri, Jun 6, 2014 at 2:43 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote: > Alvaro Herrera <alvherre@2ndquadrant.com> writes: >> Robert Haas wrote: >>> For my part, I'd strongly prefer a name based on the term "logical >>> decoding". > >> There is no reason not to use long names, so I think pg_logical_decoding >> is fine. > > +1 Indeed. With such a name there is no way to misunderstand its content. -- Michael
On 2014-06-05 12:57:57 +0200, Andres Freund wrote: > > BTW, what about also renaming pg_llog directory? I'm afraid that > > a user can confuse pg_log with pg_llog. > > We have: > * pg_ldecoding (Heikki) > * pg_lcse or pg_lcset (Petr) > * pg_logical (Andres) > > I like, what a surprise, my own suggestion best. The name seems more > versatile because it's not restricted to decoding. So, we haven't really come to any conclusion in this thread and we better change it soon, if at all. So, unless somebody protests against it I'm going to rename pg_llog to pg_logical and document it. Greetings, Andres Freund -- Andres Freund http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training & Services