Of course, there is a much more serious problem with the whole idea. I
have worked through most of the necessary changes and I'm now down to
changing heap_udate to comply with the new locking protocol.
The problem I'm now facing is that we need to know the set of updated
columns pretty early -- j
Excerpts from Tom Lane's message of mié dic 01 14:44:03 -0300 2010:
> Florian Pflug writes:
> > On Dec1, 2010, at 17:17 , Tom Lane wrote:
> >> There's not enough space in the infomask to record which columns (or
> >> which unique index) are involved. And if you're talking about data that
> >> cou
On Dec2, 2010, at 00:59 , Jim Nasby wrote:
> On Dec 1, 2010, at 11:09 AM, Florian Pflug wrote:
>> An UPDATE on such a SHARE locked row would be allowed despite the lock if it
>> only changed columns not mentioned by any unique index.
>
> On a side-note, by "changed columns" do you mean the column
On Dec 1, 2010, at 11:09 AM, Florian Pflug wrote:
> An UPDATE on such a SHARE locked row would be allowed despite the lock if it
> only changed columns not mentioned by any unique index.
On a side-note, by "changed columns" do you mean the column appeared in the
UPDATE statement, or the data act
On Dec1, 2010, at 18:44 , Tom Lane wrote:
> Florian Pflug writes:
>> On Dec1, 2010, at 17:17 , Tom Lane wrote:
>>> There's not enough space in the infomask to record which columns (or
>>> which unique index) are involved. And if you're talking about data that
>>> could remain on disk long after t
Florian Pflug writes:
> On Dec1, 2010, at 17:17 , Tom Lane wrote:
>> There's not enough space in the infomask to record which columns (or
>> which unique index) are involved. And if you're talking about data that
>> could remain on disk long after the unique index is gone, that's not
>> going to
On Dec1, 2010, at 17:17 , Tom Lane wrote:
> Florian Pflug writes:
>> The validity wouldn't change, only the kind of lock taken. If all columns to
>> be locked are part of some unique index, we'd record that fact in the locked
>> tuple's infomask, and thus know that only a certain subset of colum
Florian Pflug writes:
> The validity wouldn't change, only the kind of lock taken. If all columns to
> be locked are part of some unique index, we'd record that fact in the locked
> tuple's infomask, and thus know that only a certain subset of columns are to
> be prevented from being updated.
On Nov29, 2010, at 22:33 , Tom Lane wrote:
> Alvaro Herrera writes:
>> Excerpts from Alvaro Herrera's message of lun nov 29 18:00:55 -0300 2010:
>>> Additionally, we'd have to expend some more cycles at the parse analysis
>>> phase (of the "FOR SHARE OF x.col1, x.col2" query) to verify that those
Excerpts from Tom Lane's message of lun nov 29 18:33:19 -0300 2010:
> Alvaro Herrera writes:
> > Excerpts from Alvaro Herrera's message of lun nov 29 18:00:55 -0300 2010:
> >> Additionally, we'd have to expend some more cycles at the parse analysis
> >> phase (of the "FOR SHARE OF x.col1, x.col2"
Alvaro Herrera writes:
> Excerpts from Alvaro Herrera's message of lun nov 29 18:00:55 -0300 2010:
>> Additionally, we'd have to expend some more cycles at the parse analysis
>> phase (of the "FOR SHARE OF x.col1, x.col2" query) to verify that those
>> columns belong into some non-partial unique i
Excerpts from Alvaro Herrera's message of lun nov 29 18:00:55 -0300 2010:
> This would require some additions in ri_FetchConstraintInfo(). Right
> now it does a single syscache lookup and then extracts a bunch of
> attributes from there. If we're going to implement as you suggest, we'd
> have to
Excerpts from Florian Pflug's message of vie nov 26 10:48:39 -0300 2010:
> To me, the whole thing seems to be special case of allowing to not only lock
> whole tuples FOR UPDATE or FOR SHARE, but also individual fields or sets of
> fields. Except that for simplicity, only two sets are supported,
Excerpts from Florian Pflug's message of sáb nov 27 01:29:39 -0300 2010:
> On Nov26, 2010, at 21:06 , Alvaro Herrera wrote:
> > The problem with this idea is that it's not possible to implement it.
>
> How so? The implementation you proposed in your blog should work fine for
> this. XMAX_KEY_LOC
On Nov26, 2010, at 21:06 , Alvaro Herrera wrote:
> Excerpts from Florian Pflug's message of vie nov 26 10:48:39 -0300 2010:
>> On Nov25, 2010, at 23:01 , Alvaro Herrera wrote:
>>> So I've been working on improving locks for foreign key checks, as
>>> discussed in a thread started by Joel Jacobson a
Excerpts from Florian Pflug's message of vie nov 26 10:48:39 -0300 2010:
> On Nov25, 2010, at 23:01 , Alvaro Herrera wrote:
> > So I've been working on improving locks for foreign key checks, as
> > discussed in a thread started by Joel Jacobson a while ago. I've posted
> > about this:
> > http://
On Nov25, 2010, at 23:01 , Alvaro Herrera wrote:
> So I've been working on improving locks for foreign key checks, as
> discussed in a thread started by Joel Jacobson a while ago. I've posted
> about this:
> http://www.commandprompt.com/blogs/alvaro_herrera/2010/11/fixing_foreign_key_deadlocks/
>
Hi,
So I've been working on improving locks for foreign key checks, as
discussed in a thread started by Joel Jacobson a while ago. I've posted
about this:
http://www.commandprompt.com/blogs/alvaro_herrera/2010/11/fixing_foreign_key_deadlocks/
http://www.commandprompt.com/blogs/alvaro_herrera/2010
18 matches
Mail list logo
