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 :)
--
-------
Hannu Krosing
PostgreSQL Unlimited Scalability and Performance Consultant
2ndQuadrant Nordic
PG Admin Book: http://www.2ndQuadrant.com/books/