At Thu, 14 Apr 2022 11:13:01 -0400, Robert Haas wrote
in
> On Tue, Apr 12, 2022 at 6:55 AM Kyotaro Horiguchi
> wrote:
> > (My mailer has been fixed.)
>
> Cool.
>
> > So, I created the patches for back-patching from 10 to 14. (With
> > fixed a silly bug of the v1-pg14 that HaveVirtualXIDsDela
On Tue, Apr 12, 2022 at 6:55 AM Kyotaro Horiguchi
wrote:
> (My mailer has been fixed.)
Cool.
> So, I created the patches for back-patching from 10 to 14. (With
> fixed a silly bug of the v1-pg14 that HaveVirtualXIDsDelayingChkpt and
> HaveVirtualXIDsDelayingChkptEnd are inverted..)
I am very s
(My mailer has been fixed.)
At Mon, 11 Apr 2022 21:45:59 +0200, Markus Wanner
wrote in
> On Mon, 2022-04-11 at 15:21 -0400, Robert Haas wrote:
> > ... before v13, the commit in question actually
> > changed the size of PGXACT, which is really quite bad -- it needs to
> > be 12 bytes for perform
ot;[was: pgsql: ...]" tag, which Gmail subsequently displays as a
> different thread (that is, in my Gmail UI there's three "Re: API
> stability" threads, one of which has the [was: pgsql: ...]-tag, and
> two of which seem to be started by you as a reply on the original
&g
On Mon, 2022-04-11 at 15:21 -0400, Robert Haas wrote:
> ... before v13, the commit in question actually
> changed the size of PGXACT, which is really quite bad -- it needs to
> be 12 bytes for performance reasons. And there's no spare bytes
> available, so I think we should follow one of the sugges
On Fri, Apr 8, 2022 at 11:50 AM Robert Haas wrote:
> On Fri, Apr 8, 2022 at 4:47 AM Markus Wanner
> wrote:
> > I agree with Michael, it would be nice to not duplicate the code, but
> > use a common underlying method. A modified patch is attached.
>
> I don't think this is better, but I don't thi
On Mon, Apr 11, 2022 at 6:48 AM Matthias van de Meent
wrote:
> So, this might be the reason Robert overlooked your declaration to
> volunteer: he was looking for volunteers in the thread "Re: API
> Stability [was: pgsql: ...]" in the Gmail UI, which didn't show your
>
because of gmail not
putting this mail in the right thread: Your mail client dropped the
"[was: pgsql: ...]" tag, which Gmail subsequently displays as a
different thread (that is, in my Gmail UI there's three "Re: API
stability" threads, one of which has the [was: pgsql: ..
(a bit off-topic)
I'm not sure where I am..
At Wed, 06 Apr 2022 10:36:30 +0900 (JST), Kyotaro Horiguchi
wrote in
me> > this if nobody else would like to do it, but let me ask whether
me> > Kyotaro Horiguchi would like to propose a patch, since the original
me> > patch did, and/or whether you w
On Fri, Apr 8, 2022 at 4:47 AM Markus Wanner
wrote:
> I agree with Michael, it would be nice to not duplicate the code, but
> use a common underlying method. A modified patch is attached.
I don't think this is better, but I don't think it's worth arguing
about, either, so I'll do it this way if
On Fri, 2022-04-08 at 08:47 +0900, Michael Paquier wrote:
> On Thu, Apr 07, 2022 at 11:19:15AM -0400, Robert Haas wrote:
> > Here are patches for master and v14 to do things this way.
> > Comments?
>
> Thanks for the patches. They look correct.
+1, looks good to me and addresses my specific orig
On Thu, Apr 07, 2022 at 10:19:35PM -0400, Robert Haas wrote:
> Yeah, that's exactly why I didn't do what Michael proposes. If we're
> going to go to this trouble to avoid changing the layout of a PGPROC,
> we must be doing that on the theory that extension code cares about
> delayChkpt. And if that
On Thu, Apr 7, 2022 at 7:52 PM Tom Lane wrote:
> Michael Paquier writes:
> > On Thu, Apr 07, 2022 at 11:19:15AM -0400, Robert Haas wrote:
> >> Here are patches for master and v14 to do things this way. Comments?
>
> > Thanks for the patches. They look correct. For ~14, I'd rather avoid
> > the
(Mmm. My mailer automatically teared off the [was: ..] part from the
subject..)
--
Kyotaro Horiguchi
NTT Open Source Software Center
At Fri, 8 Apr 2022 08:47:42 +0900, Michael Paquier wrote
in
> On Thu, Apr 07, 2022 at 11:19:15AM -0400, Robert Haas wrote:
> > Here are patches for master and v14 to do things this way. Comments?
>
> Thanks for the patches. They look correct. For ~14, I'd rather avoid
> the code duplication d
Michael Paquier writes:
> On Thu, Apr 07, 2022 at 11:19:15AM -0400, Robert Haas wrote:
>> Here are patches for master and v14 to do things this way. Comments?
> Thanks for the patches. They look correct. For ~14, I'd rather avoid
> the code duplication done by GetVirtualXIDsDelayingChkptEnd() a
On Thu, Apr 07, 2022 at 11:19:15AM -0400, Robert Haas wrote:
> Here are patches for master and v14 to do things this way. Comments?
Thanks for the patches. They look correct. For ~14, I'd rather avoid
the code duplication done by GetVirtualXIDsDelayingChkptEnd() and
HaveVirtualXIDsDelayingChkpt(
> On 7. 4. 2022, at 17:19, Robert Haas wrote:
>
> On Tue, Apr 5, 2022 at 10:17 AM Tom Lane wrote:
>> What I think you need to do is:
>>
>> 1. In the back branches, revert delayChkpt to its previous type and
>> semantics. Squeeze a separate delayChkptEnd bool in somewhere
>> (you can't change
Robert Haas writes:
> Here are patches for master and v14 to do things this way. Comments?
WFM.
regards, tom lane
On Tue, Apr 5, 2022 at 10:17 AM Tom Lane wrote:
> What I think you need to do is:
>
> 1. In the back branches, revert delayChkpt to its previous type and
> semantics. Squeeze a separate delayChkptEnd bool in somewhere
> (you can't change the struct size either ...).
>
> 2. In HEAD, rename the fie
On Thu, Apr 7, 2022 at 2:28 AM Michael Paquier wrote:
> > Well, perhaps it's not the end of the world, but it's still a large
> > PITA for the maintainer of such an extension. They can't "just fix it"
> > because some percentage of their userbase will still need to compile
> > against older minor
On Tue, Apr 05, 2022 at 03:16:20PM -0400, Tom Lane wrote:
> Robert Haas writes:
>> On Tue, Apr 5, 2022 at 10:32 AM Tom Lane wrote:
>>> My point is that we want that to happen in HEAD, but it's not okay
>>> for it to happen in a minor release of a stable branch.
>
>> I understand, but I am not su
At Wed, 06 Apr 2022 18:13:17 +0900 (JST), Kyotaro Horiguchi
wrote in
> At Wed, 6 Apr 2022 10:30:32 +0200, Alvaro Herrera
> wrote in
> > For code documentation purposes, I think it is slightly better to use
> > bits8 than uint8 for variables where you're storing independent bit flags.
>
> Oh,
At Wed, 6 Apr 2022 10:30:32 +0200, Alvaro Herrera
wrote in
> On 2022-Apr-06, Kyotaro Horiguchi wrote:
>
> > For master, renamed delayChkpt to delayChkptFlags and changed it to
> > uint8.
>
> For code documentation purposes, I think it is slightly better to use
> bits8 than uint8 for variables
On 2022-Apr-06, Kyotaro Horiguchi wrote:
> For master, renamed delayChkpt to delayChkptFlags and changed it to
> uint8.
For code documentation purposes, I think it is slightly better to use
bits8 than uint8 for variables where you're storing independent bit flags.
--
Álvaro Herrera Post
At Wed, 06 Apr 2022 15:53:32 +0900 (JST), Kyotaro Horiguchi
wrote in
> At Wed, 06 Apr 2022 15:31:53 +0900 (JST), Kyotaro Horiguchi
> wrote in
> > At Wed, 06 Apr 2022 14:30:37 +0900 (JST), Kyotaro Horiguchi
> > wrote in
> > > So if we don't want to move any member in PGPROC, we do:
> > >
>
At Wed, 06 Apr 2022 15:31:53 +0900 (JST), Kyotaro Horiguchi
wrote in
> At Wed, 06 Apr 2022 14:30:37 +0900 (JST), Kyotaro Horiguchi
> wrote in
> > So if we don't want to move any member in PGPROC, we do:
> >
> > 14: after statusFlags.
> > 13: after delayChkpt.
> > 12-10: after syncRepState (a
At Wed, 06 Apr 2022 14:30:37 +0900 (JST), Kyotaro Horiguchi
wrote in
> So if we don't want to move any member in PGPROC, we do:
>
> 14: after statusFlags.
> 13: after delayChkpt.
> 12-10: after syncRepState (and before syncRepLinks).
>
> If we allow to shift some members, the new flag can be p
me> I'd like to do that. Let me see.
At Tue, 5 Apr 2022 10:29:03 -0400, Robert Haas wrote in
> On Tue, Apr 5, 2022 at 10:17 AM Tom Lane wrote:
> > What I think you need to do is:
> >
> > 1. In the back branches, revert delayChkpt to its previous type and
> > semantics. Squeeze a separate delay
At Tue, 5 Apr 2022 10:01:56 -0400, Robert Haas wrote in
> I think as the person who committed that patch I'm on the hook to fix
> this if nobody else would like to do it, but let me ask whether
> Kyotaro Horiguchi would like to propose a patch, since the original
> patch did, and/or whether you w
Robert Haas writes:
> On Tue, Apr 5, 2022 at 10:32 AM Tom Lane wrote:
>> My point is that we want that to happen in HEAD, but it's not okay
>> for it to happen in a minor release of a stable branch.
> I understand, but I am not sure that I agree. I think that if an
> extension stops compiling ag
On Tue, Apr 5, 2022 at 10:32 AM Tom Lane wrote:
> Robert Haas writes:
> > On Tue, Apr 5, 2022 at 10:17 AM Tom Lane wrote:
> >> Renaming it would constitute an API break, which is if anything worse
> >> than an ABI break.
>
> > I don't think so, because an API break will cause a compilation
> > f
Robert Haas writes:
> On Tue, Apr 5, 2022 at 10:17 AM Tom Lane wrote:
>> Renaming it would constitute an API break, which is if anything worse
>> than an ABI break.
> I don't think so, because an API break will cause a compilation
> failure, which an extension author can easily fix.
My point is
On Tue, Apr 5, 2022 at 10:17 AM Tom Lane wrote:
> Renaming it would constitute an API break, which is if anything worse
> than an ABI break.
I don't think so, because an API break will cause a compilation
failure, which an extension author can easily fix.
> While we're complaining at you, let me
Robert Haas writes:
> On Tue, Apr 5, 2022 at 9:02 AM Markus Wanner
> wrote:
>> And for this specific case: Is it worth reverting this change and
>> applying a fully backwards compatible fix, instead?
> I think it's normally our policy to avoid changing definitions of
> accessible structs in back
On Tue, Apr 5, 2022 at 9:02 AM Markus Wanner
wrote:
> And for this specific case: Is it worth reverting this change and
> applying a fully backwards compatible fix, instead?
I think it's normally our policy to avoid changing definitions of
accessible structs in back branches, except that we allow
On 24.03.22 20:32, Robert Haas wrote:
Fix possible recovery trouble if TRUNCATE overlaps a checkpoint.
This patch changed the delayChkpt field of struct PGPROC from bool to
int. Back-porting this change could be considered an API breaking
change for extensions using this field.
I'm not c
37 matches
Mail list logo
