Skip site navigation (1) Skip section navigation (2)

Re: Future In-Core Replication

From: Simon Riggs <simon(at)2ndQuadrant(dot)com>
To: Hannu Krosing <hannu(at)2ndquadrant(dot)com>
Cc: Christopher Browne <cbbrowne(at)gmail(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Future In-Core Replication
Date: 2012-04-29 17:28:49
Message-ID: CA+U5nM+MXF-8s17vRFQbcQZ+Q0HTM3sbrF7u23Uu86HUtxfFYg@mail.gmail.com (view raw or flat)
Thread:
Lists: pgsql-hackers
On Sun, Apr 29, 2012 at 6:20 PM, Hannu Krosing <hannu(at)2ndquadrant(dot)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(at)krosing(dot)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

In response to

pgsql-hackers by date

Next:From: Simon RiggsDate: 2012-04-29 17:33:00
Subject: Re: default_transaction_isolation = serializable causes crash under Hot Standby
Previous:From: Simon RiggsDate: 2012-04-29 17:26:53
Subject: Re: smart shutdown at end of transaction (was: Default mode for shutdown)

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group