Re: Future In-Core Replication

From: Hannu Krosing <hannu(at)2ndQuadrant(dot)com>
To: Simon Riggs <simon(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:20:00
Message-ID: 1335720000.3919.63.camel@hvost
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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 :)

--
-------
Hannu Krosing
PostgreSQL Unlimited Scalability and Performance Consultant
2ndQuadrant Nordic
PG Admin Book: http://www.2ndQuadrant.com/books/

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Simon Riggs 2012-04-29 17:26:53 Re: smart shutdown at end of transaction (was: Default mode for shutdown)
Previous Message Simon Riggs 2012-04-29 17:02:47 Re: Re: xReader, double-effort (was: Temporary tables under hot standby)