Re: [DOCS] Confused about a statement in WAL configs
On Mon, Jul 31, 2017 at 10:04 AM, David G. Johnston < [email protected]> wrote: > On Mon, Jul 31, 2017 at 6:16 AM, wrote: > >> The following documentation comment has been logged on the website: >> >> Page: https://www.postgresql.org/docs/9.6/static/wal-configuration.html >> Description: >> >> In this section: >> >> "At checkpoint time, all dirty data pages are flushed to disk and a >> special >> checkpoint record is written to the log file. (The change records were >> previously flushed to the WAL files.)" >> >> I am confused by what the part in parenthesis means by >> "previously". This >> may only reflect my ignorance, but I don't know if >> "previously" means "in >> previous versions of Postgres" or "before the checkpoint" >> or something >> else. >> >> Mostly because of this, I don't understand what this statement >> means. Thank >> you. >> > > "previously" in that sentence means "earlier in time". The "WAL files" > are written to during every COMMIT. They constitute a journal of changes > that affected the in-memory "pages" and made them "dirty". During a > checkpoint a marker entry is written that says a checkpoint has occurred > and that every change noted in the WAL files written before the marker > entry and now known to exist in the actual data files on disk. > Forgive me, but I don't quite follow this clause at it's not a complete sentence: "every change noted in the WAL files written before the marker entry and now known to exist in the actual data files on disk". Is there a typo here? > Until that happens some of those change may only exist in memory (in the > form of dirty data pages). > > David J. > I *think* I follow now: before the checkpoint, the dirty data pages had already been written to the WAL files, but not necessarily flushed to disk. The checkpoint flushes them all to disk as well. If that is the case, I still think the wording is confusing and should be updated to say that ^^ more explicitly spelled out. For example: At checkpoint time, all dirty data pages are flushed to disk and a special checkpoint record is written to the log file. (The change records were previously flushed only to the WAL files, not necessarily to disk). Again, if I understand rightly. Thank you.
Re: [DOCS] Confused about a statement in WAL configs
On Tue, Aug 1, 2017 at 7:23 AM, Jeremy Finzel wrote: > > I *think* I follow now: before the checkpoint, the dirty data pages had > already been written to the WAL files, but not necessarily flushed to > disk. The checkpoint flushes them all to disk as well. > Yes, that it correct. David J.
[DOCS] Use of term Master/Slave
The following documentation comment has been logged on the website: Page: https://www.postgresql.org/docs/9.6/static/release-9-6.html Description: Wondering why PostgreSQL still uses the terms master and slave when there are other terms like primary/secondary that can be used in the same manner. -- Sent via pgsql-docs mailing list ([email protected]) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-docs
[DOCS] Reg Date/Time function
The following documentation comment has been logged on the website: Page: https://www.postgresql.org/docs/8.2/static/functions-datetime.html Description: Hi, I am going through PostgreSQL, for the first day. And it was great till now. One quick question/doubt regarding the function "justify_days(interval)" select justify_days(interval '365 days'); this statement returns 1 year 5 days, whereas I feel it should be just 1 year. Please correct me if I am wrong.. Thanks for all your time. -- Sent via pgsql-docs mailing list ([email protected]) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-docs
[DOCS] "data" not "datums"
The following documentation comment has been logged on the website: Page: https://www.postgresql.org/docs/9.4/static/datatype-json.html Description: In the section https://www.postgresql.org/docs/9.4/static/datatype-json.html Sub-section: 8.14.2. Designing JSON documents effectively Original text: "but having a predictable structure makes it easier to write queries that usefully summarize a set of "documents" (datums) in a table." Suggested text: "but having a predictable structure makes it easier to write queries that usefully summarize a set of "documents" (data) in a table." -- Sent via pgsql-docs mailing list ([email protected]) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-docs
Re: [DOCS] Use of term Master/Slave
Hi, On 2017-07-31 21:13:48 +, [email protected] wrote: > The following documentation comment has been logged on the website: > > Page: https://www.postgresql.org/docs/9.6/static/release-9-6.html > Description: > > Wondering why PostgreSQL still uses the terms master and slave when there > are other terms like primary/secondary that can be used in the same manner. Yea, I think we should be more careful from now on. I think several people already try, but it's not been a concerted effort so far. I'm not convinced it's a good idea to change old release notes though. - Andres -- Sent via pgsql-docs mailing list ([email protected]) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-docs
Re: [DOCS] Reg Date/Time function
Per the docs, justify_days is to "Adjust interval so 30-day time periods are represented as months" so 360 days = 12 months = 1 year so 365 days is 1-year 5-days. There are all sorts of oddities and special assumptions regarding date/time calculations made even more complicated by the need to support special use-cases such as 30/360 financial coupon factor calculations (every month is 30-days and years have 360 days). Cheers, Steve On Mon, Jul 31, 2017 at 5:30 PM, wrote: > The following documentation comment has been logged on the website: > > Page: https://www.postgresql.org/docs/8.2/static/functions-datetime.html > Description: > > Hi, > I am going through PostgreSQL, for the first day. And it was great till > now. > One quick question/doubt regarding the function > "justify_days(interval)" > > select justify_days(interval '365 days'); > > this statement returns 1 year 5 days, whereas I feel it should be just 1 > year. > > Please correct me if I am wrong.. Thanks for all your time. > > -- > Sent via pgsql-docs mailing list ([email protected]) > To make changes to your subscription: > http://www.postgresql.org/mailpref/pgsql-docs >
Re: [DOCS] Use of term Master/Slave
On 31 July 2017 at 22:13, wrote: > The following documentation comment has been logged on the website: > > Page: https://www.postgresql.org/docs/9.6/static/release-9-6.html > Description: > > Wondering why PostgreSQL still uses the terms master and slave when there > are other terms like primary/secondary that can be used in the same manner. Do you think primary/secondary is more descriptive? I started using the terms Primary and Secondary in the original use, but I think we've moved away from that towards Master/Standby, which fits better with a world where "muti-master" is a frequently used term and an eventual goal in core. Multi-primary doesn't seem to make much sense. -- Simon Riggshttp://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services -- Sent via pgsql-docs mailing list ([email protected]) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-docs
Re: [DOCS] Use of term Master/Slave
On 08/01/2017 12:41 PM, Simon Riggs wrote: On 31 July 2017 at 22:13, wrote: The following documentation comment has been logged on the website: Page: https://www.postgresql.org/docs/9.6/static/release-9-6.html Description: Wondering why PostgreSQL still uses the terms master and slave when there are other terms like primary/secondary that can be used in the same manner. Do you think primary/secondary is more descriptive? I don't, especially when you take into account cascading replication. If we are going to change these terms we may want to look at the old slony (and new logical replication) terms such as Origin and Subscriber. Thanks, JD -- Command Prompt, Inc. || http://the.postgres.company/ || @cmdpromptinc PostgreSQL Centered full stack support, consulting and development. Advocate: @amplifypostgres || Learn: https://pgconf.us * Unless otherwise stated, opinions are my own. * -- Sent via pgsql-docs mailing list ([email protected]) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-docs
Re: [DOCS] Use of term Master/Slave
Simon Riggs wrote: > On 31 July 2017 at 22:13, wrote: > > The following documentation comment has been logged on the website: > > > > Page: https://www.postgresql.org/docs/9.6/static/release-9-6.html > > Description: > > > > Wondering why PostgreSQL still uses the terms master and slave when there > > are other terms like primary/secondary that can be used in the same manner. > > Do you think primary/secondary is more descriptive? I think "primary" is fine, but "secondary" isn't. > I started using the terms Primary and Secondary in the original use, > but I think we've moved away from that towards Master/Standby, which > fits better with a world where "muti-master" is a frequently used term > and an eventual goal in core. Multi-primary doesn't seem to make much > sense. Elsewhere we've started using the terms "origin" and "replica". "Multi-origin" sounds sensible enough to me whereas "multi-primary" doesn't. -- Álvaro Herrerahttps://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services -- Sent via pgsql-docs mailing list ([email protected]) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-docs
Re: [DOCS] Use of term Master/Slave
Alvaro, all, * Alvaro Herrera ([email protected]) wrote: > Simon Riggs wrote: > > On 31 July 2017 at 22:13, wrote: > > > The following documentation comment has been logged on the website: > > > > > > Page: https://www.postgresql.org/docs/9.6/static/release-9-6.html > > > Description: > > > > > > Wondering why PostgreSQL still uses the terms master and slave when there > > > are other terms like primary/secondary that can be used in the same > > > manner. > > > > Do you think primary/secondary is more descriptive? > > I think "primary" is fine, but "secondary" isn't. > > > I started using the terms Primary and Secondary in the original use, > > but I think we've moved away from that towards Master/Standby, which > > fits better with a world where "muti-master" is a frequently used term > > and an eventual goal in core. Multi-primary doesn't seem to make much > > sense. > > Elsewhere we've started using the terms "origin" and "replica". > "Multi-origin" sounds sensible enough to me whereas "multi-primary" > doesn't. I don't feel like we see much of that terminology being used, whereas 'primary' and 'replica' seem to be more common (particularly since that's what the big O company uses). Multi-origin doesn't "feel" any better to me than multi-primary does (neither is great...), but when it comes to the logical replication side of things, publishers and subscribers does seem to fit well and so I'm not entirely sure that we actually need to use the terms "multi-primary" or "multi-origin"..? Thanks! Stephen signature.asc Description: Digital signature
Re: [DOCS] Use of term Master/Slave
> On Aug 1, 2017, at 3:59 PM, Stephen Frost wrote: > > Alvaro, all, > > * Alvaro Herrera ([email protected]) wrote: >> Simon Riggs wrote: >>> On 31 July 2017 at 22:13, wrote: The following documentation comment has been logged on the website: Page: https://www.postgresql.org/docs/9.6/static/release-9-6.html Description: Wondering why PostgreSQL still uses the terms master and slave when there are other terms like primary/secondary that can be used in the same manner. >>> >>> Do you think primary/secondary is more descriptive? >> >> I think "primary" is fine, but "secondary" isn't. >> >>> I started using the terms Primary and Secondary in the original use, >>> but I think we've moved away from that towards Master/Standby, which >>> fits better with a world where "muti-master" is a frequently used term >>> and an eventual goal in core. Multi-primary doesn't seem to make much >>> sense. >> >> Elsewhere we've started using the terms "origin" and "replica". >> "Multi-origin" sounds sensible enough to me whereas "multi-primary" >> doesn't. > > I don't feel like we see much of that terminology being used, whereas > 'primary' and 'replica' seem to be more common (particularly since > that's what the big O company uses). +1 > Multi-origin doesn't "feel" any better to me than multi-primary does > (neither is great...), but when it comes to the logical replication side > of things, publishers and subscribers does seem to fit well and so I'm > not entirely sure that we actually need to use the terms "multi-primary" > or "multi-origin"..? For the type of things logical replication does, publisher / subscriber does seem to be the accepted terminology. We just need to be careful in our own documentation based on the LISTEN / NOTIFY functionality that also has similar subscribe / publish terminology in the industry. Jonathan -- Sent via pgsql-docs mailing list ([email protected]) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-docs
Re: [DOCS] Reg Date/Time function
On 1 August 2017 at 12:30, wrote: > Hi, > I am going through PostgreSQL, for the first day. And it was great till > now. > One quick question/doubt regarding the function > "justify_days(interval)" > > select justify_days(interval '365 days'); > > this statement returns 1 year 5 days, whereas I feel it should be just 1 > year. > > Please correct me if I am wrong.. Thanks for all your time. It seems you are trying to convert a time interval type to days. The most reliable way to get this is to extract the epoch, which is in number of seconds, then convert this to days (divide by 60 * 60 * 24). SELECT x, extract(epoch from x)/86400 AS days FROM ( SELECT '1 year'::interval AS x UNION ALL SELECT '365 days' ) AS sub; x | days --+ 1 year | 365.25 365 days |365 (2 rows) A typical "year" indeed has 365.25 days, when you consider leap years typically every 4th. As noted previously, justify_days(interval) has a special use for 360-day calendars[1]. [1] https://en.wikipedia.org/wiki/360-day_calendar -- Sent via pgsql-docs mailing list ([email protected]) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-docs
Re: [DOCS] Use of term Master/Slave
On 1 August 2017 at 09:13, wrote: > Wondering why PostgreSQL still uses the terms master and slave when there > are other terms like primary/secondary that can be used in the same manner. Another alternative I've seen in different fields is "manager" and "agent". -- Sent via pgsql-docs mailing list ([email protected]) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-docs
Re: [DOCS] Reg Date/Time function
Thank you Steve for the information. Thanks, Sandeep Segu. On Tue, Aug 1, 2017 at 2:04 PM, Steve Crawford < [email protected]> wrote: > Per the docs, justify_days is to "Adjust interval so 30-day time periods > are represented as months" so 360 days = 12 months = 1 year so 365 days is > 1-year 5-days. > > There are all sorts of oddities and special assumptions regarding > date/time calculations made even more complicated by the need to support > special use-cases such as 30/360 financial coupon factor calculations > (every month is 30-days and years have 360 days). > > Cheers, > Steve > > > On Mon, Jul 31, 2017 at 5:30 PM, wrote: > >> The following documentation comment has been logged on the website: >> >> Page: https://www.postgresql.org/docs/8.2/static/functions-datetime.html >> Description: >> >> Hi, >> I am going through PostgreSQL, for the first day. And it was great till >> now. >> One quick question/doubt regarding the function >> "justify_days(interval)" >> >> select justify_days(interval '365 days'); >> >> this statement returns 1 year 5 days, whereas I feel it should be just 1 >> year. >> >> Please correct me if I am wrong.. Thanks for all your time. >> >> -- >> Sent via pgsql-docs mailing list ([email protected]) >> To make changes to your subscription: >> http://www.postgresql.org/mailpref/pgsql-docs >> > >
