| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | "Heikki Linnakangas" <heikki(at)enterprisedb(dot)com> |
| Cc: | "Florian G(dot) Pflug" <fgp(at)phlo(dot)org>, "PostgreSQL-patches" <pgsql-patches(at)postgresql(dot)org> |
| Subject: | Re: Lazy xid assignment V3 |
| Date: | 2007-09-03 19:47:44 |
| Message-ID: | 24864.1188848864@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-patches |
"Heikki Linnakangas" <heikki(at)enterprisedb(dot)com> writes:
> Yeah. If we did want to do something more, we could acquire the lock on
> vid conditionally, and use another vid if acquiring the lock fails. But
> I don't think it's necessary.
I was thinking more along the lines of looking through the ProcArray at
backend startup to ensure the sessionID we've chosen is unique, and
choosing another one if not. But this would expend cycles with the
ProcArray locked, for something that seems exceedingly unlikely to
happen,
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Bruce Momjian | 2007-09-04 01:15:46 | HOT documentation README |
| Previous Message | Florian G. Pflug | 2007-09-03 18:05:22 | Re: Lazy xid assignment V3 |