|
|
|
Время жизни dblink_connect?
|
|||
|---|---|---|---|
|
#18+
Сколько существует коннект, созданный dblink_connect? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.08.2015, 14:49 |
|
||
|
Время жизни dblink_connect?
|
|||
|---|---|---|---|
|
#18+
Winnipuh, 1. пока не скажете dblink_disconnect -- из родительского сеанса 2. или pg_terminate_backend(пид) -- откуда угодно 3 . или не закроете родительскую сессию. ... <и т.п.> ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.08.2015, 14:58 |
|
||
|
Время жизни dblink_connect?
|
|||
|---|---|---|---|
|
#18+
Вот интересно, можно сделать такое же, но постоянное, где-то запомненное, что-то типа Linked Server как в SQL Server, то есть чтобы постоянно существовал? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.08.2015, 19:54 |
|
||
|
Время жизни dblink_connect?
|
|||
|---|---|---|---|
|
#18+
WinnipuhВот интересно, можно сделать такое же, но постоянное, где-то запомненное, что-то типа Linked Server как в SQL Server, то есть чтобы постоянно существовал? постоянно в смысле автоматически в любом новом коннекте выданном приложению? через pgbouncer легко... делаете хранимку которая вызывает этот dblink connect и ставите ее в connect_query='SELECT вашахранимка();' в pgbouncer в настройках вашего пула. " connect_query Query to be executed after a connection is established, but before allowing the connection to be used by any clients. " Через connect_query вообще можно много интересной инициализационной логики накрутить типа создания "постоянных временных таблиц" И тд и тп. -- Maxim Boguk www.postgresql-consulting.ru ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.08.2015, 04:47 |
|
||
|
Время жизни dblink_connect?
|
|||
|---|---|---|---|
|
#18+
Maxim BogukWinnipuhВот интересно, можно сделать такое же, но постоянное, где-то запомненное, что-то типа Linked Server как в SQL Server, то есть чтобы постоянно существовал? постоянно в смысле автоматически в любом новом коннекте выданном приложению? через pgbouncer легко... делаете хранимку которая вызывает этот dblink connect и ставите ее в connect_query='SELECT вашахранимка();' в pgbouncer в настройках вашего пула. " connect_query Query to be executed after a connection is established, but before allowing the connection to be used by any clients. " Через connect_query вообще можно много интересной инициализационной логики накрутить типа создания "постоянных временных таблиц" И тд и тп. -- Maxim Boguk www.postgresql-consulting.ru возможно, это то, что нужно ТС, но я думаю, что нет. мне бы хотелось иметь расшаренное соединения (конкретный пид) -- чтобы из любого другого получать именно его -- с его окружением. я бы через него обменивался. Т.е. нужно именованное соединение, доступное по имени из любого другого (если не занято). а баунсер, даже если [случайно] выдаст вам нужное, сделает сразу discard all если я не прав -- то в цитате не хватает деталей. а то , что про баунсер -- с той же точностью -- через [fdw] сервера -- открываете соединение dblink, вместо строки соединения -- имя сервера -- и делов. накладные -- каждое обращение через создание нового соединения -- решаемо ... тем же баунсером. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.08.2015, 15:37 |
|
||
|
Время жизни dblink_connect?
|
|||
|---|---|---|---|
|
#18+
qwwqвозможно, это то, что нужно ТС, но я думаю, что нет. мне бы хотелось иметь расшаренное соединения (конкретный пид) -- чтобы из любого другого получать именно его -- с его окружением. я бы через него обменивался. Т.е. нужно именованное соединение, доступное по имени из любого другого (если не занято). а баунсер, даже если [случайно] выдаст вам нужное, сделает сразу discard all если я не прав -- то в цитате не хватает деталей. а то , что про баунсер -- с той же точностью -- через [fdw] сервера -- открываете соединение dblink, вместо строки соединения -- имя сервера -- и делов. накладные -- каждое обращение через создание нового соединения -- решаемо ... тем же баунсером. 1)C расшаренным dblink на всех ничего не получится в текущих версиях. 2)а зачем pgbouncer в transaction pooling mode то discard all; то делать???? Чтобы сбросить все что в connect_query сделали??? Из официальной документации: "When transaction pooling is used, the server_reset_query should be empty, as clients should not use any session features. If client does use session features, then they will be broken as transaction pooling will not guarantee that next query will be run on same connection." А без discard all; все выданные клиентам соединения будут всегда иметь установленный dblink готовый к использованию (ну почти всегда конечно, если оно оборвется по каким то причинам то клиент должен это корректно обрабатывать). PS: автору топика стоит в сторону FDW смотреть а не в сторону dblink, FDW автоматом открывает соединение при первом обращении в foreign серверу: "postgres_fdw establishes a connection to a foreign server during the first query that uses a foreign table associated with the foreign server. This connection is kept and re-used for subsequent queries in the same session. However, if multiple user identities (user mappings) are used to access the foreign server, a connection is established for each user mapping." см: http://www.postgresql.org/docs/9.4/static/postgres-fdw.html -- Maxim Boguk www.postgresql-consulting.ru ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.08.2015, 08:17 |
|
||
|
Время жизни dblink_connect?
|
|||
|---|---|---|---|
|
#18+
[quot Maxim Boguk]qwwqвозможно, это то, что нужно ТС, но я думаю, что нет. мне бы хотелось иметь расшаренное соединения (конкретный пид) -- чтобы из любого другого получать именно его -- с его окружением. я бы через него обменивался. Т.е. нужно именованное соединение, доступное по имени из любого другого (если не занято). а баунсер, даже если [случайно] выдаст вам нужное, сделает сразу discard all если я не прав -- то в цитате не хватает деталей. а то , что про баунсер -- с той же точностью -- через [fdw] сервера -- открываете соединение dblink, вместо строки соединения -- имя сервера -- и делов. накладные -- каждое обращение через создание нового соединения -- решаемо ... тем же баунсером. 1)C расшаренным dblink на всех ничего не получится в текущих версиях. 2)а зачем pgbouncer в transaction pooling mode то discard all; то делать???? Чтобы сбросить все что в connect_query сделали??? Из официальной документации: "When transaction pooling is used, the server_reset_query should be empty, as clients should not use any session features. If client does use session features, then they will be broken as transaction pooling will not guarantee that next query will be run on same connection." А без discard all; все выданные клиентам соединения будут всегда иметь установленный dblink готовый к использованию (ну почти всегда конечно, если оно оборвется по каким то причинам то клиент должен это корректно обрабатывать). PS: автору топика стоит в сторону FDW смотреть а не в сторону dblink, FDW автоматом открывает соединение при первом обращении в foreign серверу: "postgres_fdw establishes a connection to a foreign server during the first query that uses a foreign table associated with the foreign server. This connection is kept and re-used for subsequent queries in the same session. However, if multiple user identities (user mappings) are used to access the foreign server, a connection is established for each user mapping." см: http://www.postgresql.org/docs/9.4/static/postgres-fdw.html Да, видимо FDW, но я тут рядом открывал тему про FDW, какие-то они недоделанные немножко. Скажем мне надо версию для Windows: sqlite_fdw - нашел, даже работает, но только на чтение, tds_fdw - а нету. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.08.2015, 11:29 |
|
||
|
|

start [/forum/topic.php?fid=53&tid=1997819]: |
0ms |
get settings: |
10ms |
get forum list: |
14ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
165ms |
get topic data: |
9ms |
get forum data: |
2ms |
get page messages: |
42ms |
get tp. blocked users: |
1ms |
| others: | 246ms |
| total: | 495ms |

| 0 / 0 |
