On Tue, Oct 11, 2016 at 10:06 AM, Petr Jelinek <petr@2ndquadrant.com> wrote: > On 10/10/16 16:44, Merlin Moncure wrote: >> On Thu, Oct 6, 2016 at 3:53 PM, Simon Riggs <simon@2ndquadrant.com> wrote: >>> On 6 October 2016 at 21:27, Robert Haas <robertmhaas@gmail.com> wrote: >>>> I think we should implement background transactions and call them >>>> background transactions. That allows us to expose additional >>>> functionality which is useful, like the ability to kick something off >>>> and check back later for the results. There's no reason to call it >>>> background transactions and also call it autonomous transactions: one >>>> feature doesn't need two names. >>> >>> I'm happy to also invoke it via an alternate mechanism or API, so that >>> it can continue to be used even if the above mechanism changes. >>> >>> We have no need to wait for the perfect solution, even assuming we >>> would ever agree that just one exists. >> >> -1 on implementing both autonomous and background transactions. This >> will confuse everyone. > > I personally care much more about having background transactions than > autonomous ones (as I only ever had use-cases for the background ones) > so don't agree there.
All right. But would you agree then that AT should at least emulate competing implementations? A major advantage of bgworkers is possibly supporting concurrent activity and maybe the syntax could be more directed to possibly moving in that direction other than copying oracle style (PRAGMA etc), particularly if the locking rules are substantially different.
There is a big trap - AT is usually used for writing to log tables. When BT fails on maximum active workers then, then you cannot do any expected operation.
