On 11/10/16 21:54, Merlin Moncure wrote: > On Tue, Oct 11, 2016 at 10:06 AM, Petr Jelinek <p...@2ndquadrant.com> wrote: >> On 10/10/16 16:44, Merlin Moncure wrote: >>> On Thu, Oct 6, 2016 at 3:53 PM, Simon Riggs <si...@2ndquadrant.com> wrote: >>>> On 6 October 2016 at 21:27, Robert Haas <robertmh...@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. >
Yes, I am just saying we should have both. I don't feel like I can judge if background transactions solve autonomous transactions use-cases so I am not expressing opinion there. -- Petr Jelinek http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
