Re: pg_waldump: support decoding of WAL inside tarfile
От | Robert Haas |
---|---|
Тема | Re: pg_waldump: support decoding of WAL inside tarfile |
Дата | |
Msg-id | CA+TgmobNteeHyCtmnk8WZB8fScp9OUc2002vzc8zJPaG1K=8uQ@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: pg_waldump: support decoding of WAL inside tarfile (Robert Haas <robertmhaas@gmail.com>) |
Список | pgsql-hackers |
On Fri, Sep 12, 2025 at 2:28 PM Robert Haas <robertmhaas@gmail.com> wrote: > Is there a real need to pass XLogDumpPrivate to astreamer_wal_read or > astreamer_archive_read? The only things that they need are archive_fd, > archive_name, archive_streamer, archive_streamer_buf, and > archive_streamer_read_ptr. In other words, they really don't care > about any of the *existing* things that are in XLogDumpPrivate. This > makes me wonder whether we should actually try to make this new > astreamer completely independent of xlogreader. In other words, > instead of calling it astreamer_waldump() or astreamer_xlogreader() as > I proposed above, maybe it could be a completely generic astreamer, > say astreamer_stringinfo_new(StringInfo *buf) that just appends to the > buffer. That would require also moving the stuff out of > astreamer_wal_read() that knows about XLogRecPtr, but why does that > function need to know about XLogRecPtr? Couldn't the caller figure out > that part and just tell this function how many bytes are needed? Hmm, on further thought, I think this was a silly idea. Part of the intended function of this astreamer is to make sure we're only reading WAL files from the archive, and eventually reordering them if required, so obviously something completely generic isn't going to work. Maybe there's a way to make this look a little cleaner and tidier but this isn't it... -- Robert Haas EDB: http://www.enterprisedb.com
В списке pgsql-hackers по дате отправления: