On 2025-Jul-07, Japin Li wrote:
> Thank you for pushing this patch. I noticed some other areas in the
> documentation that could also use an update.
Thanks! Pushed these fixes.
--
Álvaro Herrera 48°01'N 7°57'E — https://www.EnterpriseDB.com/
Syntax error: function hell() needs
On 2025-Jul-07, Álvaro Herrera wrote:
> I think this should work, but I'm going to run against each of these
> versions to verify it before pushing.
Seems to work okay, so pushed. Crake will tell us if something's still
amiss.
--
Álvaro HerreraBreisgau, Deutschland — https://www.Ente
On 2025-Jul-07, Álvaro Herrera wrote:
> Meanwhile, crake is failing the cross-version upgrade test because of
> this change, and I'm not sure what solution I'm going to offer. Maybe
> use the AdjustUpgrade.pm infrastructure to set all the pg_lsn column
> values to NULL if the old version is earli
On 2025-Jul-07, Ashutosh Bapat wrote:
> I am wondering whether we should question the restriction on using
> format macros because of translations.
Sure Mr. Quixote, the windmills are over there.
> In fact, these format macros can actually aid translations e.g. if the
> translation sees LSN_FORM
On Mon, 07 Jul 2025 at 14:18, Álvaro Herrera wrote:
> On 2025-Jul-05, Masahiko Sawada wrote:
>
>> On Fri, Jul 4, 2025 at 8:01 PM Álvaro Herrera wrote:
>> >
>> > On 2025-Jul-04, Japin Li wrote:
>> >
>> > > I've opted to directly use %X/%08X for LSN formatting in this patch,
>> > > with an
>> > >
On Mon, 07 Jul 2025 at 19:34, Ashutosh Bapat
wrote:
> On Fri, Jul 4, 2025 at 5:18 PM Álvaro Herrera wrote:
>>
>> On 2025-Jul-04, Japin Li wrote:
>>
>> > I've opted to directly use %X/%08X for LSN formatting in this patch, with
>> > an
>> > accompanying comment near LSN_FORMAT_ARGS.
>>
>> Thank
On Fri, Jul 4, 2025 at 5:18 PM Álvaro Herrera wrote:
>
> On 2025-Jul-04, Japin Li wrote:
>
> > I've opted to directly use %X/%08X for LSN formatting in this patch, with an
> > accompanying comment near LSN_FORMAT_ARGS.
>
> Thank you! I support this approach and intend to work on getting this
> pa
On 2025-Jul-05, Masahiko Sawada wrote:
> On Fri, Jul 4, 2025 at 8:01 PM Álvaro Herrera wrote:
> >
> > On 2025-Jul-04, Japin Li wrote:
> >
> > > I've opted to directly use %X/%08X for LSN formatting in this patch, with
> > > an
> > > accompanying comment near LSN_FORMAT_ARGS.
> >
> > Thank you!
On Fri, Jul 4, 2025 at 8:01 PM Álvaro Herrera wrote:
>
> On 2025-Jul-04, Japin Li wrote:
>
> > I've opted to directly use %X/%08X for LSN formatting in this patch, with an
> > accompanying comment near LSN_FORMAT_ARGS.
>
> Thank you! I support this approach and intend to work on getting this
> pa
On 2025-Jul-04, Japin Li wrote:
> I've opted to directly use %X/%08X for LSN formatting in this patch, with an
> accompanying comment near LSN_FORMAT_ARGS.
Thank you! I support this approach and intend to work on getting this
patch committed soon after some more review, unless there are further
On 2025-Jul-03, Japin Li wrote:
> Providing two LSN formats — %X%08X for translatable messages and
> LSN_FORMAT for non-translatable ones — seems to offer no clear advantage.
>
> I'd prefer to use %X/%08X directly and add the description to the
> LSN_FORMAT_ARGS macro.
WFM.
--
Álvaro Herrera
On Thu, 03 Jul 2025 at 10:19, Álvaro Herrera wrote:
> On 2025-Jul-03, Michael Paquier wrote:
>
>> Yep. If you do not want this new policy to be forgotten by new paths,
>> I'd suggested to standarize that with something like that, close to
>> the existing LSN_FORMAT_ARGS():
>> #define LSN_FORMAT "
On 2025-Jul-03, Michael Paquier wrote:
> Yep. If you do not want this new policy to be forgotten by new paths,
> I'd suggested to standarize that with something like that, close to
> the existing LSN_FORMAT_ARGS():
> #define LSN_FORMAT "%X/%08X"
Well, the reason we didn't use a macro in the form
On Thu, Jul 3, 2025 at 7:32 AM Michael Paquier wrote:
>
> On Wed, Jul 02, 2025 at 08:57:45PM +0200, Alvaro Herrera wrote:
> > I think a tool would have to be severely miswritten in order to become
> > broken from this change. Our own code to scan LSNs is to use
> > scanf('%X/%X') which should wor
On Wed, Jul 02, 2025 at 08:57:45PM +0200, Alvaro Herrera wrote:
> I think a tool would have to be severely miswritten in order to become
> broken from this change. Our own code to scan LSNs is to use
> scanf('%X/%X') which should work just fine with and without the leading
> zeroes. I honestly do
On 2025-Jul-03, Masahiko Sawada wrote:
> On Wed, Jul 2, 2025 at 10:56 PM Japin Li wrote:
> Interesting. While this is a better format, could it break
> compatibility with existing tools that for example compares LSN
> strings?
I think a tool would have to be severely miswritten in order to beco
On Wed, Jul 2, 2025 at 10:56 PM Japin Li wrote:
>
> On Tue, 01 Jul 2025 at 22:00, Japin Li wrote:
> > On Tue, 01 Jul 2025 at 13:39, Álvaro Herrera wrote:
> >> On 2025-Jul-01, Japin Li wrote:
> >>
> >>> This inconsistency, while minor, could be confusing when cross-referencing
> >>> LSNs within p
On Tue, Jul 1, 2025 at 6:46 PM Japin Li wrote:
>
>
> Hi, all
>
> I've noticed an inconsistency in the LSN format printed by pg_waldump,
> specifically concerning the lsn: and prev fields in the output.
>
> $ pg_waldump /tmp/pgdata02/pg_wal/0001000A 2>/dev/null
> |grep 'AB10260
On Tue, 01 Jul 2025 at 13:39, Álvaro Herrera wrote:
> On 2025-Jul-01, Japin Li wrote:
>
>> This inconsistency, while minor, could be confusing when cross-referencing
>> LSNs within pg_waldump's own output or when parsing it programmatically.
>
> I agree that we should fix this, but I'd rather add
On 2025-Jul-01, Japin Li wrote:
> This inconsistency, while minor, could be confusing when cross-referencing
> LSNs within pg_waldump's own output or when parsing it programmatically.
I agree that we should fix this, but I'd rather add the missing zeros
than remove these ones (the only ones we ha
20 matches
Mail list logo
