Re: Auto creation of Partitions - Mailing list pgsql-hackers

From Joris Dobbelsteen
Subject Re: Auto creation of Partitions
Date
Msg-id 73427AD314CC364C8DF0FFF9C4D693FF0379BE@nehemiah.joris2k.local
Whole thread Raw
In response to Auto creation of Partitions  (NikhilS <nikkhils@gmail.com>)
List pgsql-hackers
>-----Original Message-----
>From: pgsql-hackers-owner@postgresql.org
>[mailto:pgsql-hackers-owner@postgresql.org] On Behalf Of Josh Berkus
>Sent: dinsdag 6 maart 2007 19:45
>To: pgsql-hackers@postgresql.org
>Cc: Florian G. Pflug; Martijn van Oosterhout; Shane Ambler;
>NikhilS; Peter Eisentraut
>Subject: Re: [HACKERS] Auto creation of Partitions
>
>Florian,
>
>> This sounds like what is really needed is a way to lock a certain
>> condition, namely the existance or non-existance of a record with
>> certain values in certain fields. This would not only help
>this case,
>> it would also help RI triggers, because those wouldn't have
>to acquire
>> a share lock on the referenced rows anymore.
>
>That's called "predicate locking" and it's very, very hard to do.

That's definitely not needed.

Rather something good such that we can finally enforce RI ourselves in
the general case. This is currently not possible to do easily, except in
C code. This means we need to look at all the rows that exists, but are
normally be invisible to our view of the database. Still I'm not sure
about all cases, as the MVCC model is quite tricky and I'm not sure
whether my idea's about it are valid.

The basic idea is that you need to guarentee the constraint for the
'single underlaying model' (with everything visible) and for your view
(under your visibility rules). I believe, but are not certain, that
under these conditions any (valid) snapshot will obey the desired
constraints.

- Joris Dobbelsteen



pgsql-hackers by date:

Previous
From: David Fetter
Date:
Subject: Re: Arrays of Complex Types
Next
From: "Simon Riggs"
Date:
Subject: Re: Bug: Buffer cache is not scan resistant