| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | "Jim C(dot) Nasby" <jnasby(at)pervasive(dot)com> |
| Cc: | Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>, ITAGAKI Takahiro <itagaki(dot)takahiro(at)lab(dot)ntt(dot)co(dot)jp>, pgsql-hackers(at)postgresql(dot)org |
| Subject: | Re: Remove xmin and cmin from frozen tuples |
| Date: | 2005-09-06 22:02:27 |
| Message-ID: | 20979.1126044147@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
"Jim C. Nasby" <jnasby(at)pervasive(dot)com> writes:
>>> If we're going to look at doing that I think it would also be good to
>>> consider including xmin and xmax as well.
>>
>> If you do that, you'll never be able to delete or update the tuple.
> My idea was to use an int to represent combinations of (c|x)(min|max),
> probably on a per-table basis. Essentially, it would normalize these
> values. I don't see how this would eliminate the ability to update or
> delete.
How will other transactions know whether the tuple is good (yet) or not?
How will you recover if the backend that does know this crashes before
transaction end? How will you lock tuples for update/delete?
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | mark | 2005-09-06 22:06:48 | Re: uuid type for postgres |
| Previous Message | Jim C. Nasby | 2005-09-06 21:55:28 | Re: Remove xmin and cmin from frozen tuples |