Re: Does a row lock taken out in a CTE stay in place?

From: "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com>
To: Seamus Abshere <seamus(at)abshere(dot)net>
Cc: "pgsql-general(at)postgresql(dot)org" <pgsql-general(at)postgresql(dot)org>
Subject: Re: Does a row lock taken out in a CTE stay in place?
Date: 2017-07-11 15:47:09
Message-ID: CAKFQuwY4cgVXyKo5Uorgm4EMOrYvQNT973gj5ZHHRwGjKxhBQQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

On Tue, Jul 11, 2017 at 8:36 AM, Seamus Abshere <seamus(at)abshere(dot)net> wrote:

> Given an update that uses CTEs like this:
>
> WITH
> lock_rows AS (
> SELECT 1 FROM tbl WHERE [...] FOR UPDATE
> )
> UPDATE [...]
>
> Will the rows in `tbl` remain locked until the UPDATE is finished?
>
>
​Yes​ - locks persist to the end of the transaction. Using a CTE doesn't
constitute creating a new statement.

Also, does it matter if `lock_rows` is referenced? (IIUC the query
> wouldn't be run if the CTE isn't referenced if it was for a SELECT, but
> since it's an UPDATE, it will be run anyway
> ​.
>

​Pretty sure it will not be. The EXPLAIN​ command should be able to
provide a more definitive answer.

If the UPDATE was inside the CTE it definitely would be run regardless of
outer query references. I'm not sure if the FOR UPDATE impacts whether the
select needs to be executed by I'm thinking no since it doesn't change the
semantics of the query.

David J.

In response to

Browse pgsql-general by date

  From Date Subject
Next Message Jason Dusek 2017-07-11 17:24:11 Re: Imperative Query Languages
Previous Message Tom Lane 2017-07-11 15:45:45 Re: Does a row lock taken out in a CTE stay in place?