| From: | Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> |
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Cc: | Hiroshi Inoue <Inoue(at)tpf(dot)co(dot)jp>, Neil Padgett <npadgett(at)redhat(dot)com>, "pgsql-patches(at)postgresql(dot)org" <pgsql-patches(at)postgresql(dot)org> |
| Subject: | Re: Revised Patch to allow multiple table locks in "Unison" |
| Date: | 2001-07-30 16:20:58 |
| Message-ID: | 200107301620.f6UGKwq07511@candle.pha.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers pgsql-patches |
> Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> writes:
> > Actually, with this new code, we could go back to locking in oid order,
> > which would eliminate the problem.
>
> No it wouldn't. If anything, locking in a *randomized* order would be
> the best bet. But I have no confidence in this approach, anyway.
I am looking for a way to get this in there without munging the lock
code, which is already quite complex. What about doing some sort of
small sleep after we reset back to the beginning of the table list.
--
Bruce Momjian | http://candle.pha.pa.us
pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Bruce Momjian | 2001-07-30 16:49:57 | Performance TODO items |
| Previous Message | Fernando Nasser | 2001-07-30 16:16:22 | Re: Revised Patch to allow multiple table locks in "Unison" |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Bruce Momjian | 2001-07-30 16:55:38 | Re: Revised Patch to allow multiple table locks in "Unison" |
| Previous Message | Bruce Momjian | 2001-07-30 16:16:25 | Re: Add ANALYZE to tab complete in psql |