On 11/10/16 21:54, Merlin Moncure wrote:
> 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.
>
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
