| From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
|---|---|
| To: | Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com> |
| Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Thomas Munro <thomas(dot)munro(at)enterprisedb(dot)com>, Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: [HACKERS] Moving relation extension locks out of heavyweight lock manager |
| Date: | 2017-12-01 20:32:00 |
| Message-ID: | CA+TgmoaJd1uRKpw8iT1RmYojbhfe58=HU5P8scX02icXRZ-xnQ@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Fri, Dec 1, 2017 at 1:28 PM, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
> [ lots of minor comments ]
When I took a break from sitting at the computer, I realized that I
think this has a more serious problem: won't it permanently leak
reference counts if someone hits ^C or an error occurs while the lock
is held? I think it will -- it probably needs to do cleanup at the
places where we do LWLockReleaseAll() that includes decrementing the
shared refcount if necessary, rather than doing cleanup at the places
we release heavyweight locks.
I might be wrong about the details here -- this is off the top of my head.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tomas Vondra | 2017-12-01 20:47:43 | Re: [HACKERS] Custom compression methods |
| Previous Message | Robert Haas | 2017-12-01 20:28:00 | Re: [HACKERS] Transaction control in procedures |