Re: invalid tid errors in latest 7.3.4 stable.
От | Stephan Szabo |
---|---|
Тема | Re: invalid tid errors in latest 7.3.4 stable. |
Дата | |
Msg-id | 20031001150510.U45145@megazone.bigpanda.com обсуждение исходный текст |
Ответ на | Re: invalid tid errors in latest 7.3.4 stable. (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: invalid tid errors in latest 7.3.4 stable.
|
Список | pgsql-hackers |
On Wed, 1 Oct 2003, Tom Lane wrote: > Stephan Szabo <sszabo@megazone.bigpanda.com> writes: > > On Tue, 30 Sep 2003, Tom Lane wrote: > >> I think I can implement it and it will act as stated in my proposal. > >> Whether people like the proposed behavior is the big question in my > >> mind. > > > I think it's more reasonable than the current behavior or any of > > the others we've hit along the way, and we have to pretty much choose > > now if we want to change it for 7.4. > > I've committed the attached patch. One thing I wanted to double-check > with you is that the SELECT FOR UPDATES done in the noaction cases are > being correctly handled. I think it is correct to do them with the > current snapshot rather than the start-of-transaction snap; do you > agree? Also, I did not propagate the crosscheck support into I think the ones in the main functions need to be current snapshot. I think the one in ri_Check_Pk_Match doesn't need to be. That's there to see if this same transaction has inserted a new row with the old value of the updated/deleted pk row and the serializable snapshot should be fine. Any conflicting attempts from another transaction should be waiting on our completion due to the unique index I think. > heap_mark4update, meaning that these SELECT FOR UPDATEs won't complain > if they find a row that was inserted later than the start of the > serializable transaction. I'm not totally sure if they should or not; > what do you think? Well, I think that not doing so would only change the error from a serialization error to a matching row exists error. It might be a bit surprising if you've just done a select yourself and seen that there were no matching rows, but I'm not sure that it's a big deal as long as it errors as appropriate.
В списке pgsql-hackers по дате отправления: