FAQ

On Fri, Jun 15, 2012 at 1:52 AM, Magnus Hagander wrote:
On Fri, Jun 15, 2012 at 1:29 AM, Robert Haas wrote:
New SQL functons pg_backup_in_progress() and pg_backup_start_time()

Darold Gilles, reviewed by Gabriele Bartolini and others, rebased by
Marco Nenciarini.  Stylistic cleanup and OID fixes by me.
How well is the term "on-line exclusive backup" really settled with
people? I wonder if we need to add a specific note to the docs saying
that the function doesn't consider streaming base backups at all, and
that one should refer to pg_stat_replication for info about those? Or
really, should the function be pg_exclusive_backup_in_progress()
perhaps?
Well, if we think that the term "exclusive backup" is not going to be
easily comprehensible, then sticking that into the function name isn't
going to help us much. I think that's just wordiness for the sake of
being wordy. I do agree that we could probably improve the clarity of
the documentation along the lines you suggest.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

Search Discussions

  • Magnus Hagander at Jun 15, 2012 at 2:54 pm

    On Fri, Jun 15, 2012 at 8:16 PM, Robert Haas wrote:
    On Fri, Jun 15, 2012 at 1:52 AM, Magnus Hagander wrote:
    On Fri, Jun 15, 2012 at 1:29 AM, Robert Haas wrote:
    New SQL functons pg_backup_in_progress() and pg_backup_start_time()

    Darold Gilles, reviewed by Gabriele Bartolini and others, rebased by
    Marco Nenciarini.  Stylistic cleanup and OID fixes by me.
    How well is the term "on-line exclusive backup" really settled with
    people? I wonder if we need to add a specific note to the docs saying
    that the function doesn't consider streaming base backups at all, and
    that one should refer to pg_stat_replication for info about those? Or
    really, should the function be pg_exclusive_backup_in_progress()
    perhaps?
    Well, if we think that the term "exclusive backup" is not going to be
    easily comprehensible, then sticking that into the function name isn't
    going to help us much.  I think that's just wordiness for the sake of
    being wordy.  I do agree that we could probably improve the clarity of
    the documentation along the lines you suggest.
    It would alert people to the existance of the term, and thus help
    those who didn't actually read the documentation.

    Which actually makes an argument for making that change *anyway*,
    because right now the function is incorrectly named. A function named
    pg_backup_in_progress() should answer the question "is a backup in
    progress". And it doesn't answer that question.
  • Thom Brown at Jun 15, 2012 at 3:08 pm

    On 15 June 2012 15:54, Magnus Hagander wrote:
    On Fri, Jun 15, 2012 at 8:16 PM, Robert Haas wrote:
    On Fri, Jun 15, 2012 at 1:52 AM, Magnus Hagander wrote:
    On Fri, Jun 15, 2012 at 1:29 AM, Robert Haas wrote:
    New SQL functons pg_backup_in_progress() and pg_backup_start_time()

    Darold Gilles, reviewed by Gabriele Bartolini and others, rebased by
    Marco Nenciarini.  Stylistic cleanup and OID fixes by me.
    How well is the term "on-line exclusive backup" really settled with
    people? I wonder if we need to add a specific note to the docs saying
    that the function doesn't consider streaming base backups at all, and
    that one should refer to pg_stat_replication for info about those? Or
    really, should the function be pg_exclusive_backup_in_progress()
    perhaps?
    Well, if we think that the term "exclusive backup" is not going to be
    easily comprehensible, then sticking that into the function name isn't
    going to help us much.  I think that's just wordiness for the sake of
    being wordy.  I do agree that we could probably improve the clarity of
    the documentation along the lines you suggest.
    It would alert people to the existance of the term, and thus help
    those who didn't actually read the documentation.

    Which actually makes an argument for making that change *anyway*,
    because right now the function is incorrectly named. A function named
    pg_backup_in_progress() should answer the question "is a backup in
    progress". And it doesn't answer that question.
    Maybe pg_is_in_backup_mode, which would match the naming convention of
    pg_is_in_recovery, and would claim that a backup is actually underway.

    --
    Thom
  • Magnus Hagander at Jun 15, 2012 at 3:10 pm

    On Fri, Jun 15, 2012 at 11:08 PM, Thom Brown wrote:
    On 15 June 2012 15:54, Magnus Hagander wrote:
    On Fri, Jun 15, 2012 at 8:16 PM, Robert Haas wrote:
    On Fri, Jun 15, 2012 at 1:52 AM, Magnus Hagander wrote:
    On Fri, Jun 15, 2012 at 1:29 AM, Robert Haas wrote:
    New SQL functons pg_backup_in_progress() and pg_backup_start_time()

    Darold Gilles, reviewed by Gabriele Bartolini and others, rebased by
    Marco Nenciarini.  Stylistic cleanup and OID fixes by me.
    How well is the term "on-line exclusive backup" really settled with
    people? I wonder if we need to add a specific note to the docs saying
    that the function doesn't consider streaming base backups at all, and
    that one should refer to pg_stat_replication for info about those? Or
    really, should the function be pg_exclusive_backup_in_progress()
    perhaps?
    Well, if we think that the term "exclusive backup" is not going to be
    easily comprehensible, then sticking that into the function name isn't
    going to help us much.  I think that's just wordiness for the sake of
    being wordy.  I do agree that we could probably improve the clarity of
    the documentation along the lines you suggest.
    It would alert people to the existance of the term, and thus help
    those who didn't actually read the documentation.

    Which actually makes an argument for making that change *anyway*,
    because right now the function is incorrectly named. A function named
    pg_backup_in_progress() should answer the question "is a backup in
    progress". And it doesn't answer that question.
    Maybe pg_is_in_backup_mode, which would match the naming convention of
    pg_is_in_recovery, and would claim that a backup is actually underway.
    Wouldn't that make it even more wrong since it doesn't include backups
    taken using streaming backups?
  • Thom Brown at Jun 15, 2012 at 3:12 pm

    On 15 June 2012 16:09, Magnus Hagander wrote:
    On Fri, Jun 15, 2012 at 11:08 PM, Thom Brown wrote:
    On 15 June 2012 15:54, Magnus Hagander wrote:
    On Fri, Jun 15, 2012 at 8:16 PM, Robert Haas wrote:
    On Fri, Jun 15, 2012 at 1:52 AM, Magnus Hagander wrote:
    On Fri, Jun 15, 2012 at 1:29 AM, Robert Haas wrote:
    New SQL functons pg_backup_in_progress() and pg_backup_start_time()

    Darold Gilles, reviewed by Gabriele Bartolini and others, rebased by
    Marco Nenciarini.  Stylistic cleanup and OID fixes by me.
    How well is the term "on-line exclusive backup" really settled with
    people? I wonder if we need to add a specific note to the docs saying
    that the function doesn't consider streaming base backups at all, and
    that one should refer to pg_stat_replication for info about those? Or
    really, should the function be pg_exclusive_backup_in_progress()
    perhaps?
    Well, if we think that the term "exclusive backup" is not going to be
    easily comprehensible, then sticking that into the function name isn't
    going to help us much.  I think that's just wordiness for the sake of
    being wordy.  I do agree that we could probably improve the clarity of
    the documentation along the lines you suggest.
    It would alert people to the existance of the term, and thus help
    those who didn't actually read the documentation.

    Which actually makes an argument for making that change *anyway*,
    because right now the function is incorrectly named. A function named
    pg_backup_in_progress() should answer the question "is a backup in
    progress". And it doesn't answer that question.
    Maybe pg_is_in_backup_mode, which would match the naming convention of
    pg_is_in_recovery, and would claim that a backup is actually underway.
    Wouldn't that make it even more wrong since it doesn't include backups
    taken using streaming backups?
    Sorry I mean "*wouldn't* claim that a backup is underway"

    --
    Thom
  • Heikki Linnakangas at Jun 15, 2012 at 3:14 pm

    On 15.06.2012 17:54, Magnus Hagander wrote:
    On Fri, Jun 15, 2012 at 8:16 PM, Robert Haaswrote:
    On Fri, Jun 15, 2012 at 1:52 AM, Magnus Haganderwrote:
    On Fri, Jun 15, 2012 at 1:29 AM, Robert Haaswrote:
    New SQL functons pg_backup_in_progress() and pg_backup_start_time()

    Darold Gilles, reviewed by Gabriele Bartolini and others, rebased by
    Marco Nenciarini. Stylistic cleanup and OID fixes by me.
    How well is the term "on-line exclusive backup" really settled with
    people? I wonder if we need to add a specific note to the docs saying
    that the function doesn't consider streaming base backups at all, and
    that one should refer to pg_stat_replication for info about those? Or
    really, should the function be pg_exclusive_backup_in_progress()
    perhaps?
    Well, if we think that the term "exclusive backup" is not going to be
    easily comprehensible, then sticking that into the function name isn't
    going to help us much. I think that's just wordiness for the sake of
    being wordy. I do agree that we could probably improve the clarity of
    the documentation along the lines you suggest.
    It would alert people to the existance of the term, and thus help
    those who didn't actually read the documentation.
    I'm not sure we want to expose the "exclusive backup" term to users.
    It's a bit confusing. It makes sense in the limited scope in the code in
    xlog.c where it's currently used, but if I wanted to explain what it is
    to users, I don't think I'd choose that term.
    Which actually makes an argument for making that change *anyway*,
    because right now the function is incorrectly named. A function named
    pg_backup_in_progress() should answer the question "is a backup in
    progress". And it doesn't answer that question.
    I agree that pg_backup_in_progress() is confusing, if it returns false
    while you're running pg_basebackup. In the doc changes you proposed, you
    call the pg_start/stop_backup() a "low level API" for taking backups.
    That's not suitable for a function name, but I think we should work on
    that, and find a better term that works.

    Backup mode? Filesystem backup mode?

    --
    Heikki Linnakangas
    EnterpriseDB http://www.enterprisedb.com
  • Magnus Hagander at Jun 16, 2012 at 3:49 am

    On Fri, Jun 15, 2012 at 11:14 PM, Heikki Linnakangas wrote:
    On 15.06.2012 17:54, Magnus Hagander wrote:

    On Fri, Jun 15, 2012 at 8:16 PM, Robert Haas<robertmhaas@gmail.com>
    wrote:
    On Fri, Jun 15, 2012 at 1:52 AM, Magnus Hagander<magnus@hagander.net>
    wrote:
    On Fri, Jun 15, 2012 at 1:29 AM, Robert Haas<rhaas@postgresql.org>
    wrote:
    New SQL functons pg_backup_in_progress() and pg_backup_start_time()

    Darold Gilles, reviewed by Gabriele Bartolini and others, rebased by
    Marco Nenciarini.  Stylistic cleanup and OID fixes by me.

    How well is the term "on-line exclusive backup" really settled with
    people? I wonder if we need to add a specific note to the docs saying
    that the function doesn't consider streaming base backups at all, and
    that one should refer to pg_stat_replication for info about those? Or
    really, should the function be pg_exclusive_backup_in_progress()
    perhaps?

    Well, if we think that the term "exclusive backup" is not going to be
    easily comprehensible, then sticking that into the function name isn't
    going to help us much.  I think that's just wordiness for the sake of
    being wordy.  I do agree that we could probably improve the clarity of
    the documentation along the lines you suggest.

    It would alert people to the existance of the term, and thus help
    those who didn't actually read the documentation.

    I'm not sure we want to expose the "exclusive backup" term to users. It's a
    bit confusing. It makes sense in the limited scope in the code in xlog.c
    where it's currently used, but if I wanted to explain what it is to users, I
    don't think I'd choose that term.

    Which actually makes an argument for making that change *anyway*,
    because right now the function is incorrectly named. A function named
    pg_backup_in_progress() should answer the question "is a backup in
    progress". And it doesn't answer that question.

    I agree that pg_backup_in_progress() is confusing, if it returns false while
    you're running pg_basebackup. In the doc changes you proposed, you call the
    pg_start/stop_backup() a "low level API" for taking backups. That's not
    suitable for a function name, but I think we should work on that, and find a
    better term that works.

    Backup mode? Filesystem backup mode?
    We already have backup mode, and it covers both of them really. And
    filesystem backup mode is also what pg_basebackup does - it takes a
    filesystem backup...

    The easiest one I can think of is the "manual backup mode", but in the
    other thread Simon didn't like that term.
  • Daniel Farina at Jun 18, 2012 at 3:40 am

    On Fri, Jun 15, 2012 at 8:49 PM, Magnus Hagander wrote:
    I agree that pg_backup_in_progress() is confusing, if it returns false while
    you're running pg_basebackup. In the doc changes you proposed, you call the
    pg_start/stop_backup() a "low level API" for taking backups. That's not
    suitable for a function name, but I think we should work on that, and find a
    better term that works.

    Backup mode? Filesystem backup mode?
    We already have backup mode, and it covers both of them really. And
    filesystem backup mode is also what pg_basebackup does - it takes a
    filesystem backup...

    The easiest one I can think of is the "manual backup mode", but in the
    other thread Simon didn't like that term.
    Let me make things a bit worse since people are trying to figure out
    nomenclature and positioning in the documentation, especially taking
    consideration of pg_basebackup:

    I think that the "exclusive" nature of the pg_(start|stop)_backup mode
    (to use the original terminology under reconsideration) is quite
    harmful, related to what was raised in
    http://archives.postgresql.org/pgsql-hackers/2009-11/msg00024.php (I
    revisited this in
    http://archives.postgresql.org/pgsql-hackers/2011-11/msg01696.php)

    After mulling over this some more, I am less on the fence about how
    unfortunate it is that Postgres cannot restart when doing an
    "exclusive" base backup: I think it is a severe anti-feature that
    should gradually be retired. pg_basebackup has the better contract
    (whereby some information is very carefully inserted into the backup
    to trigger archive recovery), and pg_(start|stop)_backup has a worse
    one. There are more people performing archiving than there are writing
    archiving tools, and the latter category should just be expected to
    carefully get this right as pg_basebackup does. Tragically,
    pg_basebackup's archiving technique does not meet my requirements (and
    it's a non-trivial optimization that I'm not sure makes sense in every
    case, so I'm not sure it should be added), so those of us with other
    archivers are left with workarounds like moving the backup file around
    during the backup process.

    Such a move would render the notion of a "backup in progress" or
    single "backup start time" more or less obsolete. That's not to say
    that more reporting in the meantime shouldn't be added, because
    changing the archiving contract will take time, and meanwhile people
    are going to have to use the old contract between the archiving
    software of choice and Postgres for quite a while. However, I think
    the eventual deprecation of "exclusive" backup mode is where things
    should go, and maybe this will change someone's perception of how this
    should be represented in documentation.

    Finally, this complexity goes away (or rather, is moved, but hopefully
    made more cohesive) if one can delegate all WAL persistence to other
    software. The presence of backup_label most basically affects whether
    one wishes to recover via restore_command or the pg_xlog directory,
    which only mattered insomuch that the archiver was an asynchronous
    form of replication and pg_xlog was nominally a synchronous one. It's
    becoming less clear to me that these are deserving of being so
    distinct in the future: they're all sources of WAL, and with syncrep
    and group-commit already available, we're might be in a position to
    remove some surface area and duplicated concepts in tooling. Slowly.

    --
    fdr
  • Albe Laurenz at Jun 18, 2012 at 7:22 am

    Daniel Farina wrote:
    After mulling over this some more, I am less on the fence about how
    unfortunate it is that Postgres cannot restart when doing an
    "exclusive" base backup: I think it is a severe anti-feature that
    should gradually be retired.
    This anti-feature was introduced with
    http://archives.postgresql.org/pgsql-committers/2008-04/msg00275.php
    following discussions
    http://archives.postgresql.org/pgsql-hackers/2007-11/msg00800.php
    and
    http://archives.postgresql.org/pgsql-hackers/2008-03/msg01033.php

    The problem (at least for me) is that without this the server will
    often refuse to restart after a clean shutdown, namely when the
    WAL segment containing the required checkpoint has already been
    archived.

    Yours,
    Laurenz Albe

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
grouppgsql-hackers @
categoriespostgresql
postedJun 15, '12 at 12:17p
activeJun 18, '12 at 7:22a
posts9
users6
websitepostgresql.org...
irc#postgresql

People

Translate

site design / logo © 2021 Grokbase