On 2020-Aug-26, Robert Haas wrote:
> On Wed, Aug 26, 2020 at 7:47 AM Dagfinn Ilmari Mannsåker
> wrote:
> > Would it be possible to make the compat versions only available when
> > building extensions, but not to core code?
>
> I think that would be good if we can do it. We could even have it
> i
On Wed, Aug 26, 2020 at 7:47 AM Dagfinn Ilmari Mannsåker
wrote:
> Would it be possible to make the compat versions only available when
> building extensions, but not to core code?
I think that would be good if we can do it. We could even have it
inside #ifdef LWLOCK_API_COMPAT, and extension auth
Andres Freund writes:
> Hi,
>
> On 2020-08-25 13:59:35 -0400, Robert Haas wrote:
>
>> However, if we do it all in a backward-compatible way as you propose,
>> then we're likely to keep reintroducing code that does it the old way
>> for a really long time. I'm not sure that actually makes a lot of
On Mon, Aug 24, 2020 at 3:35 PM Andres Freund wrote:
> To avoid unnecessary backward compat pains it seems best to first
> introduce compat wrappers using the current signature, and then
> subsequently replace in-core callers with the direct calls.
I like the idea of doing this, purely to make pr
Hi,
On 2020-08-25 14:22:28 -0400, Robert Haas wrote:
> On Tue, Aug 25, 2020 at 2:17 PM Andres Freund wrote:
> > It seems easy enough to slap a compiler "enforced" deprecation warning
> > on the new compat version, in master only. Seems unnecessary to make
> > life immediately harder for extension
On Tue, Aug 25, 2020 at 2:17 PM Andres Freund wrote:
> It seems easy enough to slap a compiler "enforced" deprecation warning
> on the new compat version, in master only. Seems unnecessary to make
> life immediately harder for extensions authors desiring cross-version
> compatibility.
I don't kno
Hi,
On 2020-08-25 13:59:35 -0400, Robert Haas wrote:
> On Mon, Aug 24, 2020 at 6:35 PM Andres Freund wrote:
> > Thoughts?
>
> This is likely to cause a certain amount of annoyance to many
> PostgreSQL developers, but if you have evidence that it will improve
> performance significantly, I think
On Mon, Aug 24, 2020 at 6:35 PM Andres Freund wrote:
> Thoughts?
This is likely to cause a certain amount of annoyance to many
PostgreSQL developers, but if you have evidence that it will improve
performance significantly, I think it's very reasonable to do it
anyway. However, if we do it all in
Hi,
Currently lwlock acquisition, whether direct, or via the LockBuffer()
wrapper, have a mode argument. I don't like that much, for three
reasons:
1) I've tried to add annotations for static analyzers to help with
locking correctness. The ones I looked at don't support annotating
shared/ex
