ALTER TABLE SET STATISTICS requires AccessExclusiveLock
Is there a good reason for $subject, other than that the code is entangled
with other ALTER TABLE code?
The new SET DISTINCT might be equally affected.
Peter Eisentraut <peter_e@gmx.net> writes:
Is there a good reason for $subject, other than that the code is entangled
with other ALTER TABLE code?
I think it could be lower, but it would take nontrivial restructuring of
the ALTER TABLE support. In particular, consider what happens when you
have a list of subcommands that don't all require the same lock level.
I think you'd need to scan the list and find the highest required lock
level before starting ...
regards, tom lane
Tom Lane wrote:
Peter Eisentraut <peter_e@gmx.net> writes:
Is there a good reason for $subject, other than that the code is entangled
with other ALTER TABLE code?I think it could be lower, but it would take nontrivial restructuring of
the ALTER TABLE support. In particular, consider what happens when you
have a list of subcommands that don't all require the same lock level.
I think you'd need to scan the list and find the highest required lock
level before starting ...
IIRC there was a patch from Simon to address this issue, but it had some
holes which he didn't have time to close, so it sank. Maybe this can be
resurrected and fixed.
--
Alvaro Herrera http://www.CommandPrompt.com/
The PostgreSQL Company - Command Prompt, Inc.
On Fri, 2009-08-07 at 15:58 -0400, Alvaro Herrera wrote:
Tom Lane wrote:
Peter Eisentraut <peter_e@gmx.net> writes:
Is there a good reason for $subject, other than that the code is entangled
with other ALTER TABLE code?I think it could be lower, but it would take nontrivial restructuring of
the ALTER TABLE support. In particular, consider what happens when you
have a list of subcommands that don't all require the same lock level.
I think you'd need to scan the list and find the highest required lock
level before starting ...IIRC there was a patch from Simon to address this issue, but it had some
holes which he didn't have time to close, so it sank. Maybe this can be
resurrected and fixed.
I was intending to finish that patch in this release cycle.
MERGE needs further work if you are looking for a project. It isn't
immediately obvious but MERGE logic is a requirement for maintaining
materialized views, which is why I was working on that.
--
Simon Riggs www.2ndQuadrant.com
Simon Riggs wrote:
On Fri, 2009-08-07 at 15:58 -0400, Alvaro Herrera wrote:
Tom Lane wrote:
Peter Eisentraut <peter_e@gmx.net> writes:
Is there a good reason for $subject, other than that the code is entangled
with other ALTER TABLE code?I think it could be lower, but it would take nontrivial restructuring of
the ALTER TABLE support. In particular, consider what happens when you
have a list of subcommands that don't all require the same lock level.
I think you'd need to scan the list and find the highest required lock
level before starting ...IIRC there was a patch from Simon to address this issue, but it had some
holes which he didn't have time to close, so it sank. Maybe this can be
resurrected and fixed.I was intending to finish that patch in this release cycle.
Since you're busy with Hot Standby, any chance you could pass it on?
--
Alvaro Herrera http://www.CommandPrompt.com/
The PostgreSQL Company - Command Prompt, Inc.
On Mon, 2009-10-19 at 12:56 -0300, Alvaro Herrera wrote:
Simon Riggs wrote:
On Fri, 2009-08-07 at 15:58 -0400, Alvaro Herrera wrote:
Tom Lane wrote:
Peter Eisentraut <peter_e@gmx.net> writes:
Is there a good reason for $subject, other than that the code is entangled
with other ALTER TABLE code?I think it could be lower, but it would take nontrivial restructuring of
the ALTER TABLE support. In particular, consider what happens when you
have a list of subcommands that don't all require the same lock level.
I think you'd need to scan the list and find the highest required lock
level before starting ...IIRC there was a patch from Simon to address this issue, but it had some
holes which he didn't have time to close, so it sank. Maybe this can be
resurrected and fixed.I was intending to finish that patch in this release cycle.
Since you're busy with Hot Standby, any chance you could pass it on?
If you'd like. It's mostly finished, just one last thing to finish:
atomic changes to pg_class via an already agreed API.
--
Simon Riggs www.2ndQuadrant.com
Simon Riggs wrote:
On Mon, 2009-10-19 at 12:56 -0300, Alvaro Herrera wrote:
Simon Riggs wrote:
On Fri, 2009-08-07 at 15:58 -0400, Alvaro Herrera wrote:
Tom Lane wrote:
Peter Eisentraut <peter_e@gmx.net> writes:
Is there a good reason for $subject, other than that the code is entangled
with other ALTER TABLE code?I think it could be lower, but it would take nontrivial restructuring of
the ALTER TABLE support. In particular, consider what happens when you
have a list of subcommands that don't all require the same lock level.
I think you'd need to scan the list and find the highest required lock
level before starting ...IIRC there was a patch from Simon to address this issue, but it had some
holes which he didn't have time to close, so it sank. Maybe this can be
resurrected and fixed.I was intending to finish that patch in this release cycle.
Since you're busy with Hot Standby, any chance you could pass it on?
If you'd like. It's mostly finished, just one last thing to finish:
atomic changes to pg_class via an already agreed API.
I assume this did not get done for 9.0. Do we want a TODO item?
--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com
PG East: http://www.enterprisedb.com/community/nav-pg-east-2010.do
+ If your life is a hard drive, Christ can be your backup. +On mån, 2010-02-22 at 10:32 -0500, Bruce Momjian wrote:
Simon Riggs wrote:
On Mon, 2009-10-19 at 12:56 -0300, Alvaro Herrera wrote:
Simon Riggs wrote:
On Fri, 2009-08-07 at 15:58 -0400, Alvaro Herrera wrote:
Tom Lane wrote:
Peter Eisentraut <peter_e@gmx.net> writes:
Is there a good reason for $subject, other than that the code is entangled
with other ALTER TABLE code?I think it could be lower, but it would take nontrivial restructuring of
the ALTER TABLE support. In particular, consider what happens when you
have a list of subcommands that don't all require the same lock level.
I think you'd need to scan the list and find the highest required lock
level before starting ...IIRC there was a patch from Simon to address this issue, but it had some
holes which he didn't have time to close, so it sank. Maybe this can be
resurrected and fixed.I was intending to finish that patch in this release cycle.
Since you're busy with Hot Standby, any chance you could pass it on?
If you'd like. It's mostly finished, just one last thing to finish:
atomic changes to pg_class via an already agreed API.I assume this did not get done for 9.0. Do we want a TODO item?
Yes.
Peter Eisentraut wrote:
On m?n, 2010-02-22 at 10:32 -0500, Bruce Momjian wrote:
Simon Riggs wrote:
On Mon, 2009-10-19 at 12:56 -0300, Alvaro Herrera wrote:
Simon Riggs wrote:
On Fri, 2009-08-07 at 15:58 -0400, Alvaro Herrera wrote:
Tom Lane wrote:
Peter Eisentraut <peter_e@gmx.net> writes:
Is there a good reason for $subject, other than that the code is entangled
with other ALTER TABLE code?I think it could be lower, but it would take nontrivial restructuring of
the ALTER TABLE support. In particular, consider what happens when you
have a list of subcommands that don't all require the same lock level.
I think you'd need to scan the list and find the highest required lock
level before starting ...IIRC there was a patch from Simon to address this issue, but it had some
holes which he didn't have time to close, so it sank. Maybe this can be
resurrected and fixed.I was intending to finish that patch in this release cycle.
Since you're busy with Hot Standby, any chance you could pass it on?
If you'd like. It's mostly finished, just one last thing to finish:
atomic changes to pg_class via an already agreed API.I assume this did not get done for 9.0. Do we want a TODO item?
Yes.
Added:
Reduce locking required for ALTER commands
* http://archives.postgresql.org/pgsql-hackers/2009-08/msg00533.php
* http://archives.postgresql.org/pgsql-hackers/2009-10/msg01083.php
* http://archives.postgresql.org/pgsql-hackers/2010-01/msg02349.php
--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com
PG East: http://www.enterprisedb.com/community/nav-pg-east-2010.do
2010/3/3 Bruce Momjian <bruce@momjian.us>:
Peter Eisentraut wrote:
On m?n, 2010-02-22 at 10:32 -0500, Bruce Momjian wrote:
Simon Riggs wrote:
On Mon, 2009-10-19 at 12:56 -0300, Alvaro Herrera wrote:
Simon Riggs wrote:
On Fri, 2009-08-07 at 15:58 -0400, Alvaro Herrera wrote:
Tom Lane wrote:
Peter Eisentraut <peter_e@gmx.net> writes:
Is there a good reason for $subject, other than that the code is entangled
with other ALTER TABLE code?I think it could be lower, but it would take nontrivial restructuring of
the ALTER TABLE support. In particular, consider what happens when you
have a list of subcommands that don't all require the same lock level.
I think you'd need to scan the list and find the highest required lock
level before starting ...IIRC there was a patch from Simon to address this issue, but it had some
holes which he didn't have time to close, so it sank. Maybe this can be
resurrected and fixed.I was intending to finish that patch in this release cycle.
Since you're busy with Hot Standby, any chance you could pass it on?
If you'd like. It's mostly finished, just one last thing to finish:
atomic changes to pg_class via an already agreed API.I assume this did not get done for 9.0. Do we want a TODO item?
Yes.
Added:
Reduce locking required for ALTER commands
I just faced production issue where it is impossible to alter table to
adjust autovacuum settings in a pg8.4. (5K tps, 260M rows table, lock
too much)
Can we add some mechanism to prevent that situation also in the TODO item ?
(alternative is actualy to alter other tables and adjust the
postgresql.conf for biggest tables, but not an ideal solution anyway)
* http://archives.postgresql.org/pgsql-hackers/2009-08/msg00533.php
* http://archives.postgresql.org/pgsql-hackers/2009-10/msg01083.php
* http://archives.postgresql.org/pgsql-hackers/2010-01/msg02349.php--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.comPG East: http://www.enterprisedb.com/community/nav-pg-east-2010.do
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
--
Cédric Villemain 2ndQuadrant
http://2ndQuadrant.fr/ PostgreSQL : Expertise, Formation et Support
On 7/7/10 6:04 PM, Cédric Villemain wrote:
I just faced production issue where it is impossible to alter table to
adjust autovacuum settings in a pg8.4. (5K tps, 260M rows table, lock
too much)
We could try to resolve the COMMENT ON issue with the same mechanism.
What we need is a table lock which blocks other DDL statements, but not DML.
--
-- Josh Berkus
PostgreSQL Experts Inc.
http://www.pgexperts.com
On Wed, Jul 7, 2010 at 9:04 PM, Cédric Villemain
<cedric.villemain.debian@gmail.com> wrote:
I assume this did not get done for 9.0. Do we want a TODO item?
Yes.
Added:
Reduce locking required for ALTER commands
I just faced production issue where it is impossible to alter table to
adjust autovacuum settings in a pg8.4. (5K tps, 260M rows table, lock
too much)Can we add some mechanism to prevent that situation also in the TODO item ?
(alternative is actualy to alter other tables and adjust the
postgresql.conf for biggest tables, but not an ideal solution anyway)* http://archives.postgresql.org/pgsql-hackers/2009-08/msg00533.php
* http://archives.postgresql.org/pgsql-hackers/2009-10/msg01083.php
* http://archives.postgresql.org/pgsql-hackers/2010-01/msg02349.php
Bruce, that last link is about something else completely. Here are
some better ones:
http://archives.postgresql.org/pgsql-hackers/2008-10/msg01248.php
http://archives.postgresql.org/pgsql-hackers/2008-10/msg00242.php
All,
Rereading the thread, I'm a bit confused by why we're proposing to use
a SHARE lock; it seems to me that a self-conflicting lock type would
simplify things. There's a bunch of discussion on the thread about
how to handle pg_class updates atomically, but doesn't using a
self-conflicting lock type eliminate that problem?
It strikes me that for the following operations, which don't affect
queries at all, we could use a SHARE UPDATE EXCLUSIVE, which is likely
superior to SHARE for this purpose because it wouldn't lock out
concurrent DML write operations:
ALTER [ COLUMN ] column SET STATISTICS integer
ALTER [ COLUMN ] column SET STORAGE { PLAIN | EXTERNAL | EXTENDED | MAIN }
ALTER [ COLUMN ] column SET ( attribute_option = value [, ... ] )
ALTER [ COLUMN ] column RESET ( attribute_option [, ... ] )
CLUSTER ON index_name
SET WITHOUT CLUSTER
SET ( storage_parameter = value [, ... ] )
RESET ( storage_parameter [, ... ] )
(Of the above list, arguably SET STORAGE and [RE]SET (fillfactor) do
in fact affect DML writes, but it seems like changing them on the fly
should still be safe.)
The remaining commands which Simon proposed to downgrade to share-locks were:
ALTER [ COLUMN ] column SET DEFAULT expression
CREATE RULE (only non-ON SELECT rules)
CREATE TRIGGER
ALTER [ COLUMN ] column SET NOT NULL (but not DROP NOT NULL)
ADD table_constraint (but not DROP CONSTRAINT)
DISABLE TRIGGER [ trigger_name | ALL | USER ]
ENABLE TRIGGER [ trigger_name | ALL | USER ]
ENABLE REPLICA TRIGGER trigger_name
ENABLE ALWAYS TRIGGER trigger_name
Setting a column default, creating a non-select RULE, and
creating/disabling a trigger shouldn't affect SELECT statements, so as
long as we lock out all updates we should be OK. For these it seems
we could use SHARE ROW EXCLUSIVE, which will conflict with any other
DML command and with any data change, but not with SELECTs.
I am somewhat fuzzy on what the correct locking is for SET NOT NULL
and ADD table_constraint. I believe that the idea here is that a
query plan might rely on the existence of a constraint for
correctness, so we must lock out all queries when dropping one; but a
query plan can't rely on the absence of a constraint for correctness
(since the constraint could be true anyway), so it's safe to allow one
to be added even when there are queries in flight. If that's correct
then it seems like we could use SHARE ROW EXCLUSIVE for these command
types as well. However, these two particular commands have another
distinguishing characteristic also: they might run for a while, so it
would be useful to be able to do more than one at once. So maybe it's
worth thinking a little harder about how to weaken those two in
particular to some non-self-conflicting lock type. Then again, even
SHARE ROW EXCLUSIVE is a big improvement over ACCESS EXCLUSIVE, so
maybe that would be enough for a first go at the problem.
Thoughts?
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise Postgres Company
On Wed, 2010-07-07 at 22:26 -0400, Robert Haas wrote:
Rereading the thread, I'm a bit confused by why we're proposing to use
a SHARE lock; it seems to me that a self-conflicting lock type would
simplify things. There's a bunch of discussion on the thread about
how to handle pg_class updates atomically, but doesn't using a
self-conflicting lock type eliminate that problem?
The use of the SHARE lock had nothing to do with the pg_class update
requirement, so that suggestion won't help there.
It strikes me that for the following operations, which don't affect
queries at all, we could use a SHARE UPDATE EXCLUSIVE, which is likely
superior to SHARE for this purpose because it wouldn't lock out
concurrent DML write operations:
Yes, we can also use SHARE UPDATE EXCLUSIVE for some of them. The use of
SHARE lock was specifically targeted at ADD FOREIGN KEY, to allow
multiple concurrent FKs. Not much use for production however, so SUE
looks better to me.
Not sure I agree with the "don't affect queries at all" bit....
I'll take my previous patch through to completion now, I'm funded to do
that work now. Sept commitfest though.
--
Simon Riggs www.2ndQuadrant.com
On Thu, Jul 8, 2010 at 2:16 AM, Simon Riggs <simon@2ndquadrant.com> wrote:
On Wed, 2010-07-07 at 22:26 -0400, Robert Haas wrote:
Rereading the thread, I'm a bit confused by why we're proposing to use
a SHARE lock; it seems to me that a self-conflicting lock type would
simplify things. There's a bunch of discussion on the thread about
how to handle pg_class updates atomically, but doesn't using a
self-conflicting lock type eliminate that problem?The use of the SHARE lock had nothing to do with the pg_class update
requirement, so that suggestion won't help there.
Forgive me if I press on this just a bit further, but ISTM that an
atomic pg_class update functionality isn't intrinsically required,
because if it were the current code would need it. So what is
changing in this patch that makes it necessary when it isn't now?
ISTM it must be that the lock is weaker. What am I missing?
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise Postgres Company
On Thu, 2010-07-08 at 06:08 -0400, Robert Haas wrote:
On Thu, Jul 8, 2010 at 2:16 AM, Simon Riggs <simon@2ndquadrant.com> wrote:
On Wed, 2010-07-07 at 22:26 -0400, Robert Haas wrote:
Rereading the thread, I'm a bit confused by why we're proposing to use
a SHARE lock; it seems to me that a self-conflicting lock type would
simplify things. There's a bunch of discussion on the thread about
how to handle pg_class updates atomically, but doesn't using a
self-conflicting lock type eliminate that problem?The use of the SHARE lock had nothing to do with the pg_class update
requirement, so that suggestion won't help there.Forgive me if I press on this just a bit further, but ISTM that an
atomic pg_class update functionality isn't intrinsically required,
because if it were the current code would need it. So what is
changing in this patch that makes it necessary when it isn't now?
ISTM it must be that the lock is weaker. What am I missing?
Not sure I follow that logic. Discussion on the requirement is in the
archives. I don't wish to question that aspect myself.
--
Simon Riggs www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Training and Services
On Thu, Jul 8, 2010 at 5:09 PM, Simon Riggs <simon@2ndquadrant.com> wrote:
On Thu, 2010-07-08 at 06:08 -0400, Robert Haas wrote:
On Thu, Jul 8, 2010 at 2:16 AM, Simon Riggs <simon@2ndquadrant.com> wrote:
On Wed, 2010-07-07 at 22:26 -0400, Robert Haas wrote:
Rereading the thread, I'm a bit confused by why we're proposing to use
a SHARE lock; it seems to me that a self-conflicting lock type would
simplify things. There's a bunch of discussion on the thread about
how to handle pg_class updates atomically, but doesn't using a
self-conflicting lock type eliminate that problem?The use of the SHARE lock had nothing to do with the pg_class update
requirement, so that suggestion won't help there.Forgive me if I press on this just a bit further, but ISTM that an
atomic pg_class update functionality isn't intrinsically required,
because if it were the current code would need it. So what is
changing in this patch that makes it necessary when it isn't now?
ISTM it must be that the lock is weaker. What am I missing?Not sure I follow that logic. Discussion on the requirement is in the
archives. I don't wish to question that aspect myself.
The relevant link from the archives is here:
http://archives.postgresql.org/pgsql-hackers/2008-10/msg00242.php
Tom asked what happens when two transactions attempt to do concurrent
actions on the same table. Your response was that we should handle it
like CREATE INDEX, and handle the update of the pg_class row
non-transactionally. But of course, if you use a self-conflicting
lock at the relation level, then the relation locks conflict and you
never have to worry about how to update the pg_class entry in the face
of concurrent updates.
Which, come to think of it, is probably a good thing, because on
further reflection I'm pretty sure the proposed approach will fall
down completely for some of these operations. heap_inplace_update()
can only be used when (a) the new tuple is identical in size to the
old tuple, and (b) no action is required on rollback. That's fine for
updating things like relpages and reltuples (which are just hints
anyway) but it ain't gonna work for changing, say, reloptions, which
is variable-length. It's also not going to work for changing things
like attstorage, even though a change there can't affect the tuple
size, because modifying the tuple in place won't handle rollbacks
correctly.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise Postgres Company
On Fri, 2010-07-09 at 13:04 -0400, Robert Haas wrote:
Tom asked what happens when two transactions attempt to do concurrent
actions on the same table. Your response was that we should handle it
like CREATE INDEX, and handle the update of the pg_class row
non-transactionally. But of course, if you use a self-conflicting
lock at the relation level, then the relation locks conflict and you
never have to worry about how to update the pg_class entry in the face
of concurrent updates.
From memory, Tom was also worried about the prospect of people updating
pg_class directly using SQL. That seems a rare, yet valid concern.
I've already agreed with your point that we should use SHARE UPDATE
EXCLUSIVE.
--
Simon Riggs www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Training and Services
On Fri, Jul 9, 2010 at 1:18 PM, Simon Riggs <simon@2ndquadrant.com> wrote:
On Fri, 2010-07-09 at 13:04 -0400, Robert Haas wrote:
Tom asked what happens when two transactions attempt to do concurrent
actions on the same table. Your response was that we should handle it
like CREATE INDEX, and handle the update of the pg_class row
non-transactionally. But of course, if you use a self-conflicting
lock at the relation level, then the relation locks conflict and you
never have to worry about how to update the pg_class entry in the face
of concurrent updates.From memory, Tom was also worried about the prospect of people updating
pg_class directly using SQL. That seems a rare, yet valid concern.
Yes, and it's another another reason why we shouldn't use
non-transactional updates.
http://archives.postgresql.org/pgsql-hackers/2008-11/msg00744.php
I've already agreed with your point that we should use SHARE UPDATE
EXCLUSIVE.
The point you seem to be missing is that once we make that decision,
we can throw all the heap_inplace_update() stuff out the window, and
the whole problem becomes much simpler.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise Postgres Company
Robert Haas wrote:
On Wed, Jul 7, 2010 at 9:04 PM, C?dric Villemain
<cedric.villemain.debian@gmail.com> wrote:I assume this did not get done for 9.0. ?Do we want a TODO item?
Yes.
Added:
? ? ? ?Reduce locking required for ALTER commands
I just faced production issue where it is impossible to alter table to
adjust autovacuum settings in a pg8.4. (5K tps, 260M rows table, lock
too much)Can we add some mechanism to prevent that situation also in the TODO item ?
(alternative is actualy to alter other tables and adjust the
postgresql.conf for biggest tables, but not an ideal solution anyway)? ? ? ? ? ?* http://archives.postgresql.org/pgsql-hackers/2009-08/msg00533.php
? ? ? ? ? ?* http://archives.postgresql.org/pgsql-hackers/2009-10/msg01083.php
? ? ? ? ? ?* http://archives.postgresql.org/pgsql-hackers/2010-01/msg02349.phpBruce, that last link is about something else completely. Here are
some better ones:http://archives.postgresql.org/pgsql-hackers/2008-10/msg01248.php
http://archives.postgresql.org/pgsql-hackers/2008-10/msg00242.php
Thanks, TODO updated.
--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ None of us is going to be here forever. +
On Fri, 2010-07-09 at 15:03 -0400, Robert Haas wrote:
On Fri, Jul 9, 2010 at 1:18 PM, Simon Riggs <simon@2ndquadrant.com> wrote:
On Fri, 2010-07-09 at 13:04 -0400, Robert Haas wrote:
Tom asked what happens when two transactions attempt to do concurrent
actions on the same table. Your response was that we should handle it
like CREATE INDEX, and handle the update of the pg_class row
non-transactionally. But of course, if you use a self-conflicting
lock at the relation level, then the relation locks conflict and you
never have to worry about how to update the pg_class entry in the face
of concurrent updates.From memory, Tom was also worried about the prospect of people updating
pg_class directly using SQL. That seems a rare, yet valid concern.Yes, and it's another another reason why we shouldn't use
non-transactional updates.http://archives.postgresql.org/pgsql-hackers/2008-11/msg00744.php
I've already agreed with your point that we should use SHARE UPDATE
EXCLUSIVE.The point you seem to be missing is that once we make that decision,
we can throw all the heap_inplace_update() stuff out the window, and
the whole problem becomes much simpler.
That is a point I missed.
Considering this further, it seems we have two conflicting requirements
1. ALTER TABLE ... ADD FOREIGN KEY needs a SHARE mode lock if we want to
run that concurrently with itself and CREATE INDEX operations during a
pg_restore. This was my original goal.
2. In most other cases, SHARE UPDATE EXCLUSIVE is the most useful lock,
especially during heavy operational use.
Since adding an FK requires adding triggers also that puts both of the
above in direct conflict.
ISTM that we should follow (2) and let (1) be added to the TODO for
later work, as an option. I'll followu up on (2).
--
Simon Riggs www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Training and Services
