On 20/10/2025 04:36, Michael Paquier wrote:
On Wed, Oct 15, 2025 at 05:39:38PM +0300, Heikki Linnakangas wrote:
We could store xl_crc unaligned. IIRC all the structs that follow that are
already stored unaligned.
If we do just that, would there be any downside in moving xl_crc to be
just after
On Wed, Oct 15, 2025 at 05:39:38PM +0300, Heikki Linnakangas wrote:
> We could store xl_crc unaligned. IIRC all the structs that follow that are
> already stored unaligned.
If we do just that, would there be any downside in moving xl_crc to be
just after xl_prev? That would keep the record assemb
On Tue, Oct 14, 2025 at 03:20:16PM +0300, Heikki Linnakangas wrote:
> I'm not sure I agree with the premise that we should try to get rid of
> RM_HEAP2_ID. There's nothing wrong with that scheme as such. As an
> alternative, we could easily teach e.g pg_waldump to treat RM_HEAP_ID and
> RM_HEAP2_ID
On 14/10/2025 11:13, John Naylor wrote:
Okay, v2 gets rid of the general info mask (split out into 0002 for
readability) and leaves alone the RMGR-specific masks (i.e. leaves out
v1 0002/3). It runs fine with installcheck while streaming to a
standby with wal_consistency_checking. I've also left
On Fri, Oct 10, 2025 at 9:47 AM Michael Paquier wrote:
>
> On Thu, Oct 09, 2025 at 03:15:11PM +0700, John Naylor wrote:
> > Leaving that up to the rmgr makes sense. One consideration I didn't
> > mention was for xlogstats.c -- "record_stats[rmid][recid]" would get
> > 16x larger if recid could tak
On Mon, Oct 06, 2025 at 04:04:00PM +0700, John Naylor wrote:
> 0004: get rid of RM_HEAP2_ID. This was simple once the prerequisites
> were in place. All of the HEAP2_* macros keep the same name and only
> differ in value. Heap rmgr is completely full so it might be good to
> increase to 5 bits for
On Tue, Oct 14, 2025 at 7:20 PM Heikki Linnakangas wrote:
> This patch consumes one of the padding bytes. That's not entirely free,
> as there is an opportunity cost: we could squeeze out the padding bytes
> and save 2 bytes on every WAL record instead.
I must be misunderstanding, because I'm not
On Thu, Oct 09, 2025 at 03:15:11PM +0700, John Naylor wrote:
> Leaving that up to the rmgr makes sense. One consideration I didn't
> mention was for xlogstats.c -- "record_stats[rmid][recid]" would get
> 16x larger if recid could take up the full byte. Maybe that's
> harmless, but I didn't want to
On 15/10/2025 02:54, Michael Paquier wrote:
On Tue, Oct 14, 2025 at 03:20:16PM +0300, Heikki Linnakangas wrote:
I'm not sure I agree with the premise that we should try to get rid of
RM_HEAP2_ID. There's nothing wrong with that scheme as such. As an
alternative, we could easily teach e.g pg_wald
On Mon, Oct 06, 2025 at 04:04:00PM +0700, John Naylor wrote:
> Making the XLogRecord header nicer has been proposed several times
> [1][2][3]. In [2], Robert wondered if with 2 bytes of xl_info, we
> could get rid of the separate xl_xact_info. There could be other
> possibilities as well, but I hav
On 15/10/2025 07:51, John Naylor wrote:
On Tue, Oct 14, 2025 at 7:20 PM Heikki Linnakangas wrote:
This patch consumes one of the padding bytes. That's not entirely free,
as there is an opportunity cost: we could squeeze out the padding bytes
and save 2 bytes on every WAL record instead.
I mus
On Wed, Oct 15, 2025 at 12:01:44PM +0700, John Naylor wrote:
> On Wed, Oct 15, 2025 at 6:55 AM Michael Paquier wrote:
>> We could move out xl_xid, which should not be required for all
>> records, shaving 4 bytes from the base XLogRecord. I'm afraid of the
>> duplication this would create if we pu
On Wed, Oct 15, 2025 at 6:55 AM Michael Paquier wrote:
>
> On Tue, Oct 14, 2025 at 03:20:16PM +0300, Heikki Linnakangas wrote:
> > I'm not sure I agree with the premise that we should try to get rid of
> > RM_HEAP2_ID. There's nothing wrong with that scheme as such. As an
> > alternative, we could
On Thu, Oct 9, 2025 at 1:43 PM Michael Paquier wrote:
> > 0001: Split xl_info into xl_info for rmgr-specific info and xl_geninfo
> > for generic flags. I used the XLogInsertExtended() idea from one of
> > Matthias's patches in [3], but wrote the rest a different way to keep
> > churn small.
>
> Re
14 matches
Mail list logo
