Re: Locking and postgres_fdw extension

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Steve Baldwin <steve(dot)baldwin(at)gmail(dot)com>
Cc: pgsql-general <pgsql-general(at)postgresql(dot)org>
Subject: Re: Locking and postgres_fdw extension
Date: 2020-11-20 06:29:17
Message-ID: 1277128.1605853757@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

Steve Baldwin <steve(dot)baldwin(at)gmail(dot)com> writes:
> However if I want it to fail immediately if unable to obtain the lock, it
> seems nowait is ignored for foreign tables (or at least with my version of
> postgres_fdw).

Hmm ... this seems to be intentional, per the comments in
deparseLockingClause():

* For now, just ignore any [NO] KEY specification, since (a)
* it's not clear what that means for a remote table that we
* don't have complete information about, and (b) it wouldn't
* work anyway on older remote servers. Likewise, we don't
* worry about NOWAIT.

However, it's not super clear whether the concern about NOWAIT is just
that the remote server might be too old to know that keyword, or
whether there's some deeper issue.

(I see your example is also falling foul of the non-implementation
of NO KEY, which might be confusing matters still more.)

regards, tom lane

In response to

Browse pgsql-general by date

  From Date Subject
Next Message Dirk Mika 2020-11-20 07:13:42 Set COLLATE on a session level
Previous Message Tom Lane 2020-11-20 06:17:58 Re: received immediate shutdown request caused cluster failover