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.
>> > 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 Riggs||Date: 2012-04-29 17:33:00|
|Subject: Re: default_transaction_isolation = serializable causes
crash under Hot Standby|
|Previous:||From: Simon Riggs||Date: 2012-04-29 17:26:53|
|Subject: Re: smart shutdown at end of transaction (was: Default mode