Re: [HACKERS] slotname vs slot_name
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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] slotname vs slot_name
On 06/05/2014 05:09 AM, Amit Langote wrote: Hi, On Thu, Jun 5, 2014 at 10:57 AM, Fujii Masao masao.fu...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] slotname vs slot_name
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.fu...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] slotname vs slot_name
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 signature.asc Description: This is a digitally signed message part
Re: [HACKERS] slotname vs slot_name
On Jun 5, 2014 10:22 AM, Devrim Gündüz dev...@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 :-) /Magnus
Re: [HACKERS] slotname vs slot_name
On Thu, Jun 5, 2014 at 5:27 PM, Magnus Hagander mag...@hagander.net wrote: On Jun 5, 2014 10:22 AM, Devrim Gündüz dev...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] slotname vs slot_name
On 2014-06-05 10:57:58 +0900, Fujii Masao wrote: On Thu, Jun 5, 2014 at 8:24 AM, Andres Freund and...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] slotname vs slot_name
On Thu, Jun 5, 2014 at 7:57 PM, Andres Freund and...@2ndquadrant.com wrote: We have: * pg_ldecoding (Heikki) * pg_lcse or pg_lcset (Petr) * pg_logical (Andres) pg_decoding, simply? -- Michael -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] slotname vs slot_name
On 2014-06-05 20:02:38 +0900, Michael Paquier wrote: On Thu, Jun 5, 2014 at 7:57 PM, Andres Freund and...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] slotname vs slot_name
On Thu, Jun 5, 2014 at 12:57 PM, Andres Freund and...@2ndquadrant.com wrote: On 2014-06-05 10:57:58 +0900, Fujii Masao wrote: On Thu, Jun 5, 2014 at 8:24 AM, Andres Freund and...@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. 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/
Re: [HACKERS] slotname vs slot_name
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 and...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] slotname vs slot_name
On 06/05/2014 02:10 PM, Magnus Hagander wrote: On Thu, Jun 5, 2014 at 12:57 PM, Andres Freund and...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] slotname vs slot_name
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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] slotname vs slot_name
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 From 31bf302736625621c164366aaa578def09f57237 Mon Sep 17 00:00:00 2001 From: Andres Freund and...@anarazel.de Date: Thu, 5 Jun 2014 13:25:22 +0200 Subject: [PATCH] Consistently spell a replication slot's name as slot_name. Previously there's been a mix between 'slotname' and 'slot_name'. It's not nice to be inconsistent in a new feature. As a post beta1 initdb is required now anyways, fix the inconsistencies. Most the changes won't affect usage of replication slots because the majority of changes is around function parameter names. The prominent exception to that is that the recovery.conf parameter 'primary_slotname' is now named 'primary_slot_name'. --- doc/src/sgml/func.sgml | 28 - doc/src/sgml/high-availability.sgml | 6 +++--- doc/src/sgml/logicaldecoding.sgml | 8 +++ doc/src/sgml/protocol.sgml | 16 +++--- doc/src/sgml/recovery-config.sgml | 6 +++--- src/backend/access/transam/recovery.conf.sample | 2 +- src/backend/access/transam/xlog.c | 4 ++-- src/backend/catalog/system_views.sql| 8 +++ src/bin/pg_basebackup/pg_recvlogical.c | 6 +++--- src/include/catalog/catversion.h| 2 +- src/include/catalog/pg_proc.h | 12 +-- 11 files changed, 49 insertions(+), 49 deletions(-) diff --git a/doc/src/sgml/func.sgml b/doc/src/sgml/func.sgml index c4bcefd..5c906f3 100644 --- a/doc/src/sgml/func.sgml +++ b/doc/src/sgml/func.sgml @@ -16609,14 +16609,14 @@ postgres=# SELECT * FROM pg_xlogfile_name_offset(pg_stop_backup()); indexterm primarypg_create_physical_replication_slot/primary /indexterm -literalfunctionpg_create_physical_replication_slot(parameterslotname/parameter typename/type)/function/literal +literalfunctionpg_create_physical_replication_slot(parameterslot_name/parameter typename/type)/function/literal /entry entry -(parameterslotname/parameter typename/type, parameterxlog_position/parameter typepg_lsn/type) +(parameterslot_name/parameter typename/type, parameterxlog_position/parameter typepg_lsn/type) /entry entry Creates a new physical replication slot named -parameterslotname/parameter. Streaming changes from a physical slot +parameterslot_name/parameter. Streaming changes from a physical slot is only possible with the walsender protocol - see xref linkend=protocol-replication. Corresponds to the walsender protocol command literalCREATE_REPLICATION_SLOT ... PHYSICAL/literal. @@ -16627,14 +16627,14 @@ postgres=# SELECT * FROM pg_xlogfile_name_offset(pg_stop_backup()); indexterm primarypg_drop_replication_slot/primary /indexterm -literalfunctionpg_drop_replication_slot(parameterslotname/parameter typename/type)/function/literal +literalfunctionpg_drop_replication_slot(parameterslot_name/parameter typename/type)/function/literal /entry entry typevoid/type /entry entry Drops the physical or logical replication slot -named parameterslotname/parameter. Same as walsender protocol +named parameterslot_name/parameter. Same as walsender protocol command literalDROP_REPLICATION_SLOT/. /entry /row @@ -16644,14 +16644,14 @@ postgres=# SELECT * FROM pg_xlogfile_name_offset(pg_stop_backup()); indexterm primarypg_create_logical_replication_slot/primary /indexterm -literalfunctionpg_create_logical_replication_slot(parameterslotname/parameter typename/type, parameterplugin/parameter typename/type)/function/literal +literalfunctionpg_create_logical_replication_slot(parameterslot_name/parameter typename/type, parameterplugin/parameter typename/type)/function/literal /entry entry -(parameterslotname/parameter typename/type, parameterxlog_position/parameter typepg_lsn/type) +(parameterslot_name/parameter
Re: [HACKERS] slotname vs slot_name
On Thu, Jun 5, 2014 at 7:12 AM, Heikki Linnakangas hlinnakan...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] slotname vs slot_name
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 Herrerahttp://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] slotname vs slot_name
Alvaro Herrera alvhe...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] slotname vs slot_name
On June 5, 2014 7:43:06 PM CEST, Tom Lane t...@sss.pgh.pa.us wrote: Alvaro Herrera alvhe...@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 couple months 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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] slotname vs slot_name
On 05/06/14 19:56, Andres Freund wrote: On June 5, 2014 7:43:06 PM CEST, Tom Lane t...@sss.pgh.pa.us wrote: Alvaro Herrera alvhe...@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 couple 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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] slotname vs slot_name
On Fri, Jun 6, 2014 at 2:43 AM, Tom Lane t...@sss.pgh.pa.us wrote: Alvaro Herrera alvhe...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] slotname vs slot_name
On Thu, Jun 5, 2014 at 8:24 AM, Andres Freund and...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] slotname vs slot_name
Hi, On Thu, Jun 5, 2014 at 10:57 AM, Fujii Masao masao.fu...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
