On Thu, Apr 14, 2016 at 2:00 PM, Pavel Stehule wrote:
>>> You don't need a separate shared memory segment. You might want to
>>> have a look at what we did for pldebugger:
>>>
>>> http://git.postgresql.org/gitweb/?p=pldebugger.git;a=commitdiff;h=14c6caf08bb14a7404a8241e47a80ef5f97e451e
>>>
>>> I
2016-04-12 15:15 GMT+02:00 Pavel Stehule :
>
>
> 2016-04-12 14:51 GMT+02:00 Robert Haas :
>
>> On Tue, Apr 12, 2016 at 4:18 AM, Pavel Stehule
>> wrote:
>> > If there will be simple way, how to fix it, then I'll fix my
>> extensions. But
>> > new API is working only when the extension has own shar
2016-04-12 14:51 GMT+02:00 Robert Haas :
> On Tue, Apr 12, 2016 at 4:18 AM, Pavel Stehule
> wrote:
> > If there will be simple way, how to fix it, then I'll fix my extensions.
> But
> > new API is working only when the extension has own share memory segment.
> For
> > some complex extensions like
On Tue, Apr 12, 2016 at 4:18 AM, Pavel Stehule wrote:
> If there will be simple way, how to fix it, then I'll fix my extensions. But
> new API is working only when the extension has own share memory segment. For
> some complex extensions like Orafce it means expensive refactoring.
>
> What is wors
Hi
2016-02-13 15:54 GMT+01:00 Tom Lane :
> Simon Riggs writes:
> > On 10 February 2016 at 16:36, Tom Lane wrote:
> >> FWIW, I wasn't paying attention either, but I'm convinced by Robert's
> >> argument. Avoiding coupling between extensions is worth an API break.
>
> > Old APIs - why can't we k
Simon Riggs writes:
> On 10 February 2016 at 16:36, Tom Lane wrote:
>> FWIW, I wasn't paying attention either, but I'm convinced by Robert's
>> argument. Avoiding coupling between extensions is worth an API break.
> Old APIs - why can't we keep it?
Because with the old API, a bug in extension
On 10 February 2016 at 16:36, Tom Lane wrote:
> Robert Haas writes:
> > On Wed, Feb 10, 2016 at 11:08 AM, Heikki Linnakangas
> wrote:
> >> (Sorry if this was discussed already, I haven't been paying attention)
> >>
> >> LWLockAssign() is used by extensions. Are we OK with just breaking them,
>
2016-02-13 6:32 GMT+01:00 Robert Haas :
> On Sat, Feb 13, 2016 at 12:20 AM, Pavel Stehule
> wrote:
> >> Hmm. So orafce is actually benefiting from the 3-lwlock slop that was
> >> built into the old system: if one of those original 3 locks was
> >> as-yet-unclaimed, orafce grabs it when it initia
On Sat, Feb 13, 2016 at 12:20 AM, Pavel Stehule wrote:
>> Hmm. So orafce is actually benefiting from the 3-lwlock slop that was
>> built into the old system: if one of those original 3 locks was
>> as-yet-unclaimed, orafce grabs it when it initializes. The new system
>> hasn't got that slop, and
2016-02-13 4:52 GMT+01:00 Robert Haas :
> On Fri, Feb 12, 2016 at 1:08 PM, Pavel Stehule
> wrote:
> >> I got a error
> >>
> >> ERROR: XX000: requested tranche is not registered
> >> LOCATION: GetNamedLWLockTranche, lwlock.c:602
> >>
> >> Because the session initialization doesn't finish, then O
On Fri, Feb 12, 2016 at 1:08 PM, Pavel Stehule wrote:
>> I got a error
>>
>> ERROR: XX000: requested tranche is not registered
>> LOCATION: GetNamedLWLockTranche, lwlock.c:602
>>
>> Because the session initialization doesn't finish, then Orafce doesn't
>> work
>
> I am starting to understand - t
2016-02-12 17:35 GMT+01:00 Pavel Stehule :
>
>
> 2016-02-12 15:46 GMT+01:00 Pavel Stehule :
>
>>
>>
>> 2016-02-12 15:43 GMT+01:00 Robert Haas :
>>
>>> On Fri, Feb 12, 2016 at 8:16 AM, Pavel Stehule
>>> wrote:
>>> >> That's very strange. It looks to me like you did exactly the right
>>> >> thing.
2016-02-12 15:46 GMT+01:00 Pavel Stehule :
>
>
> 2016-02-12 15:43 GMT+01:00 Robert Haas :
>
>> On Fri, Feb 12, 2016 at 8:16 AM, Pavel Stehule
>> wrote:
>> >> That's very strange. It looks to me like you did exactly the right
>> >> thing. Can you provide any details on how it fails?
>> >
>> > Lo
2016-02-12 15:43 GMT+01:00 Robert Haas :
> On Fri, Feb 12, 2016 at 8:16 AM, Pavel Stehule
> wrote:
> >> That's very strange. It looks to me like you did exactly the right
> >> thing. Can you provide any details on how it fails?
> >
> > Looks like some race conditions is there - but I didn't tes
On Fri, Feb 12, 2016 at 8:16 AM, Pavel Stehule wrote:
>> That's very strange. It looks to me like you did exactly the right
>> thing. Can you provide any details on how it fails?
>
> Looks like some race conditions is there - but I didn't tested it deeper
Well, OK, so I'm totally willing to wor
2016-02-12 14:10 GMT+01:00 Robert Haas :
> On Fri, Feb 12, 2016 at 3:33 AM, Pavel Stehule
> wrote:
> >> There will be necessary more changes than this. Orafce has some parts
> >> based on lw locks. I am able to compile it without any issue. But the
> lock
> >> mechanism is broken now - so impact
On Fri, Feb 12, 2016 at 3:33 AM, Pavel Stehule wrote:
>> There will be necessary more changes than this. Orafce has some parts
>> based on lw locks. I am able to compile it without any issue. But the lock
>> mechanism is broken now - so impact on extensions will be higher. Have to do
>> some resea
2016-02-12 10:37 GMT+01:00 Amit Kapila :
> On Fri, Feb 12, 2016 at 2:03 PM, Pavel Stehule
> wrote:
>
>>
>>
>> There will be necessary more changes than this. Orafce has some parts
>>> based on lw locks. I am able to compile it without any issue. But the lock
>>> mechanism is broken now - so impac
On Fri, Feb 12, 2016 at 2:03 PM, Pavel Stehule
wrote:
>
>
> There will be necessary more changes than this. Orafce has some parts
>> based on lw locks. I am able to compile it without any issue. But the lock
>> mechanism is broken now - so impact on extensions will be higher. Have to
>> do some r
There will be necessary more changes than this. Orafce has some parts based
> on lw locks. I am able to compile it without any issue. But the lock
> mechanism is broken now - so impact on extensions will be higher. Have to
> do some research.
>
if somebody would to use it for testing
https://gith
2016-02-10 17:21 GMT+01:00 Robert Haas :
> On Wed, Feb 10, 2016 at 11:08 AM, Heikki Linnakangas
> wrote:
> > On 10/02/16 17:12, Robert Haas wrote:
> >> Code cleanup in the wake of recent LWLock refactoring.
> >>
> >> As of commit c1772ad9225641c921545b35c84ee478c326b95e, there's no
> >> longer an
On 11 February 2016 at 00:21, Robert Haas wrote:
>
>
> If there's a strong feeling that we should keep the old APIs around,
> we can do that, but I think that (1) if we don't remove them now, we
> probably never will and (2) they are vile APIs.
Yep.
Delete 'em.
Things regularly change between
Robert Haas writes:
> On Wed, Feb 10, 2016 at 11:08 AM, Heikki Linnakangas wrote:
>> (Sorry if this was discussed already, I haven't been paying attention)
>>
>> LWLockAssign() is used by extensions. Are we OK with just breaking them,
>> requiring them to change LWLockAssign() with the new mecha
On Wed, Feb 10, 2016 at 11:08 AM, Heikki Linnakangas wrote:
> On 10/02/16 17:12, Robert Haas wrote:
>> Code cleanup in the wake of recent LWLock refactoring.
>>
>> As of commit c1772ad9225641c921545b35c84ee478c326b95e, there's no
>> longer any way of requesting additional LWLocks in the main tranc
24 matches
Mail list logo
