The autonomous session runs in a separate process. The main process and autonomous session communicate over the standard frontend/backend protocol. Execution of autonomous session is synchronous, main process waits Complete message from autonomous session. Messages are sent through shared memory queues.

Autonomous session is taken from the pool of autonomous sessions. For each process, that calls autonomous function a separate pool is created. That means, that if the 1st autonomous function calls a 2nd autonomous function, then 1st autonomous session also creates a personal pool of sessions. A background worker process is launched when starting the autonomous session. It establishes a database connection as the authenticated user. The session parameters like search_path are copied from the main session. Maximum size of the pool is 100.

As autonomous session is a separate process, it contains caches, etc. In order to prevent infinite grow of resources usage we reset all caches by timeout using restart of autonomous sessions. This timeout is set by guc setting `autonomous_session_lifetime`.

SQL commands are prepared on the autonomous worker and executed using the extended query protocol. Parameter values are passed from the main session's variables. Result rows are returned over the protocol. Errors and notices are propagated to the main session and re-thrown.

Cursors, prepared statements, dynamic sql with the placeholders for parameters require additional protocol support not yet.

The autonomous session infrastructure can support other use cases like parallel query workers. The separation of query execution from the main session provides additional flexibility. However, no performance benefit is expected over current parallel query mechanisms.