Re: [HACKERS] [PATCHES] [pgsql-patches] Phantom Command IDs,updated patch

2007-02-09 Thread Heikki Linnakangas
Tom Lane wrote: I'm testing the patch currently. I was a bit surprised to find the without_oid test failing, but it makes sense because I'm using a MAXALIGN=8 machine. I suppose Heikki tested on MAXALIGN=4. That's right. Thanks for the review! -- Heikki Linnakangas EnterpriseDB

Re: [HACKERS] [PATCHES] [pgsql-patches] Phantom Command IDs, updated patch

2007-02-09 Thread Zeugswetter Andreas ADI SD
As for what I think we *should* do near-term, I'm pretty strongly tempted to suggest that we just throw an error if a subtransaction tries to upgrade an upper transaction's shared lock to exclusive. So when a RI check locks a parent, you would not be able to update the parent in a later

Re: [HACKERS] [PATCHES] [pgsql-patches] Phantom Command IDs, updated patch

2007-02-09 Thread Tom Lane
Zeugswetter Andreas ADI SD [EMAIL PROTECTED] writes: So when a RI check locks a parent, you would not be able to update the parent in a later subtrans. I can imagine, that the error would be a problem in a select for update loop, because there you usually want to update the row. No, it would

Re: [HACKERS] [PATCHES] [pgsql-patches] Phantom Command IDs, updated patch

2007-02-08 Thread Tom Lane
[ time to move this thread to -hackers ] Bruce Momjian [EMAIL PROTECTED] writes: Tom Lane wrote: Alvaro Herrera [EMAIL PROTECTED] writes: Heikki Linnakangas wrote: Tom Lane wrote: BTW, I don't care much for the terminology phantom cid ... there's nothing particularly phantom about them,

Re: [HACKERS] [PATCHES] [pgsql-patches] Phantom Command IDs, updated patch

2007-02-08 Thread Bruce Momjian
Tom Lane wrote: [ time to move this thread to -hackers ] Bruce Momjian [EMAIL PROTECTED] writes: Tom Lane wrote: Alvaro Herrera [EMAIL PROTECTED] writes: Heikki Linnakangas wrote: Tom Lane wrote: BTW, I don't care much for the terminology phantom cid ... there's nothing

Re: [HACKERS] [PATCHES] [pgsql-patches] Phantom Command IDs, updated patch

2007-02-08 Thread Tom Lane
Bruce Momjian [EMAIL PROTECTED] writes: Tom Lane wrote: Packed doesn't seem to have quite the right connotation either --- it sounds like it means there are two separable fields in the CID value. Maybe composite cid? At one point I was thinking combo. but composite sounds good. I like

Re: [HACKERS] [PATCHES] [pgsql-patches] Phantom Command IDs, updated patch

2007-02-08 Thread Alvaro Herrera
Bruce Momjian wrote: Tom Lane wrote: Another issue that we need to think about before we go too far with this is the problem that we punted on before 8.2 release: how to deal with rolling back an upgrade of a row-level lock from shared to exclusive within a subtransaction. I'm a bit

Re: [HACKERS] [PATCHES] [pgsql-patches] Phantom Command IDs, updated patch

2007-02-08 Thread Alvaro Herrera
Alvaro Herrera wrote: This starts to look awfully similar to MultiXactIds. And probably using such a mechanism would allow you to rollback any number of row locks: take the current membersoof the multicid, substract the one that rolled back and use that as new multicid. The main difference

Re: [HACKERS] [PATCHES] [pgsql-patches] Phantom Command IDs, updated patch

2007-02-08 Thread Bruce Momjian
Tom Lane wrote: At one point I was thinking combo. but composite sounds good. I like combo --- nice and short. Another issue that we need to think about before we go too far with this is the problem that we punted on before 8.2 release: how to deal with rolling back an upgrade of a

Re: [HACKERS] [PATCHES] [pgsql-patches] Phantom Command IDs, updated patch

2007-02-08 Thread Tom Lane
Alvaro Herrera [EMAIL PROTECTED] writes: Humm, sorry, obviously this makes no sense at all because I mentally mixed the Xid locker and the Cids. After thinking a bit, I have a sketch of a solution. Assume that we extend the MultiXact infrastructure so that it can track whether each member of a

Re: [HACKERS] [PATCHES] [pgsql-patches] Phantom Command IDs, updated patch

2007-02-08 Thread Tom Lane
Bruce Momjian [EMAIL PROTECTED] writes: The way combo cid is supposed to work is that you are deleting a row created in your same transaction by a previous command id, so you look in the combo cid array to see if a match for that pair exists --- if not, you create a new entry and put the two

Re: [HACKERS] [PATCHES] [pgsql-patches] Phantom Command IDs, updated patch

2007-02-08 Thread Bruce Momjian
Tom Lane wrote: Bruce Momjian [EMAIL PROTECTED] writes: The way combo cid is supposed to work is that you are deleting a row created in your same transaction by a previous command id, so you look in the combo cid array to see if a match for that pair exists --- if not, you create a new

Re: [HACKERS] [PATCHES] [pgsql-patches] Phantom Command IDs,updated patch

2007-02-08 Thread Simon Riggs
On Thu, 2007-02-08 at 15:32 -0500, Tom Lane wrote: Bruce Momjian [EMAIL PROTECTED] writes: Tom Lane wrote: Packed doesn't seem to have quite the right connotation either --- it sounds like it means there are two separable fields in the CID value. Maybe composite cid? At one point

Re: [HACKERS] [PATCHES] [pgsql-patches] Phantom Command IDs,updated patch

2007-02-08 Thread Alvaro Herrera
Simon Riggs wrote: On Thu, 2007-02-08 at 15:32 -0500, Tom Lane wrote: Bruce Momjian [EMAIL PROTECTED] writes: Tom Lane wrote: Packed doesn't seem to have quite the right connotation either --- it sounds like it means there are two separable fields in the CID value. Maybe

Re: [HACKERS] [PATCHES] [pgsql-patches] Phantom Command IDs,updated patch

2007-02-08 Thread Tom Lane
Alvaro Herrera [EMAIL PROTECTED] writes: Simon Riggs wrote: Combo is OK, because it's a *combination* of two CommandIds. That means they are ComboCommandIds or CCIs. CCI is CommandCounterIncrement to me, so let's not use that abbreviation. Agreed. I looked for a bit at adding a separate