Re: [HACKERS] Last thoughts about LONG
От | wieck@debis.com (Jan Wieck) |
---|---|
Тема | Re: [HACKERS] Last thoughts about LONG |
Дата | |
Msg-id | m11wtf9-0003kGC@orion.SAPserv.Hamburg.dsh.de обсуждение исходный текст |
Ответ на | Re: [HACKERS] Last thoughts about LONG (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | pgsql-hackers |
Tom Lane wrote: > wieck@debis.com (Jan Wieck) writes: > > Another bonus would be this: What happens on an UPDATE to a > > table having LONG attributes? If the attribute is not > > modified, the OLD LongData will be found in the targetlist, > > and we'll not waste any space by storing the same information > > again. > > Won't work. If you do that, you have several generations of the > "primary" tuple pointing at the same item in the "secondary" table. > There is room in the multiple primary tuples to keep track of their > committed/uncommitted status, but there won't be enough room to > keep track in the secondary table. A really critical point, to think about in depth. And another point I could have stumbled over. But it would work anyway. I assumed up to now, that even under MVCC, and even if reading dirty, there could be at max one single transaction modifying one and the same tuple - no? Ignore all the rest and forget all my comments if your answer is no. But please tell me how something like RI should ever work RELIABLE in such an environment. In fact, in that case I would immediately stop all my efford in FOREIGN KEY, because it would be a dead end street - so I assume your answer is yes. My concept, using regular heap access inside of heap access to act on "secondary" table, means to stamp the same current xact as for "primary" table into xmax of old, and into xmin of new tuples for the "secondary" table. And it means that this operation appears to be atomic if living in a locking environment. The only thing I DON'T wanted to do is to stamp xmax and create new instances in "secondary" table, if no update is done to the value of the old LONG attribute. Any UPDATE modifying the LONG value, and INSERT/DELETE of course will stamp this information and/or create new instances. So the only thing (because the only difference) to worry about are unstamped and uncreated instances in "secondary" table - right? Since INSERT/DELETE allways act synchronous to the "primary" table, and and UPDATE modifying the LONG too, the only thing left to worry about is an UPDATE without updating the LONG. In this scenario, a "secondary" tuple of a not updated "primary" LONG will have an older, but surely committed, xmin. And it's xmax will be either infinite, or aborted. So it is visible - no other chance. And that's good, because at the time beeing, the updater of the "primary" tuple does a NOOP on the "secondary". And this (extended) part of the "primaries" tuple information is absolutely unaffected, regardless if it's transaction will commit or rollback. Well, your concern is again valid. This concept MIGHT need to force a NON-MVCC locking scheme for "secondary" tables. But as far as I learned from the RI stuff, that isn't a problem and therefore current Jackpot value to be added to Vadim's account. Jan -- #======================================================================# # It's easier to get forgiveness for being wrong than for being right. # # Let's break this rule - forgive me. # #========================================= wieck@debis.com (Jan Wieck) #
В списке pgsql-hackers по дате отправления: