Re: Future In-Core Replication - Mailing list pgsql-hackers

From Simon Riggs
Subject Re: Future In-Core Replication
Date
Msg-id CA+U5nM+MXF-8s17vRFQbcQZ+Q0HTM3sbrF7u23Uu86HUtxfFYg@mail.gmail.com
Whole thread Raw
In response to Re: Future In-Core Replication  (Hannu Krosing <hannu@2ndQuadrant.com>)
List pgsql-hackers
On Sun, Apr 29, 2012 at 6:20 PM, Hannu Krosing <hannu@2ndquadrant.com> wrote:
> On Sun, 2012-04-29 at 12:03 +0100, Simon Riggs wrote:
>> On Sat, Apr 28, 2012 at 8:40 PM, Hannu Krosing <hannu@krosing.net> wrote:
>>
>> > As to what LCRs should contain, it will probably be locical equivalents
>> > of INSERT, UPDATE ... LIMIT 1, DELETE ... LIMIT 1, TRUNCATE and all DDL.
>>
>> Yeh
>>
>> > I would even go as far as propose a variant for DML-WITH-LIMIT-1 to be
>> > added to postgresql's SQL syntax so that the LCRs could be converted to
>> > SQL text for some tasks and thus should be easy to process using generic
>> > text-based tools.
>> > The DML-WITH-LIMIT-1 is required to do single logical updates on tables
>> > with non-unique rows.
>> > And as for any logical updates we will have huge performance problem
>> > when doing UPDATE or DELETE on large table with no indexes, but
>> > fortunately this problem is on slave, not master ;)
>>
>> While that is possible, I would favour the do-nothing approach. By
>> making the default replication mode = none, we then require a PK to be
>> assigned before allowing replication mode = on for a table. Trying to
>> replicate tables without PKs is a problem that can wait basically.
>
> While this is a good approach in most cases, there is a large use case
> for pk-less / indexless tables in large logfiles, where you may want to
> do INSERT only replication, perhaps with some automatic partitioning on
> logdate. Allowing this is probably something to look at in the first
> release, even though I'm not sure wht would happen on violation of this
> insert-only policy.
> Should it
> * refuse to continue and rollback the transaction (probably not)
> * fail silently
> * succeed but log the change locally
> * succseed with some special flags so other side can treat it specially
> without having to look up stuff in system catalog
> * (if we mark the unique / pk fields in some special way anyway, then
> the previous one is free :)

OK, I think an insert-only replication mode would allow that.

--
 Simon Riggs                   http://www.2ndQuadrant.com/
 PostgreSQL Development, 24x7 Support, Training & Services


pgsql-hackers by date:

Previous
From: Simon Riggs
Date:
Subject: Re: smart shutdown at end of transaction (was: Default mode for shutdown)
Next
From: Simon Riggs
Date:
Subject: Re: default_transaction_isolation = serializable causes crash under Hot Standby