| From: | Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org> |
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Cc: | Neil Conway <neilc(at)samurai(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: fixing LISTEN/NOTIFY |
| Date: | 2005-10-06 13:49:04 |
| Message-ID: | 20051006134904.GJ5373@surnet.cl |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Thu, Oct 06, 2005 at 09:12:58AM -0400, Tom Lane wrote:
> Neil Conway <neilc(at)samurai(dot)com> writes:
> > However, I don't really like the idea of blocking the backend for a
> > potentially significant amount of time in a state half-way between
> > "committed" and "ready for the next query".
>
> I wonder whether we could use something comparable to pg_multixact
> or pg_subtrans, to convert the problem from one of "need to fit in
> fixed amount of memory" to one of "it's on disk with some buffers
> in memory".
The multixact mechanism seems a perfect fit to me (variable length
contents, identifiers produced serially and destroyed in a
not-too-distant future). In fact I proposed it awhile back.
--
Alvaro Herrera http://www.amazon.com/gp/registry/CTMLCN8V17R4
"At least to kernel hackers, who really are human, despite occasional
rumors to the contrary" (LWN.net)
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Heikki Linnakangas | 2005-10-06 13:53:36 | Re: fixing LISTEN/NOTIFY |
| Previous Message | Martijn van Oosterhout | 2005-10-06 13:48:59 | Re: prefix btree implementation |