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:

Reply via email to