| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | "Hiroshi Inoue" <Inoue(at)tpf(dot)co(dot)jp> |
| Cc: | "Bruce Momjian" <pgman(at)candle(dot)pha(dot)pa(dot)us>, "Florian Wunderlich" <fwunderlich(at)devbrain(dot)de>, pgsql-general(at)postgresql(dot)org |
| Subject: | Re: persistent portals/cursors (between transactions) |
| Date: | 2002-01-25 17:06:08 |
| Message-ID: | 26443.1011978368@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-general |
"Hiroshi Inoue" <Inoue(at)tpf(dot)co(dot)jp> writes:
>> AccessShareLock would fend off DROP/ALTER TABLE, but not VACUUM anymore.
> Really ? VACUUM FULL conflicts with AccessShareLock from the
> first.
I was speaking of lazy VACUUM, of course.
> If new vacuum does wrong thing with persistent read-only cursors
> it would do the wrong thing with the current cursors as well.
No, because current cursors don't span transactions.
> Of cource as Vadim mentioned before, HeapTupleSatisfiesVacuum()
> should take the transaction id in which the cursor was opened into
> account.
I haven't read all of that thread yet; maybe Vadim already had the idea
I just had of playing games with oldest-XMIN.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2002-01-25 17:07:24 | Re: persistent portals/cursors (between transactions) |
| Previous Message | Fran Fabrizio | 2002-01-25 17:04:11 | grant the right to select only certain rows? |