Hi Rahila,
On 2017/04/05 18:57, Rahila Syed wrote:
> Hello Amit,
>
>> Could you briefly elaborate why you think the lack global index support
>> would be a problem in this regard?
> I think following can happen if we allow rows satisfying the new partition
> to lie around in the
> default partition until background process moves it.
> Consider a scenario where partition key is a primary key and the data in
> the default partition is
> not yet moved into the newly added partition. If now, new data is added
> into the new partition
> which also exists(same key) in default partition there will be data
> duplication. If now
> we scan the partitioned table for that key(from both the default and new
> partition as we
> have not moved the rows) it will fetch the both rows.
> Unless we have global indexes for partitioned tables, there is chance of
> data duplication between
> child table added after default partition and the default partition.
Ah, okay. I think I wrote that question before even reading the next
sentence in Keith's message ("there's still an issue of data duplication
after the necessary child table is added.")
Maybe we can disallow background row movement if such global constraint
exists.
>> Scanning it and moving rows to the newly added partition while holding an
>> AccessExclusiveLock on the parent will block any and all of the concurrent
>> activity on it until the row-movement is finished.
> Can you explain why this will require AccessExclusiveLock on parent and
> not just the default partition and newly added partition?
Because we take an AccessExclusiveLock on the parent table when
adding/removing a partition in general. We do that because concurrent
accessors of the parent table rely on its partition descriptor from not
changing under them.
Thanks,
Amit
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
