Re: replicating DROP commands across servers

From: Heikki Linnakangas <hlinnakangas(at)vmware(dot)com>
To: "Brightwell, Adam" <adam(dot)brightwell(at)crunchydatasolutions(dot)com>, "Alvaro Herrera" <alvherre(at)2ndquadrant(dot)com>
Cc: Andres Freund <andres(at)2ndquadrant(dot)com>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: replicating DROP commands across servers
Date: 2014-10-03 16:07:07
Message-ID: 542EC9AB.2080908@vmware.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 09/16/2014 09:09 PM, Brightwell, Adam wrote:
>>
>>> I think there's been some changes to this patch since july, care to
>>> resend a new version?
>>
>> Sure, here it is.
>>
>> The only difference with the previous version is that it now also
>> supports column defaults. This was found to be a problem when you drop
>> a sequence that some column default depends on -- for example a column
>> declared SERIAL, or a sequence marked with ALTER SEQUENCE OWNED BY. The
>> new code is able to drop both the sequence and the default value
>> (leaving, of course, the rest of the column intact.) This required
>> adding support for such objects in get_object_address.
>
>
> I have given this patch the following review:
>
> - Apply to current master (77e65bf). -- success
> - check-world. --success
> - multiple FIXME statements still exist -- are there plans to fix these
> items? Can the duplicated code be extracted to a static function?

Nothing seems to be happening to this, so I'm marking this as returned
with feedback.

- Heikki

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Marco Nenciarini 2014-10-03 16:08:47 Re: [RFC] Incremental backup v2: add backup profile to base backup
Previous Message Alvaro Herrera 2014-10-03 16:06:33 Re: Per table autovacuum vacuum cost limit behaviour strange