po 1. 1. 2024 v 12:15 odesílatel Ivan Kush
napsal:
>
> On 01.01.2024 09:47, Pavel Stehule wrote:
> >
> >
> > All use cases of pg_background, except asynchronous execution. If
> > later
> > add asynchronous execution, then all =)
> >
> > For example, also:
> >
> > * conversion
On 01.01.2024 09:47, Pavel Stehule wrote:
All use cases of pg_background, except asynchronous execution. If
later
add asynchronous execution, then all =)
For example, also:
* conversion from Oracle's `PRAGMA AUTONOMOUS` to Postgres.
* possibility to create
Hi
ne 31. 12. 2023 v 15:15 odesílatel Ivan Kush
napsal:
>
> On 24.12.2023 15:38, Pavel Stehule wrote:
> > Can you show some benchmarks? I don't like this system too much but
> > maybe it can work enough.
> >
> > Still I am interested in possible use cases. If it should be used only
> > for
On 24.12.2023 15:38, Pavel Stehule wrote:
Can you show some benchmarks? I don't like this system too much but
maybe it can work enough.
Still I am interested in possible use cases. If it should be used only
for logging, then we can implement something less generic, but surely
with better
Hi
ne 24. 12. 2023 v 12:27 odesílatel Ivan Kush
napsal:
> > 1. The solution based on background workers looks too fragile - it
> can be easy to exhaust all background workers, and because this feature
> is proposed mainly for logging, then it is a little bit dangerous,
> because it means loss
> Is anyone else using backgroud connections?
Don't know at the current time. Maybe EnterpriseDB uses bgworkers as
Peter Eisentraut works there currently (LinkedIn says =)) And in 2016
he has proposed a patch with autonomous transactions with bgworkers.
> 1. The solution based on background workers looks too fragile - it
can be easy to exhaust all background workers, and because this feature
is proposed mainly for logging, then it is a little bit dangerous,
because it means loss of possibility of logging.
1. We could add types for background
> On 15 Dec 2023, at 16:28, Ivan Kush wrote:
>
>
>
> Hello. I'm working on the support of autonomous transactions in Postgres.
>
> # Summary
> * Add pragma AUTONOMOUS_TRANSACTION in the functions. When function
> contains this pragma, the it's executed autonomously
> * Background workers
Hi
although I like the idea related to autonomous transactions, I don't think
so this way is the best
1. The solution based on background workers looks too fragile - it can be
easy to exhaust all background workers, and because this feature is
proposed mainly for logging, then it is a little bit
