Re: [Postgres-xc-developers] Patch to lock cluster

[Nikhil S. <ni...@st...>]

Hi Abbas,

What is exactly meant by locking the cluster here?

Do we disallow DDL during this phase? Do we allow only SELECT queries
in this phase? Am sorry, if I missed any earlier discussion on this.
How is the backup consistent in this phase?

Regards,
Nikhils

On Tue, Feb 19, 2013 at 12:37 PM, Abbas Butt
<abb...@en...> wrote:
> Hi,
> Attached please find a patch that locks the cluster so that dump can be
> taken to be restored on the new node to be added.
>
> To lock the cluster the patch adds a new GUC parameter called
> xc_lock_for_backup, however its status is maintained by the pooler. The
> reason is that the default behavior of XC is to release connections as soon
> as a command is done and it uses PersistentConnections GUC to control the
> behavior. We in this case however need a status that is independent of the
> setting of PersistentConnections.
>
> Assume we have two coordinator cluster, the patch provides this behavior:
>
> Case 1: set and show
> ====================
> psql test -p 5432
> set xc_lock_for_backup=yes;
> show xc_lock_for_backup;
>  xc_lock_for_backup
> --------------------
>  yes
> (1 row)
>
> Case 2: set from one client show from other
> ==================================
> psql test -p 5432
> set xc_lock_for_backup=yes;
> (From another tab)
> psql test -p 5432
> show xc_lock_for_backup;
>  xc_lock_for_backup
> --------------------
>  yes
> (1 row)
>
> Case 3: set from one, quit it, run again and show
> ======================================
> psql test -p 5432
> set xc_lock_for_backup=yes;
> \q
> psql test -p 5432
> show xc_lock_for_backup;
>  xc_lock_for_backup
> --------------------
>  yes
> (1 row)
>
> Case 4: set on one coordinator, show from other
> =====================================
> psql test -p 5432
> set xc_lock_for_backup=yes;
> (From another tab)
> psql test -p 5433
> show xc_lock_for_backup;
>  xc_lock_for_backup
> --------------------
>  yes
> (1 row)
>
> pg_dump and pg_dumpall seem to work fine after locking the cluster for
> backup but I would test these utilities in detail next.
>
> Also I have yet to look in detail that standard_ProcessUtility is the only
> place that updates the portion of catalog that is dumped. There may be some
> other places too that need to be blocked for catalog updates.
>
> The patch adds no extra warnings and regression shows no extra failure.
>
> Comments are welcome.
>
> --
> Abbas
> Architect
> EnterpriseDB Corporation
> The Enterprise PostgreSQL Company
>
> Phone: 92-334-5100153
>
> Website: www.enterprisedb.com
> EnterpriseDB Blog: http://blogs.enterprisedb.com/
> Follow us on Twitter: http://www.twitter.com/enterprisedb
>
> This e-mail message (and any attachment) is intended for the use of
> the individual or entity to whom it is addressed. This message
> contains information from EnterpriseDB Corporation that may be
> privileged, confidential, or exempt from disclosure under applicable
> law. If you are not the intended recipient or authorized to receive
> this for the intended recipient, any use, dissemination, distribution,
> retention, archiving, or copying of this communication is strictly
> prohibited. If you have received this e-mail in error, please notify
> the sender immediately by reply e-mail and delete this message.
> ------------------------------------------------------------------------------
> Everyone hates slow websites. So do we.
> Make your web apps faster with AppDynamics
> Download AppDynamics Lite for free today:
> http://p.sf.net/sfu/appdyn_d2d_feb
> _______________________________________________
> Postgres-xc-developers mailing list
> Pos...@li...
> https://lists.sourceforge.net/lists/listinfo/postgres-xc-developers
>



-- 
StormDB - http://www.stormdb.com
The Database Cloud
Postgres-XC Support and Service