From: | Andreas Berger <4postgres(at)gmail(dot)com> |
---|---|
To: | tgl(at)sss(dot)pgh(dot)pa(dot)us, pgsql-admin(at)postgresql(dot)org |
Subject: | Re: alter table without an ACCESS EXCLUSIVE lock |
Date: | 2011-06-17 09:59:44 |
Message-ID: | BANLkTikh0czdScJ2mKR7XPYZkregdinfOA@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-admin |
Thanks for your answer!
In this spacial case your suggestion is a solution, but I am searching
for an opportunity to make every change (e.g. alter table) without
effecting availability of the database and the modified table when using
wal shipping (maybe something like concurrently when creating an index).
When using skytools I can keep the downtime minimal by doing a master
slave change after modifying the slave db. But the question now is, is
it possible to use wal shipping without having downtimes when modifying
tables?
regards,
Andi
On 2011-06-16 20:21, Tom Lane wrote:
> Andreas Berger <4postgres(at)gmail(dot)com> <4postgres(at)gmail(dot)com> writes:
>> i'm searching for a solution for changing the type of a column, e.g. from>> varchar(128) to varchar(512), without an ACCESS EXCLUSIVE lock.
> > That specific case (increasing the max length of a varchar column) could> be handled by hacking the pg_attribute.atttypmod entry for the column,> since no change in the actual data is required.> > However, I have no idea whether your replication environment would cope> with such a change --- experimenting on a non-production setup would be> highly recommendable.> > regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Nicolas Thauvin | 2011-06-17 13:23:44 | Re: pg_dump and drop table if exists statement |
Previous Message | Andreas Pötzlberger | 2011-06-17 08:50:00 | Re: alter table without an ACCESS EXCLUSIVE lock |