FAQ
I can check for the presence of $PGDATA/backup_label in order to detect
a backup in progress (i.e. pg_start_backup() has been run and
pg_stop_backup() has not yet been run).

However there is a period of time after pg_start_backup() is first
executed to when it completes, during which backup_label file does not
exist yet, but the backup has essentially been started. Is there any
way to detect this state?

Thanks,

Joe

- --
Joe Conway
credativ LLC: http://www.credativ.us
Linux, PostgreSQL, and general Open Source
Training, Service, Consulting, & 24x7 Support

Search Discussions

  • Andres Freund at May 31, 2013 at 5:42 pm

    On 2013-05-31 10:38:56 -0700, Joe Conway wrote:
    I can check for the presence of $PGDATA/backup_label in order to detect
    a backup in progress (i.e. pg_start_backup() has been run and
    pg_stop_backup() has not yet been run).

    However there is a period of time after pg_start_backup() is first
    executed to when it completes, during which backup_label file does not
    exist yet, but the backup has essentially been started. Is there any
    way to detect this state?
    9.3 has pg_is_in_backup() for that. I don't think there's a way to
    detect it safely without C code before that.

    Greetings,

    Andres Freund

    --
      Andres Freund http://www.2ndQuadrant.com/
      PostgreSQL Development, 24x7 Support, Training & Services
  • Joe Conway at May 31, 2013 at 6:35 pm

    On 05/31/2013 10:42 AM, Andres Freund wrote:
    On 2013-05-31 10:38:56 -0700, Joe Conway wrote:
    I can check for the presence of $PGDATA/backup_label in order to
    detect a backup in progress (i.e. pg_start_backup() has been run
    and pg_stop_backup() has not yet been run).

    However there is a period of time after pg_start_backup() is
    first executed to when it completes, during which backup_label
    file does not exist yet, but the backup has essentially been
    started. Is there any way to detect this state?
    9.3 has pg_is_in_backup() for that. I don't think there's a way to
    detect it safely without C code before that.
    Good to know, although it won't help me much in my current scenario ;-)

    Thanks,

    Joe


    - --
    Joe Conway
    credativ LLC: http://www.credativ.us
    Linux, PostgreSQL, and general Open Source
    Training, Service, Consulting, & 24x7 Support
  • Thom Brown at May 31, 2013 at 5:43 pm

    On 31 May 2013 18:38, Joe Conway wrote:
    -----BEGIN PGP SIGNED MESSAGE-----
    Hash: SHA1

    I can check for the presence of $PGDATA/backup_label in order to detect
    a backup in progress (i.e. pg_start_backup() has been run and
    pg_stop_backup() has not yet been run).

    However there is a period of time after pg_start_backup() is first
    executed to when it completes, during which backup_label file does not
    exist yet, but the backup has essentially been started. Is there any
    way to detect this state?
    pg_is_in_backup()

    --
    Thom
  • Heikki Linnakangas at May 31, 2013 at 5:46 pm

    On 31.05.2013 20:38, Joe Conway wrote:
    I can check for the presence of $PGDATA/backup_label in order to detect
    a backup in progress (i.e. pg_start_backup() has been run and
    pg_stop_backup() has not yet been run).

    However there is a period of time after pg_start_backup() is first
    executed to when it completes, during which backup_label file does not
    exist yet, but the backup has essentially been started. Is there any
    way to detect this state?
    What are you trying to accomplish? Even if you eliminate that window,
    it's always possible that a backup starts just after you've checked that
    there is no backup in progress.

    - Heikki
  • Joe Conway at May 31, 2013 at 6:41 pm

    On 05/31/2013 10:46 AM, Heikki Linnakangas wrote:
    On 31.05.2013 20:38, Joe Conway wrote:
    I can check for the presence of $PGDATA/backup_label in order to
    detect a backup in progress (i.e. pg_start_backup() has been run
    and pg_stop_backup() has not yet been run).

    However there is a period of time after pg_start_backup() is
    first executed to when it completes, during which backup_label
    file does not exist yet, but the backup has essentially been
    started. Is there any way to detect this state?
    What are you trying to accomplish? Even if you eliminate that
    window, it's always possible that a backup starts just after you've
    checked that there is no backup in progress.
    We can lay down a lockfile before checking for backup in progress, and
    the script that starts the backup can check for the lockfile before
    doing anything. There is still a race-window, but I want to minimize
    it. pg_is_in_backup() mentioned nearby on this thread will help close
    the gap.

    Joe

    - --
    Joe Conway
    credativ LLC: http://www.credativ.us
    Linux, PostgreSQL, and general Open Source
    Training, Service, Consulting, & 24x7 Support
  • Heikki Linnakangas at May 31, 2013 at 7:30 pm

    On 31.05.2013 21:41, Joe Conway wrote:
    On 05/31/2013 10:46 AM, Heikki Linnakangas wrote:
    On 31.05.2013 20:38, Joe Conway wrote:
    I can check for the presence of $PGDATA/backup_label in order to
    detect a backup in progress (i.e. pg_start_backup() has been run
    and pg_stop_backup() has not yet been run).

    However there is a period of time after pg_start_backup() is
    first executed to when it completes, during which backup_label
    file does not exist yet, but the backup has essentially been
    started. Is there any way to detect this state?
    What are you trying to accomplish? Even if you eliminate that
    window, it's always possible that a backup starts just after you've
    checked that there is no backup in progress.
    We can lay down a lockfile before checking for backup in progress, and
    the script that starts the backup can check for the lockfile before
    doing anything. There is still a race-window, but I want to minimize
    it. pg_is_in_backup() mentioned nearby on this thread will help close
    the gap.
    Note that pg_is_in_backup() just checks for presence of
    $PGDATA/backup_label. Also note that pg_basebackup doesn't create
    backup_label in the server. It's included in the backup that's sent to
    the client, but it's never written to disk in the server. So checking
    for backup_label manually or with pg_is_in_backup() will return false
    even if pg_basebackup is running.

    - Heikki
  • Joe Conway at May 31, 2013 at 7:35 pm

    On 05/31/2013 12:29 PM, Heikki Linnakangas wrote:
    Note that pg_is_in_backup() just checks for presence of
    $PGDATA/backup_label. Also note that pg_basebackup doesn't create
    backup_label in the server. It's included in the backup that's sent
    to the client, but it's never written to disk in the server. So
    checking for backup_label manually or with pg_is_in_backup() will
    return false even if pg_basebackup is running.
    Oh, that's really good to know.

    So essentially there is no reliable way to know that pg_start_backup()
    has been executed and pg_stop_backup() has not?

    Joe

    - --
    Joe Conway
    credativ LLC: http://www.credativ.us
    Linux, PostgreSQL, and general Open Source
    Training, Service, Consulting, & 24x7 Support
  • Andres Freund at May 31, 2013 at 7:36 pm

    On 2013-05-31 22:29:45 +0300, Heikki Linnakangas wrote:
    On 31.05.2013 21:41, Joe Conway wrote:
    On 05/31/2013 10:46 AM, Heikki Linnakangas wrote:
    On 31.05.2013 20:38, Joe Conway wrote:
    I can check for the presence of $PGDATA/backup_label in order to
    detect a backup in progress (i.e. pg_start_backup() has been run
    and pg_stop_backup() has not yet been run).

    However there is a period of time after pg_start_backup() is
    first executed to when it completes, during which backup_label
    file does not exist yet, but the backup has essentially been
    started. Is there any way to detect this state?
    What are you trying to accomplish? Even if you eliminate that
    window, it's always possible that a backup starts just after you've
    checked that there is no backup in progress.
    We can lay down a lockfile before checking for backup in progress, and
    the script that starts the backup can check for the lockfile before
    doing anything. There is still a race-window, but I want to minimize
    it. pg_is_in_backup() mentioned nearby on this thread will help close
    the gap.
    Note that pg_is_in_backup() just checks for presence of
    $PGDATA/backup_label. Also note that pg_basebackup doesn't create
    backup_label in the server. It's included in the backup that's sent to the
    client, but it's never written to disk in the server. So checking for
    backup_label manually or with pg_is_in_backup() will return false even if
    pg_basebackup is running.
    Whoa. You are right, but I'd call that a bug. I don't understand why we
    aren't just checking
    XLogCtl->Insert.(nonExclusiveBackups||exlusiveBackup)?

    I vote for changing this before we release pg_is_in_backup().

    Greetings,

    Andres Freund

    --
      Andres Freund http://www.2ndQuadrant.com/
      PostgreSQL Development, 24x7 Support, Training & Services
  • Joe Conway at May 31, 2013 at 7:46 pm

    On 05/31/2013 12:36 PM, Andres Freund wrote:
    On 2013-05-31 22:29:45 +0300, Heikki Linnakangas wrote:
    Note that pg_is_in_backup() just checks for presence of
    $PGDATA/backup_label. Also note that pg_basebackup doesn't
    create backup_label in the server. It's included in the backup
    that's sent to the client, but it's never written to disk in the
    server. So checking for backup_label manually or with
    pg_is_in_backup() will return false even if pg_basebackup is
    running.
    Whoa. You are right, but I'd call that a bug. I don't understand
    why we aren't just checking
    XLogCtl->Insert.(nonExclusiveBackups||exlusiveBackup)?

    I vote for changing this before we release pg_is_in_backup().
    +1

    Joe

    - --
    Joe Conway
    credativ LLC: http://www.credativ.us
    Linux, PostgreSQL, and general Open Source
    Training, Service, Consulting, & 24x7 Support
  • Heikki Linnakangas at May 31, 2013 at 7:53 pm

    On 31.05.2013 22:36, Andres Freund wrote:
    On 2013-05-31 22:29:45 +0300, Heikki Linnakangas wrote:
    Note that pg_is_in_backup() just checks for presence of
    $PGDATA/backup_label. Also note that pg_basebackup doesn't create
    backup_label in the server. It's included in the backup that's sent to the
    client, but it's never written to disk in the server. So checking for
    backup_label manually or with pg_is_in_backup() will return false even if
    pg_basebackup is running.
    Whoa. You are right, but I'd call that a bug. I don't understand why we
    aren't just checking
    XLogCtl->Insert.(nonExclusiveBackups||exlusiveBackup)?
    Well, depends on what you imagine the function is used for. If you think
    of it as "will pg_start_backup() throw an error if I call it now", or
    "do I need to call pg_stop_backup()", then the current behavior is correct.

    The manual says:
    pg_is_in_backup() bool True if an on-line exclusive backup is still in progress.
    So clearly that is intentional. That could use some rephrasing, though;
    a layman won't know what an "exclusive backup" is.

    - Heikki
  • Alvaro Herrera at May 31, 2013 at 7:56 pm

    Heikki Linnakangas wrote:

    The manual says:
    pg_is_in_backup() bool True if an on-line exclusive backup is still in progress.
    So clearly that is intentional. That could use some rephrasing,
    though; a layman won't know what an "exclusive backup" is.
    Heck, I don't understand what it is either.

    --
    Álvaro Herrera http://www.2ndQuadrant.com/
    PostgreSQL Development, 24x7 Support, Training & Services
  • Michael Paquier at Jun 1, 2013 at 8:06 am

    On Sat, Jun 1, 2013 at 4:55 AM, Alvaro Herrera wrote:

    Heikki Linnakangas wrote:
    The manual says:
    pg_is_in_backup() bool True if an on-line exclusive backup is
    still in progress.
    So clearly that is intentional. That could use some rephrasing,
    though; a layman won't know what an "exclusive backup" is.
    Heck, I don't understand what it is either.
    Same here. Does it mean taking a backup not with pg_basebackup but by
    executing yourself external operations between pg_start/stop_backup calls?
    --
    Michael
  • Andres Freund at Jun 1, 2013 at 8:21 am

    On 2013-06-01 17:05:57 +0900, Michael Paquier wrote:
    On Sat, Jun 1, 2013 at 4:55 AM, Alvaro Herrera wrote:

    Heikki Linnakangas wrote:
    The manual says:
    pg_is_in_backup() bool True if an on-line exclusive backup is
    still in progress.
    So clearly that is intentional. That could use some rephrasing,
    though; a layman won't know what an "exclusive backup" is.
    Heck, I don't understand what it is either.
    Same here. Does it mean taking a backup not with pg_basebackup but by
    executing yourself external operations between pg_start/stop_backup calls?
    Basically yes. pg_start/stop_backup places the backup label into the data
    directory itself so there can only be one of them at a time since it has
    to have a fixed name. With the streaming protocol the backup label is
    only added to the streamed data, so there can be multiple ones at the
    same time.

    Greetings,

    Andres Freund

    --
      Andres Freund http://www.2ndQuadrant.com/
      PostgreSQL Development, 24x7 Support, Training & Services
  • Andres Freund at May 31, 2013 at 8:06 pm

    On 2013-05-31 22:53:14 +0300, Heikki Linnakangas wrote:
    On 31.05.2013 22:36, Andres Freund wrote:
    On 2013-05-31 22:29:45 +0300, Heikki Linnakangas wrote:
    Note that pg_is_in_backup() just checks for presence of
    $PGDATA/backup_label. Also note that pg_basebackup doesn't create
    backup_label in the server. It's included in the backup that's sent to the
    client, but it's never written to disk in the server. So checking for
    backup_label manually or with pg_is_in_backup() will return false even if
    pg_basebackup is running.
    Whoa. You are right, but I'd call that a bug. I don't understand why we
    aren't just checking
    XLogCtl->Insert.(nonExclusiveBackups||exlusiveBackup)?
    Well, depends on what you imagine the function is used for. If you think of
    it as "will pg_start_backup() throw an error if I call it now", or "do I
    need to call pg_stop_backup()", then the current behavior is correct.

    The manual says:
    pg_is_in_backup() bool True if an on-line exclusive backup is still in progress.
    So clearly that is intentional.
    Well, just because it's intentional, doesn't mean its a good idea
    ;). There very well are reasons to check for in progress non-exclusive
    backups as well. You e.g. wouldn't want to restart the database while
    the weekly base backup of your 1TB database is in progress, just because
    it's done via the replication protocol.

    If we weren't in beta 1 already I'd vote for making it into:
    pg_backup_in_progress(OUT bool exclusive, OUT int non_exclusive) or
    similar. Perhaps we should do that anyway?
    That could use some rephrasing, though; a layman won't know what an
    "exclusive backup" is.
    True. Although I have to admit I can't come up with a succinct name for
    it it right now.

    Greetings,

    Andres Freund

    --
      Andres Freund http://www.2ndQuadrant.com/
      PostgreSQL Development, 24x7 Support, Training & Services
  • Simon Riggs at Jun 1, 2013 at 1:51 pm

    On 31 May 2013 21:06, Andres Freund wrote:
    On 2013-05-31 22:53:14 +0300, Heikki Linnakangas wrote:
    On 31.05.2013 22:36, Andres Freund wrote:
    On 2013-05-31 22:29:45 +0300, Heikki Linnakangas wrote:
    Note that pg_is_in_backup() just checks for presence of
    $PGDATA/backup_label. Also note that pg_basebackup doesn't create
    backup_label in the server. It's included in the backup that's sent to the
    client, but it's never written to disk in the server. So checking for
    backup_label manually or with pg_is_in_backup() will return false even if
    pg_basebackup is running.
    Whoa. You are right, but I'd call that a bug. I don't understand why we
    aren't just checking
    XLogCtl->Insert.(nonExclusiveBackups||exlusiveBackup)?
    Well, depends on what you imagine the function is used for. If you think of
    it as "will pg_start_backup() throw an error if I call it now", or "do I
    need to call pg_stop_backup()", then the current behavior is correct.

    The manual says:
    pg_is_in_backup() bool True if an on-line exclusive backup is still in progress.
    So clearly that is intentional.
    Well, just because it's intentional, doesn't mean its a good idea
    ;). There very well are reasons to check for in progress non-exclusive
    backups as well. You e.g. wouldn't want to restart the database while
    the weekly base backup of your 1TB database is in progress, just because
    it's done via the replication protocol.

    If we weren't in beta 1 already I'd vote for making it into:
    pg_backup_in_progress(OUT bool exclusive, OUT int non_exclusive) or
    similar. Perhaps we should do that anyway?
    That could use some rephrasing, though; a layman won't know what an
    "exclusive backup" is.
    True. Although I have to admit I can't come up with a succinct name for
    it it right now.
    I see that this exact discussion has happened once before, after the
    initial commit.

    AFAICS nobody likes the fact that pg_is_in_backup() only covers
    exclusive backups. The problem seems to be that we can't find a better
    term.

    But the problem remains that having a function called
    pg_is_in_backup() that *clearly* does *not* do what it says, is a
    problem. Yes, few people will understand what an exclusive backup is,
    but that is a very good reason to not split hairs in the definition.

    The way to resolve this is to have two functions:

      pg_is_in_backup() - which covers both/all kinds of backup
      pg_is_in_exclusive_backup() - which covers just the exclusive backup mode

    and some clear documentation that explains why the two functions are necessary.

    Any objections to me committing those changes?

    --
      Simon Riggs http://www.2ndQuadrant.com/
      PostgreSQL Development, 24x7 Support, Training & Services
  • Tom Lane at Jun 1, 2013 at 2:45 pm

    Simon Riggs writes:
    The way to resolve this is to have two functions:
    pg_is_in_backup() - which covers both/all kinds of backup
    pg_is_in_exclusive_backup() - which covers just the exclusive backup mode
    What will you do with pg_backup_start_time()?

        regards, tom lane
  • Simon Riggs at Jun 1, 2013 at 6:11 pm

    On 1 June 2013 15:45, Tom Lane wrote:
    Simon Riggs <simon@2ndquadrant.com> writes:
    The way to resolve this is to have two functions:
    pg_is_in_backup() - which covers both/all kinds of backup
    pg_is_in_exclusive_backup() - which covers just the exclusive backup mode
    What will you do with pg_backup_start_time()?
    Hmm, at least all of those functions use the "backup" name
    consistently. I guess I wasn't suggesting we rename pg_start_backup()
    to pg_start_exclusive_backup(), so maybe it makes sense.

    pg_start_backup() talks about an online backup, while
    pg_is_in_backup() talks about an exclusive backup. Minimum change here
    would be to make pg_start_backup talk about an exclusive backup also.

    What we need is a function that says whether it is possible to
    shutdown because of a backup, or not. pg_basebackup is an active task,
    whereas an exclusive backup never is. So we need a function to tell us
    that although nothing else is running, but we are running an exclusive
    backup. So changing pg_is_in_backup() to refer to all kinds of backup
    still allows it to be used for its primary purpose - to tell whether
    its OK to shutdown or not, but it also makes it clearer.

    --
      Simon Riggs http://www.2ndQuadrant.com/
      PostgreSQL Development, 24x7 Support, Training & Services
  • Christoph Moench-Tegeder at Jun 1, 2013 at 9:43 am

    ## Joe Conway (mail@joeconway.com):

    However there is a period of time after pg_start_backup() is first
    executed to when it completes, during which backup_label file does not
    exist yet, but the backup has essentially been started. Is there any
    way to detect this state?
    When I did some research on the very same question just a few weeks
    ago, I settled for external locks (lockfile, pg_advisory_lock(), ...,
    depending on your exact situation) around the backup-taking code.

    Regards,
    Christoph

    --
    Spare Space
  • Joe Conway at Jun 1, 2013 at 3:11 pm

    On 06/01/2013 02:43 AM, Christoph Moench-Tegeder wrote:
    ## Joe Conway (mail@joeconway.com):
    However there is a period of time after pg_start_backup() is
    first executed to when it completes, during which backup_label
    file does not exist yet, but the backup has essentially been
    started. Is there any way to detect this state?
    When I did some research on the very same question just a few
    weeks ago, I settled for external locks (lockfile,
    pg_advisory_lock(), ..., depending on your exact situation) around
    the backup-taking code.
    Right, and an external lockfile is good except there is a race condition.

    Proc1, t0) SELECT pg_start_backup(...) -- command starts to execute

    Proc2, t1) lay down a lockfile (or other mechanism)

    Proc2, t2) check for running backup by looking for backup_label

    Proc1, t3) SELECT pg_start_backup(...) -- command finishes,
                                            -- backup_label created

    So you are forced to sleep for some arbitrary time just in case
    pg_start_backup() has started but not completed at the point when you
    try to lock out the backup.

    Or better (at least my solution), is you check pg_stat_activity for
    the presence of a running "SELECT pg_start_backup(...)" command prior
    to checking for backup_label. I imagine there is still a small race
    condition there but at least much smaller.


    Joe

    - --
    Joe Conway
    credativ LLC: http://www.credativ.us
    Linux, PostgreSQL, and general Open Source
    Training, Service, Consulting, & 24x7 Support
  • Andres Freund at Jun 1, 2013 at 3:14 pm

    On 2013-06-01 08:11:26 -0700, Joe Conway wrote:
    -----BEGIN PGP SIGNED MESSAGE-----
    Hash: SHA1
    On 06/01/2013 02:43 AM, Christoph Moench-Tegeder wrote:
    ## Joe Conway (mail@joeconway.com):
    However there is a period of time after pg_start_backup() is
    first executed to when it completes, during which backup_label
    file does not exist yet, but the backup has essentially been
    started. Is there any way to detect this state?
    When I did some research on the very same question just a few
    weeks ago, I settled for external locks (lockfile,
    pg_advisory_lock(), ..., depending on your exact situation) around
    the backup-taking code.
    Right, and an external lockfile is good except there is a race condition.

    Proc1, t0) SELECT pg_start_backup(...) -- command starts to execute

    Proc2, t1) lay down a lockfile (or other mechanism)

    Proc2, t2) check for running backup by looking for backup_label

    Proc1, t3) SELECT pg_start_backup(...) -- command finishes,
    -- backup_label created

    So you are forced to sleep for some arbitrary time just in case
    pg_start_backup() has started but not completed at the point when you
    try to lock out the backup.
    Uh. Why would you do the lock(file) thingy *after* calling
    pg_start_backup? You should do lock before calling start backup and
    remove the lock after calling stop backup. In that case I don't see
    where the race condition is?

    Greetings,

    Andres Freund

    --
      Andres Freund http://www.2ndQuadrant.com/
      PostgreSQL Development, 24x7 Support, Training & Services
  • Joe Conway at Jun 1, 2013 at 3:27 pm

    On 06/01/2013 08:14 AM, Andres Freund wrote:
    On 2013-06-01 08:11:26 -0700, Joe Conway wrote:
    -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
    On 06/01/2013 02:43 AM, Christoph Moench-Tegeder wrote:
    ## Joe Conway (mail@joeconway.com):
    However there is a period of time after pg_start_backup() is
    first executed to when it completes, during which
    backup_label file does not exist yet, but the backup has
    essentially been started. Is there any way to detect this
    state?
    When I did some research on the very same question just a few
    weeks ago, I settled for external locks (lockfile,
    pg_advisory_lock(), ..., depending on your exact situation)
    around the backup-taking code.
    Right, and an external lockfile is good except there is a race
    condition.

    Proc1, t0) SELECT pg_start_backup(...) -- command starts to
    execute

    Proc2, t1) lay down a lockfile (or other mechanism)

    Proc2, t2) check for running backup by looking for backup_label

    Proc1, t3) SELECT pg_start_backup(...) -- command finishes, --
    backup_label created

    So you are forced to sleep for some arbitrary time just in case
    pg_start_backup() has started but not completed at the point when
    you try to lock out the backup.
    Uh. Why would you do the lock(file) thingy *after* calling
    pg_start_backup? You should do lock before calling start backup
    and remove the lock after calling stop backup. In that case I don't
    see where the race condition is?
    No, the point is I have no control over Proc1. I am trying to prevent
    Proc2 from running concurrently with a binary backup (Proc1). So I
    need to lock out Proc1, or detect it is running and wait for it to finish.

    The problem is that in between t0 and t3 there is no good way to
    determine that Proc1 has started its backup because backup_label does
    not yet exist, and there is no other evidence besides pg_stat_activity
    (which as I said is better than nothing but probably not perfect).

    Joe


    - --
    Joe Conway
    credativ LLC: http://www.credativ.us
    Linux, PostgreSQL, and general Open Source
    Training, Service, Consulting, & 24x7 Support
  • Andres Freund at Jun 1, 2013 at 3:31 pm

    On 2013-06-01 08:27:42 -0700, Joe Conway wrote:
    Uh. Why would you do the lock(file) thingy *after* calling
    pg_start_backup? You should do lock before calling start backup
    and remove the lock after calling stop backup. In that case I don't
    see where the race condition is?
    No, the point is I have no control over Proc1. I am trying to prevent
    Proc2 from running concurrently with a binary backup (Proc1). So I
    need to lock out Proc1, or detect it is running and wait for it to finish.
    Backups over which you don't have control sound a bit scary ;). I think
    at that point you have a race condition no matter what since the backup
    could be started between your check and when you call pg_start_backup
    anyay. So just calling pg_start_backup and handling the error properly
    sounds like the way to go in that case.

    Andres
    --
      Andres Freund http://www.2ndQuadrant.com/
      PostgreSQL Development, 24x7 Support, Training & Services

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
grouppgsql-hackers @
categoriespostgresql
postedMay 31, '13 at 5:39p
activeJun 1, '13 at 6:11p
posts23
users9
websitepostgresql.org...
irc#postgresql

People

Translate

site design / logo © 2021 Grokbase