Re: rfc - libpq extensions
От | Iker Arizmendi |
---|---|
Тема | Re: rfc - libpq extensions |
Дата | |
Msg-id | 20030110151623.45dafd8b.iker@research.att.com обсуждение исходный текст |
Ответ на | Re: rfc - libpq extensions (Csaba Nagy <nagy@domeus.de>) |
Список | pgsql-general |
On Fri, 10 Jan 2003 18:37:52 +0100 Csaba Nagy <nagy@domeus.de> wrote: > AFAIK Using the same connection to do more queries at the same time is > not supported by the backend. > If you use transactions, it will only make your life harder to make > sure the transaction goes on on the same connection, and nobody else > uses the same connection meanwhile, messing with your ongoing > transaction... unless the postgres developers would be willing to > implement connection independent transactions (by the means of a > transaction ID passed along with the query ? this is DB sience fiction > - might be good but it's not standard nor really needed). > By using something like virtual (or "soft") connections (see my previous post) it's relatively straight forward to make sure that several queries that form a single transaction get the same DB connection. Once a transaction is started on a virtual connection and the VC gets a hold of a database connection it can simply hold on to it until the transaction is finalized. If another virtual connection is waiting for a DB connection it will just queue its queries and wait for one to become available. Once it gets it, it will hold it for the duration of one query (for non TX queries) or several queries (eg, "BEGIN", "INSERT..", "UPDATE..", "COMMIT"). > I assume your problems with connection pooling are the relatively big > setup time of a connection, and the possibility of running out of > connections... I think the more pressing problem for the connection-pooled, event-driven server is that it cannot block to wait for a connection (for whatever reason). At the same time it's pretty cumbersome for an application developer to have to manually queue queries during the wait. Regards, Iker
В списке pgsql-general по дате отправления: