| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Hannes Erven <hannes(at)erven(dot)at> |
| Cc: | pgsql-general <pgsql-general(at)postgresql(dot)org> |
| Subject: | Re: Postgresql the right tool (queue using advisory_locks + long transactions) |
| Date: | 2014-04-27 21:24:08 |
| Message-ID: | 26485.1398633848@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-general |
Hannes Erven <hannes(at)erven(dot)at> writes:
> On 2014-04-27 21:53, Tom Lane wrote:
>> Sitting on an open transaction for hours would be a bad idea.
> I'm wondering why this is and what the consequences might be - I
> thought, the MVCC model would handle that rather well?
Vacuum can't delete dead rows if there's some transaction that can still
see them. So long-running transactions + update activity = table bloat.
(I had the idea that we'd fixed this, in recent releases, if you're using
READ COMMITTED isolation level; but some experimentation says VACUUM still
won't release rows while there are idle transactions.)
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Dorian Hoxha | 2014-04-27 21:57:24 | Re: Altering array(composite-types) without breaking code when inserting them and similar questions |
| Previous Message | John R Pierce | 2014-04-27 21:13:01 | Re: Postgresql the right tool (queue using advisory_locks + long transactions) |