From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
Cc: | David Rowley <david(dot)rowley(at)2ndquadrant(dot)com>, Andres Freund <andres(at)anarazel(dot)de>, Tomas Vondra <tomas(dot)vondra(at)2ndquadrant(dot)com>, John Naylor <john(dot)naylor(at)2ndquadrant(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | Re: Delay locking partitions during INSERT and UPDATE |
Date: | 2019-02-21 01:18:05 |
Message-ID: | 795.1550711885@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> On Wed, Feb 20, 2019 at 3:57 PM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> Looking at the patch itself, I agree that a bit more attention to comments
>> is needed, and I wonder whether David has found all the places where
>> it's now necessary to s/NoLock/RowExclusiveLock/. I don't have any
>> other objections.
> I spent some time thinking about that exact issue this morning and
> studying the code to try to figure that out. I wasn't able to find
> any other places that seemed to need updating, but it could be that I
> missed something that David also missed.
Actually, in the wake of b04aeb0a0, we probably need not be too stressed
about the possibility that we missed something. Those assertions wouldn't
detect doing an unwanted lock upgrade, but I think that's unlikely to be
an issue here (or if it is, we have the problem anyway).
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | David Rowley | 2019-02-21 01:29:33 | Re: BUG #15572: Misleading message reported by "Drop function operation" on DB with functions having same name |
Previous Message | Tom Lane | 2019-02-21 01:12:55 | Re: libpq host/hostaddr/conninfo inconsistencies |