Re: postgres_fdw - cached connection leaks if the associated user mapping/foreign server is dropped

Поиск
Список
Период
Сортировка
От Fujii Masao
Тема Re: postgres_fdw - cached connection leaks if the associated user mapping/foreign server is dropped
Дата
Msg-id 8161aa69-1484-1be3-3cb8-757b48cc959b@oss.nttdata.com
обсуждение исходный текст
Ответ на Re: postgres_fdw - cached connection leaks if the associated user mapping/foreign server is dropped  (Bharath Rupireddy <bharath.rupireddyforpostgres@gmail.com>)
Ответы Re: postgres_fdw - cached connection leaks if the associated user mapping/foreign server is dropped  (Bharath Rupireddy <bharath.rupireddyforpostgres@gmail.com>)
Список pgsql-hackers

On 2020/12/23 23:40, Bharath Rupireddy wrote:
> On Wed, Dec 23, 2020 at 7:31 PM Fujii Masao <masao.fujii@oss.nttdata.com> wrote:
>> I agree to make pgfdw_xact_callback() close the connection when
>> entry->invalidated == true. But I think that it's better to get rid of
>> have_invalid_connections flag and make pgfdw_inval_callback() close
>> the connection immediately if entry->xact_depth == 0, to avoid unnecessary
>> scan of the hashtable during COMMIT of transaction not accessing to
>> foreign servers. Attached is the POC patch that I'm thinking. Thought?
> 
> We could do that way as well. It seems okay to me. Now the disconnect
> code is spread in pgfdw_inval_callback() and pgfdw_xact_callback().
> There's also less burden on pgfdw_xact_callback() to close a lot of
> connections on a single commit. The behaviour is like this - If
> entry->xact_depth == 0, then the entries wouldn't have got any
> connection in the current txn so they can be immediately closed in
> pgfdw_inval_callback() and pgfdw_xact_callback() can exit immediately
> as xact_got_connection is false. If entry->xact_depth > 0 which means
> that probably pgfdw_inval_callback() came from a sub txn, we would
> have got a connection in the txn i.e. xact_got_connection becomes true
> due to which it can get invalidated in pgfdw_inval_callback() and get
> closed in pgfdw_xact_callback() at the end of the txn.
> 
> And there's no chance of entry->xact_depth > 0 and xact_got_connection false.
> 
> I think we need to change the comment before pgfdw_inval_callback() a bit:
> 
>   * After a change to a pg_foreign_server or pg_user_mapping catalog entry,
>   * mark connections depending on that entry as needing to be remade.
>   * We can't immediately destroy them, since they might be in the midst of
>   * a transaction, but we'll remake them at the next opportunity.
> 
> to
> 
>   * After a change to a pg_foreign_server or pg_user_mapping catalog entry,
> *  try to close the cached connections associated with them if they
> are not in the
> *  midst of a transaction otherwise mark them as invalidated. We will
> destroy the
>   * invalidated connections in pgfdw_xact_callback() at the end of the main xact.
>   * Closed connections will be remade at the next opportunity.

Yes, I agree that we need to update that comment.

> 
> Any thoughts on the earlier point in [1] related to a test case(which
> becomes unnecessary with this patch) coverage?
> 

ISTM that we can leave that test as it is because it's still useful to test
the case where the cached connection is discarded in pgfdw_inval_callback().
Thought?

By applying the patch, probably we can get rid of the code to discard
the invalidated cached connection in GetConnection(). But at least for
the back branches, I'd like to leave the code as it is so that we can make
sure that the invalidated cached connection doesn't exist when getting
new connection. Maybe we can improve that in the master, but I'm not
sure if it's really worth doing that against the gain. Thought?

Regards,

-- 
Fujii Masao
Advanced Computing Technology Center
Research and Development Headquarters
NTT DATA CORPORATION



В списке pgsql-hackers по дате отправления:

Предыдущее
От: "osumi.takamichi@fujitsu.com"
Дата:
Сообщение: RE: how to use valgrind for TAP tests
Следующее
От: Michael Paquier
Дата:
Сообщение: Re: Fail Fast In CTAS/CMV If Relation Already Exists To Avoid Unnecessary Rewrite, Planning Costs