Skip site navigation (1) Skip section navigation (2)

Re: register/unregister standby Re: Synchronous replication

From: Itagaki Takahiro <itagaki(dot)takahiro(at)gmail(dot)com>
To: Dimitri Fontaine <dfontaine(at)hi-media(dot)com>
Cc: Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>, Fujii Masao <masao(dot)fujii(at)gmail(dot)com>, Joshua Tolley <eggyknap(at)gmail(dot)com>, Yeb Havinga <yebhavinga(at)gmail(dot)com>, Aidan Van Dyk <aidan(at)highrise(dot)ca>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: register/unregister standby Re: Synchronous replication
Date: 2010-09-02 11:10:33
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
On Thu, Sep 2, 2010 at 7:54 PM, Dimitri Fontaine <dfontaine(at)hi-media(dot)com> wrote:
>> One issue of the base backup function is that the operation will
>> be a long transaction. So, non-transactional special commands,
>> as like as VACUUM, would be better in terms of performance.
> Well, you still need to stream the data to the client in a format it
> will understand.

True, but using libpq connection might be not the most important thing.
The most simplest proof-of-concept might be system("rsync") in the function ;-)

> Would that be the plan of your command proposal?

What I meant was function-based maintenance does not work well in some
cases. I heard before pg_start_backup( no-fast-checkpoint ) caused table
bloating problem because it was a long transaction for 20+ minutes.
The backup function would have the similar issue.

Itagaki Takahiro

In response to

pgsql-hackers by date

Next:From: Simon RiggsDate: 2010-09-02 12:03:38
Subject: Re: Synchronous replication - patch status inquiry
Previous:From: Dimitri FontaineDate: 2010-09-02 10:54:52
Subject: Re: register/unregister standby Re: Synchronous replication

Privacy Policy | About PostgreSQL
Copyright © 1996-2018 The PostgreSQL Global Development Group