question about zeroes in the wal file names

[Luca Ferrari]

I'm just curious to better understand the naming convention behind wal
files, because I've seen on a system of mine that the wals created
were:

0005020E00FF
 0005020F

while I was expecting 20E0x100. So I digged into the code and I've
seen, from the XLogFileName macro, that the last part is built as the
reminder of the number of segments per wal file:

#define XLogFileName(fname, tli, logSegNo, wal_segsz_bytes)\
snprintf(fname, MAXFNAMELEN, "%08X%08X%08X", tli,\
 (uint32) ((logSegNo) / XLogSegmentsPerXLogId(wal_segsz_bytes)), \
 (uint32) ((logSegNo) % XLogSegmentsPerXLogId(wal_segsz_bytes)))


and with the default wal size of 16 MB that gives a remainder of 256
(FF + 1). Assuming I haven't missed anything, this means that there
are 6 zeroes that will never change in the last 8 chars of the wal
filename.  Is therefore this only done to handle PostgreSQL WAL sizes
of 4 GB each?

Thanks,
Luca

Re: Missing Trigger after pgdump install

[Tom Lane]

Susan Hurst  writes:
> Error from Postgres server log (postgresql-2019-08-16_140110.log):
> 2019-08-16 14:04:24 CDT ERROR:  relation "devops.subscribers" does not 
> exist
> 2019-08-16 14:04:24 CDT STATEMENT:  create trigger subscribers_iur_trg
>   instead of update
>   on devops.subscribers
>   for each row
>   execute procedure devops.subscribers_update();

This log file is definitely where you should be looking for more
information.  Is that the *only* message that appears while trying
to restore the dump file?

Is the pg_dump version that's being used to create the dump file 9.5.0,
or something later?  (Use pg_dump --version if you're unsure --- but
I'm suspicious that it's 9.5.0, if it's from the source server
installation.)

Trawling the commit log, I see a number of post-9.5.0 bug fixes related to
pg_dump's handling of views that have index dependencies.  I wonder whether
any of those are related to this.  The symptoms don't seem to quite match,
but ...

> CREATE VIEW subscribers appears on line 11,968 in the dump file

Is it possible that you've got more than one view named "subscribers",
in different schemas?  If so this might not be the relevant entry.

regards, tom lane

Re: question about zeroes in the wal file names

[Kyotaro Horiguchi]

At Sun, 18 Aug 2019 16:17:03 +0200, Luca Ferrari  wrote in 

> I'm just curious to better understand the naming convention behind wal
> files, because I've seen on a system of mine that the wals created
> were:
> 
> 0005020E00FF
>  0005020F
> 
> while I was expecting 20E0x100. So I digged into the code and I've
> seen, from the XLogFileName macro, that the last part is built as the
> reminder of the number of segments per wal file:
> 
> #define XLogFileName(fname, tli, logSegNo, wal_segsz_bytes)\
> snprintf(fname, MAXFNAMELEN, "%08X%08X%08X", tli,\
>  (uint32) ((logSegNo) / XLogSegmentsPerXLogId(wal_segsz_bytes)), \
>  (uint32) ((logSegNo) % XLogSegmentsPerXLogId(wal_segsz_bytes)))
> 
> 
> and with the default wal size of 16 MB that gives a remainder of 256
> (FF + 1). Assuming I haven't missed anything, this means that there
> are 6 zeroes that will never change in the last 8 chars of the wal
> filename.  Is therefore this only done to handle PostgreSQL WAL sizes
> of 4 GB each?

I think that's right. I don't see it used in other than WAL file
names.  As the macro name suggests, the 4GB block is internally
called as "xlog id" (XLogId). The block size is determined so
that the location within it can be handled as a 32-bit
integer. Older versions of postgresql defined XLogRecPtr as a
pair of two 32-bit integers.

xlogdefs.h.~REL9_1_0~:17
/*
 * Pointer to a location in the XLOG.  These pointers are 64 bits wide,
 * because we don't want them ever to overflow.
 *
 * NOTE: xrecoff == 0 is used to indicate an invalid pointer.  This is OK
 * because we use page headers in the XLOG, so no XLOG record can start
 * right at the beginning of a file.
 *
 * NOTE: the "log file number" is somewhat misnamed, since the actual files
 * making up the XLOG are much smaller than 4Gb.  Each actual file is an
 * XLogSegSize-byte "segment" of a logical log file having the indicated
 * xlogid.  The log file number and segment number together identify a
 * physical XLOG file.  Segment number and offset within the physical file
 * are computed from xrecoff div and mod XLogSegSize.
 */
typedef struct XLogRecPtr
{
uint32  xlogid; /* log file #, 0 based */
uint32  xrecoff;/* byte offset of location in 
log file */
} XLogRecPtr;


regards.

-- 
Kyotaro Horiguchi
NTT Open Source Software Center