Received: from localhost (unknown [200.46.204.184]) by developer.postgresql.org (Postfix) with ESMTP id 0DCD92E0033 for ; Tue, 29 Apr 2008 01:55:16 -0300 (ADT) Received: from developer.postgresql.org ([200.46.204.71]) by localhost (mx1.hub.org [200.46.204.184]) (amavisd-maia, port 10024) with ESMTP id 31283-03 for ; Tue, 29 Apr 2008 01:55:10 -0300 (ADT) X-Greylist: domain auto-whitelisted by SQLgrey-1.7.5 Received: from wa-out-1112.google.com (wa-out-1112.google.com [209.85.146.182]) by developer.postgresql.org (Postfix) with ESMTP id CEB4E2E0032 for ; Tue, 29 Apr 2008 01:55:11 -0300 (ADT) Received: by wa-out-1112.google.com with SMTP id n7so8583909wag.5 for ; Mon, 28 Apr 2008 21:55:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; bh=Pa7Gpc8LEAbsXu4wXevO7NmlW7/A7JoJtIKcDT0bxZI=; b=dyBPCg9hKYyx6adf5PBvOpPREmgLZuDnw4ljs/vda4l3gNtFs9U1kq6LxMC8xqHeqjKk81jnO7jdUESPTBc/YNv8C24hYWrEfPMEH7qU81PVNSEuo/CTwi4fV1S6CPluAT9hB+x4Aiy1yZI6Svf/CjIVBGDEZoB8RQ9H+7Rmtt4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=D76ZS1VVN5xsBX8AC7ZH3Noxh1C4pKAmyTvXbzoaoxQCw4smBZisuQkAthifz8FBuHsnTdDks860puovaoGv1XDv48c7wCsiVnCWkhy0BD3dyYQ0WTVhp1XQvTGPMFn/If7AGxNhbDOk7o9ZveyV1iu75AgaRiHb5TBTMif098Y= Received: by 10.114.205.1 with SMTP id c1mr7462803wag.211.1209444910517; Mon, 28 Apr 2008 21:55:10 -0700 (PDT) Received: by 10.114.240.17 with HTTP; Mon, 28 Apr 2008 21:55:10 -0700 (PDT) Message-ID: <7e4ba9550804282155u655e3ab5o38d2e659b485530d@mail.gmail.com> Date: Tue, 29 Apr 2008 10:25:10 +0530 From: "Gauri Kanekar" To: "Chris Browne" Subject: Re: Replication Syatem Cc: pgsql-performance@postgresql.org In-Reply-To: <60wsmh64f6.fsf@dba2.int.libertyrms.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_10418_6654278.1209444910506" References: <7e4ba9550804280638ie81dc23w472785c83cd38fcf@mail.gmail.com> <60wsmh64f6.fsf@dba2.int.libertyrms.com> X-Virus-Scanned: Maia Mailguard 1.0.1 X-Spam-Status: No, hits=1.9 tagged_above=0 required=5 tests=FS_REPLICA=1.179, HTML_MESSAGE=0.001, SARE_SPEC_REPLICA=0.72 X-Spam-Level: * X-Archive-Number: 200804/420 X-Sequence-Number: 29913 ------=_Part_10418_6654278.1209444910506 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Basically we have some background process which updates "table1" and we don't want the application to make any changes to "table1" while vacuum. Vacuum requires exclusive lock on "table1" and if any of the background or application is ON vacuum don't kick off. Thats the reason we need to get the site down. ~ Gauri On Tue, Apr 29, 2008 at 3:13 AM, Chris Browne wrote: > meetgaurikanekar@gmail.com ("Gauri Kanekar") writes: > > We have a table "table1" which get insert and updates daily in high > > numbers, bcoz of which its size is increasing and we have to vacuum > > it every alternate day. Vacuuming "table1" take almost 30min and > > during that time the site is down. We need to cut down on this > > downtime.So thought of having a replication system, for which the > > replicated DB will be up during the master is getting vacuumed. Can > > anybody guide which will be the best suited replication solution for > > this. > > The only reason that it would be necessary for VACUUM to "take the > site down" would be if you are running version 7.1, which was > obsoleted in 2002, which, it should be noted, was SIX YEARS AGO. > > As has been noted, you seem to be presupposing a remarkably complex > solution to resolve a problem which is likely to be better handled via > running VACUUM rather more frequently. > -- > output = reverse("ofni.sesabatadxunil" "@" "enworbbc") > http://www3.sympatico.ca/cbbrowne/postgresql.html > Rules of the Evil Overlord #181. "I will decree that all hay be > shipped in tightly-packed bales. Any wagonload of loose hay attempting > to pass through a checkpoint will be set on fire." > > > -- > Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org) > To make changes to your subscription: > http://www.postgresql.org/mailpref/pgsql-performance > -- Regards Gauri ------=_Part_10418_6654278.1209444910506 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline
Basically we have some background process which updates "table1" and we don't want the application to make any changes to "table1" while vacuum.

Vacuum requires exclusive lock on "table1" and if any of the background or application is ON vacuum don't kick off. Thats the reason we need to get the site down.

~ Gauri

On Tue, Apr 29, 2008 at 3:13 AM, Chris Browne <cbbrowne@acm.org> wrote:
meetgaurikanekar@gmail.com ("Gauri Kanekar") writes:
> We have a table "table1" which get insert and updates daily in high
> numbers, bcoz of which its size is increasing and we have to vacuum
> it every alternate day. Vacuuming "table1" take almost 30min and
> during that time the site is down.  We need to cut down on this
> downtime.So thought of having a replication system, for which the
> replicated DB will be up during the master is getting vacuumed.  Can
> anybody guide which will be the best suited replication solution for
> this.

The only reason that it would be necessary for VACUUM to "take the
site down" would be if you are running version 7.1, which was
obsoleted in 2002, which, it should be noted, was SIX YEARS AGO.

As has been noted, you seem to be presupposing a remarkably complex
solution to resolve a problem which is likely to be better handled via
running VACUUM rather more frequently.
--
output = reverse("ofni.sesabatadxunil" "@" "enworbbc")
http://www3.sympatico.ca/cbbrowne/postgresql.html
Rules  of the  Evil Overlord  #181.  "I  will decree  that all  hay be
shipped in tightly-packed bales. Any wagonload of loose hay attempting
to pass through a checkpoint will be set on fire."
<http://www.eviloverlord.com/>

--
Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-performance



--
Regards
Gauri ------=_Part_10418_6654278.1209444910506--