Hi,
On 2013-10-22 16:07:16 +0200, Andres Freund wrote:
On 2013-10-21 20:16:29 +0200, Andres Freund wrote:
Current draft is:
ALTER TABLE ... REPLICA IDENTITY NOTHING|FULL|DEFAULT
ALTER TABLE ... REPLICA IDENTITY USING INDEX ...;
which leaves the door open for
ALTER TABLE ...
On Fri, Oct 25, 2013 at 10:58 AM, Andres Freund and...@2ndquadrant.com wrote:
So, I am currently wondering about how to store the old tuple, based
on this. Currently it is stored using the TupleDesc of the index the old
tuple is based on. But if we want to allow transporting the entire tuple
On Tue, Oct 22, 2013 at 10:07 AM, Andres Freund and...@2ndquadrant.com wrote:
On 2013-10-21 20:16:29 +0200, Andres Freund wrote:
On 2013-10-18 20:50:58 +0200, Andres Freund wrote:
How about modifying the selection to go from:
* all rows if ALTER TABLE ... REPLICA IDENTITY NOTHING|FULL;
*
On Fri, Oct 18, 2013 at 2:50 PM, Andres Freund and...@2ndquadrant.com wrote:
How about modifying the selection to go from:
* all rows if ALTER TABLE ... REPLICA IDENTITY NOTHING|FULL;
* index chosen by ALTER TABLE ... REPLICA IDENTITY USING indexname
* [later, maybe] ALTER TABLE ... REPLICA
On 2013-10-21 09:40:13 -0400, Robert Haas wrote:
On Fri, Oct 18, 2013 at 2:50 PM, Andres Freund and...@2ndquadrant.com wrote:
How about modifying the selection to go from:
* all rows if ALTER TABLE ... REPLICA IDENTITY NOTHING|FULL;
* index chosen by ALTER TABLE ... REPLICA IDENTITY USING
On 10/18/2013 08:50 PM, Andres Freund wrote:
On 2013-10-18 08:11:29 -0400, Robert Haas wrote:
...
2. If that seems too complicated, how about just logging the whole old
tuple for version 1?
I think that'd make the patch much less useful because it bloats WAL
unnecessarily for the primary user
On 2013-10-21 16:40:43 +0200, Hannu Krosing wrote:
On 10/18/2013 08:50 PM, Andres Freund wrote:
On 2013-10-18 08:11:29 -0400, Robert Haas wrote:
...
2. If that seems too complicated, how about just logging the whole old
tuple for version 1?
I think that'd make the patch much less useful
On Mon, Oct 21, 2013 at 9:51 AM, Andres Freund and...@2ndquadrant.com wrote:
I have a hard time to understand why you dislike it so much. Think of a
big schema where you want to add auditing via changeset
extraction. Because of problems with reindexing primary key you've just
used candidate
On 2013-10-21 11:14:37 -0400, Robert Haas wrote:
On Mon, Oct 21, 2013 at 9:51 AM, Andres Freund and...@2ndquadrant.com wrote:
I have a hard time to understand why you dislike it so much. Think of a
big schema where you want to add auditing via changeset
extraction. Because of problems with
On 10/21/2013 05:06 PM, Andres Freund wrote:
On 2013-10-21 16:40:43 +0200, Hannu Krosing wrote:
On 10/18/2013 08:50 PM, Andres Freund wrote:
On 2013-10-18 08:11:29 -0400, Robert Haas wrote:
...
2. If that seems too complicated, how about just logging the whole old
tuple for version 1?
I
On 2013-10-18 20:50:58 +0200, Andres Freund wrote:
How about modifying the selection to go from:
* all rows if ALTER TABLE ... REPLICA IDENTITY NOTHING|FULL;
* index chosen by ALTER TABLE ... REPLICA IDENTITY USING indexname
* [later, maybe] ALTER TABLE ... REPLICA IDENTITY (cola, colb)
On Mon, Oct 14, 2013 at 9:12 AM, Andres Freund and...@2ndquadrant.com wrote:
Attached you can find version 6.4 of the patchset:
So I'm still unhappy with the arbitrary logic in what's now patch 1
for choosing the candidate key. On another thread, someone mentioned
that they might want the
On Fri, Oct 18, 2013 at 7:11 AM, Robert Haas robertmh...@gmail.com wrote:
On Mon, Oct 14, 2013 at 9:12 AM, Andres Freund and...@2ndquadrant.com wrote:
Attached you can find version 6.4 of the patchset:
So I'm still unhappy with the arbitrary logic in what's now patch 1
for choosing the
On 2013-10-18 08:11:29 -0400, Robert Haas wrote:
On Mon, Oct 14, 2013 at 9:12 AM, Andres Freund and...@2ndquadrant.com wrote:
Attached you can find version 6.4 of the patchset:
So I'm still unhappy with the arbitrary logic in what's now patch 1
for choosing the candidate key. On another
14 matches
Mail list logo
