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
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'
rmgr: XLOGlen (rec/tot):114/ 114, tx:
21 matches
Mail list logo
