Re: Race condition with libpq

Поиск
Список
Период
Сортировка
От Dietmar May
Тема Re: Race condition with libpq
Дата
Msg-id 00a001c323a6$cbb02d90$fb02a8c0@muskrat
обсуждение исходный текст
Ответ на Re: Race condition with libpq  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-interfaces
Thanks Tom,

> You're missing the point.  It's the DROP that's failing, not the CREATE,
> and it's failing because the old backend is still connected to the
> victim database.

Actually, I understand that it's the DROP that's failing. What I didn't
understand is that connection closure was asynchronous, but everything else
is synchronous.

So, why can't the server-side code that closes the connection release any
resources associated with that connection before the socket is closed? It
seems that doing so could fix this problem quite cleanly.

> [template1] is not used for any "internal" operations.  It is
> conventionally present so that clients have a standard place to
> connect to.

Perhaps I'm misunderstanding the manual - "4.1: When a new database is
created, the template database [template1] is essentially cloned. This means
that any changes you make in template1 are propagated to all subsequently
created databases."

Thanks again for your quick response,
Dietmar



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

Предыдущее
От: "Dietmar May"
Дата:
Сообщение: Re: Race condition with libpq
Следующее
От: "Dietmar May"
Дата:
Сообщение: Re: Race condition with libpq