incremental backup

could explain to me why these empty files are present and how they are used in the mecanism of incremental backup? Thanks for helping Fabrice

Re: Docs for pg_basebackup needs v17 note for incremental backup

> On 27 Feb 2025, at 19:06, David G. Johnston > wrote: > > On Thu, Feb 6, 2025 at 2:46 PM Daniel Gustafsson > wrote: >> I'd be happy to help getting this in, do you have a suggested wording? > > Thank you. > > Attached. Patch LGTM so I've applied it. -- Daniel Gusta

Re: Docs for pg_basebackup needs v17 note for incremental backup

hu, 27 Feb 2025 10:58:57 -0700 Subject: [PATCH] Document pg_basebackup incremental backup requires v17 server. --- doc/src/sgml/ref/pg_basebackup.sgml | 7 --- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git a/doc/src/sgml/ref/pg_basebackup.sgml b/doc/src/sgml/ref/pg_baseback

Re: Docs for pg_basebackup needs v17 note for incremental backup

On 2025-Jan-13, David G. Johnston wrote: > Hackers, > > Should the following paragraph in the docs be modified to point out minimum > server version of v17 for incremental backups? > > pg_basebackup works with servers of the same or an older major version, > down to 9.1. However, WAL streaming mo

Re: Docs for pg_basebackup needs v17 note for incremental backup

> On 6 Feb 2025, at 15:43, David G. Johnston wrote: > On Thursday, February 6, 2025, Andrew Dunstan wrote: > > People get busy. For example, many prominent hackers spent most of the last > > week at various conferences. There are also > > other things happening less > > publicly that are claim

Re: Docs for pg_basebackup needs v17 note for incremental backup

of initial reporting while I play by the rules and am a large contributor to the community but presently have 7 patches languishing in limbo, most without a single comment for or against. This is just one of the more clear-cut ones that doesn’t even take a senior hacker to deal with and, frankly

Re: Docs for pg_basebackup needs v17 note for incremental backup

On 2025-02-05 We 7:59 PM, David G. Johnston wrote: Is there seriously not a single person in the past three weeks who has seen this and not had the minute to spare to say "yes, this should be documented"? David J. On Mon, Jan 13, 2025 at 8:13 PM David G. Johnston wrote: Hackers,

Re: Docs for pg_basebackup needs v17 note for incremental backup

Is there seriously not a single person in the past three weeks who has seen this and not had the minute to spare to say "yes, this should be documented"? David J. On Mon, Jan 13, 2025 at 8:13 PM David G. Johnston < david.g.johns...@gmail.com> wrote: > Hackers, > > Should the following paragraph

Docs for pg_basebackup needs v17 note for incremental backup

Hackers, Should the following paragraph in the docs be modified to point out minimum server version of v17 for incremental backups? pg_basebackup works with servers of the same or an older major version, down to 9.1. However, WAL streaming mode (-X stream) only works with server version 9.3 and l

Re: trying again to get incremental backup

ckup, while "this one" is pg_combinebackup? However, what's up with pg_basebackup itself with respect to tar format incremental backups? AFAICT (see below), pg_basebackup -Ft --incremental=foo/backup_manifest happily creates an incremental backup in tar format; however, pg_combineb

Re: Instability with incremental backup tests (pg_combinebackup, 003_timeline.pl)

On Wed, Aug 21, 2024 at 03:18:49PM +0200, Tomas Vondra wrote: > +1 to just close it Sounds good to me. Thanks. -- Michael signature.asc Description: PGP signature

Re: Instability with incremental backup tests (pg_combinebackup, 003_timeline.pl)

On 8/21/24 14:58, Robert Haas wrote: > ... > > All we're doing here is taking an incremental backup of 1-table > database that had 1 row at the time of the full backup and has had 1 > more row inserted since then. On my system, the last time I ran this > regression test,

Re: Instability with incremental backup tests (pg_combinebackup, 003_timeline.pl)

pl, from dc212340058b: > # Failed test 'incremental backup from node1' > # at t/003_timeline.pl line 43. > > The node is extremely slow, so perhaps bumping up the timeout would be > fine enough in this case (did not spend time analyzing it). I don't > think that this has b

Re: Instability with incremental backup tests (pg_combinebackup, 003_timeline.pl)

4%3A51 >> >> That's in the test 003_timeline.pl, from dc212340058b: >> # Failed test 'incremental backup from node1' >> # at t/003_timeline.pl line 43. >> >> The node is extremely slow, so perhaps bumping up the timeout would be >> fine eno

Re: Instability with incremental backup tests (pg_combinebackup, 003_timeline.pl)

dc212340058b: > # Failed test 'incremental backup from node1' > # at t/003_timeline.pl line 43. > > The node is extremely slow, so perhaps bumping up the timeout would be > fine enough in this case (did not spend time analyzing it). I don't > think that this

Instability with incremental backup tests (pg_combinebackup, 003_timeline.pl)

Hi all, dikkop has reported a failure with the regression tests of pg_combinebackup: https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=dikkop&dt=2024-08-04%2010%3A04%3A51 That's in the test 003_timeline.pl, from dc212340058b: # Failed test 'incremental backup from n

Re: Incremental backup from a streaming replication standby fails

On Fri, Jul 26, 2024 at 4:13 PM Alexander Korotkov wrote: > Great! Should we mark the corresponding v17 open item as closed? Done. -- Robert Haas EDB: http://www.enterprisedb.com

Re: Incremental backup from a streaming replication standby fails

On Fri, Jul 26, 2024 at 4:11 PM Robert Haas wrote: > On Fri, Jul 26, 2024 at 1:09 AM Laurenz Albe wrote: > > > Committed this version to master and v17. > > > > Thanks for taking care of this. > > Sure thing! > > I knew it was going to confuse someone ... I just wasn't sure what to > do about it.

Re: Incremental backup from a streaming replication standby fails

On Fri, Jul 26, 2024 at 1:09 AM Laurenz Albe wrote: > > Committed this version to master and v17. > > Thanks for taking care of this. Sure thing! I knew it was going to confuse someone ... I just wasn't sure what to do about it. Now we've at least done something, which is hopefully superior to n

Re: Incremental backup from a streaming replication standby fails

ikely to confuse the reader. I think you just wanted to > > say that there are other possible causes for an incremental backup to > > fail. I want to keep the text as simple as possible and focus on the case > > that I hit, because I expect that a lot of people who experiment with

Re: Incremental backup from a streaming replication standby fails

other possible causes for an incremental backup to > fail. I want to keep the text as simple as possible and focus on the case > that I hit, because I expect that a lot of people who experiment with > incremental backup or run tests could run into the same problem. > > I don

Re: Incremental backup from a streaming replication standby fails

On Wed, 2024-07-24 at 15:27 -0400, Robert Haas wrote: > On Wed, Jul 24, 2024 at 6:46 AM Laurenz Albe wrote: > >    An incremental backup is only possible if replay would begin from a later > >    checkpoint than the checkpoint that started the previous backup upon > > wh

Re: Incremental backup from a streaming replication standby fails

On Wed, Jul 24, 2024 at 6:46 AM Laurenz Albe wrote: > An incremental backup is only possible if replay would begin from a later > checkpoint than the checkpoint that started the previous backup upon which > it depends. My concern here is that the previous backup might have been t

Re: Incremental backup from a streaming replication standby fails

27;m about to be super-nitpicky, but this seems > imprecise to me in multiple ways. On the contrary, cour comments and explanations are valuable. > How about something like this: > > An incremental backup is only possible if replay would begin from a > later checkpoint than for the

Re: Incremental backup from a streaming replication standby fails

On Mon, Jul 22, 2024 at 1:05 PM Laurenz Albe wrote: > Before I write a v2, a small question for clarification: > I believe I remember that during my experiments, I ran CHECKPOINT > on the standby server between the first backup and the incremental > backup, and that was not enough to

Re: Incremental backup from a streaming replication standby fails

On Mon, 2024-07-22 at 09:37 -0400, Robert Haas wrote: > How about something like this: > > An incremental backup is only possible if replay would begin from a > later checkpoint than for the previous backup upon which it depends. > On the primary, this condition is always satisfie

Re: Incremental backup from a streaming replication standby fails

On Fri, Jul 19, 2024 at 6:07 PM Laurenz Albe wrote: > Here is a patch. > I went for both the errhint and some documentation. Hmm, the hint doesn't end up using the word "standby" anywhere. That seems like it might not be optimal? +Like a base backup, you can take an in

Re: Incremental backup from a streaming replication standby

On Sat, Jun 29, 2024 at 07:01:04AM +0200, Laurenz Albe wrote: > The WAL summarizer is running on the standby server, but when I try > to take an incremental backup, I get an error that I understand to mean > that WAL summarizing hasn't caught up yet. Added an open ite

Re: Incremental backup from a streaming replication standby fails

appen. > > > > I think it would also be sufficient if we document that possibility. > > When I got the error, I looked at the documentation of incremental > > backup for any limitations with standby servers, but didn't find any. > > A remark in the documentation would

Re: Incremental backup from a streaming replication standby fails

ossibility. > When I got the error, I looked at the documentation of incremental > backup for any limitations with standby servers, but didn't find any. > A remark in the documentation would have satisfied me. Would you like to propose a patch adding a hint and/or adjusting

Re: Incremental backup from a streaming replication standby fails

the one I made. I'd be alright with the hint, but I'd say "during making an *incremental* standby backup", because that's the only case where it can happen. I think it would also be sufficient if we document that possibility. When I got the error, I looked at the documentation

Re: Incremental backup from a streaming replication standby fails

On Fri, Jul 19, 2024 at 11:32 AM David Steele wrote: > I think it would be enough just to add a hint such as: > > HINT: this is possible when making a standby backup with little or no > activity. That could work (with "this" capitalized). > My guess is in production environments this will be unc

Re: Incremental backup from a streaming replication standby fails

On 7/19/24 21:52, Robert Haas wrote: On Mon, Jul 15, 2024 at 11:27 AM Laurenz Albe wrote: On Sat, 2024-06-29 at 07:01 +0200, Laurenz Albe wrote: I played around with incremental backup yesterday and tried $subject The WAL summarizer is running on the standby server, but when I try to take an

Re: Incremental backup from a streaming replication standby fails

On Mon, Jul 15, 2024 at 11:27 AM Laurenz Albe wrote: > On Sat, 2024-06-29 at 07:01 +0200, Laurenz Albe wrote: > > I played around with incremental backup yesterday and tried $subject > > > > The WAL summarizer is running on the standby server, but when I try > > to ta

Re: Incremental backup from a streaming replication standby fails

On Sat, 2024-06-29 at 07:01 +0200, Laurenz Albe wrote: > I played around with incremental backup yesterday and tried $subject > > The WAL summarizer is running on the standby server, but when I try > to take an incremental backup, I get an error that I understand to mean

Incremental backup from a streaming replication standby

I played around with incremental backup yesterday and tried $subject The WAL summarizer is running on the standby server, but when I try to take an incremental backup, I get an error that I understand to mean that WAL summarizing hasn't caught up yet. I am not sure if that is worki

Re: trying again to get incremental backup

he first > backup specified on the command line, and newdir is the absolute path to use > for the tablespace in the reconstructed backup. > > The first backup specified on the command line will be the regular, full, > non-incremental backup. But if a tablespace was introduced subsequ

Re: trying again to get incremental backup

fied on the command line will be the regular, full, non-incremental backup. But if a tablespace was introduced subsequently, it would only appear in an incremental backup. Wouldn't this then mean that a mapping would need to be provided based on the path to the tablespace of that incremental backup's copy? Regards Thom

Re: incremental backup breakage in BlockRefTableEntryGetBlocks

On Fri, Apr 5, 2024 at 2:59 AM Jakub Wartak wrote: > And of course i'm attaching reproducer with some braindump notes in > case in future one hits similiar issue and wonders where to even start > looking (it's very primitive though but might help). Thanks. I've committed the patch now. -- Rober

Re: incremental backup breakage in BlockRefTableEntryGetBlocks

On Thu, Apr 4, 2024 at 9:11 PM Tomas Vondra wrote: > > On 4/4/24 19:38, Robert Haas wrote: > > Hi, > > > > Yesterday, Tomas Vondra reported to me off-list that he was seeing > > what appeared to be data corruption after taking and restoring an > > increme

Re: incremental backup breakage in BlockRefTableEntryGetBlocks

On 4/4/24 19:38, Robert Haas wrote: > Hi, > > Yesterday, Tomas Vondra reported to me off-list that he was seeing > what appeared to be data corruption after taking and restoring an > incremental backup. Overnight, Jakub Wartak further experimented with > Tomas's test

incremental backup breakage in BlockRefTableEntryGetBlocks

Hi, Yesterday, Tomas Vondra reported to me off-list that he was seeing what appeared to be data corruption after taking and restoring an incremental backup. Overnight, Jakub Wartak further experimented with Tomas's test case, did some initial analysis, and made it very easy to reproduce. I

Re: cleanup patches for incremental backup

On Wed, Mar 20, 2024 at 02:53:01PM -0400, Robert Haas wrote: > On Wed, Mar 20, 2024 at 2:35 PM Nathan Bossart > wrote: >> Committed. > > Thanks. Sorry you had to clean up after me. :-( No worries. -- Nathan Bossart Amazon Web Services: https://aws.amazon.com

Re: cleanup patches for incremental backup

On Wed, Mar 20, 2024 at 2:35 PM Nathan Bossart wrote: > On Tue, Mar 19, 2024 at 01:15:02PM -0500, Nathan Bossart wrote: > > Assuming there are no objections or feedback, I plan to commit these two > > patches within the next couple of days. > > Committed. Thanks. Sorry you had to clean up after m

Re: cleanup patches for incremental backup

On Tue, Mar 19, 2024 at 01:15:02PM -0500, Nathan Bossart wrote: > Assuming there are no objections or feedback, I plan to commit these two > patches within the next couple of days. Committed. -- Nathan Bossart Amazon Web Services: https://aws.amazon.com

Re: cleanup patches for incremental backup

On Thu, Mar 14, 2024 at 08:52:55PM -0500, Nathan Bossart wrote: > Subject: [PATCH v1 1/2] Revert "Temporary patch to help debug pg_walsummary > test failures." > Subject: [PATCH v1 2/2] Fix possible overflow in MaybeRemoveOldWalSummaries(). Assuming there are no objections or feedback, I plan to

Re: cleanup patches for incremental backup

On Thu, Mar 14, 2024 at 04:00:10PM -0500, Nathan Bossart wrote: > Separately, I suppose it's probably time to revert the temporary debugging > code adding by commit 5ddf997. I can craft a patch for that, too. As promised... -- Nathan Bossart Amazon Web Services: https://aws.amazon.com >From 392

Re: cleanup patches for incremental backup

On Wed, Jan 24, 2024 at 12:05:15PM -0600, Nathan Bossart wrote: > There might be an overflow risk in the cutoff time calculation, but I doubt > that's the root cause of these failures: > > /* >* Files should only be removed if the last modification time precedes > the >* cut

Re: incremental backup mishandles XLOG_DBASE_CREATE_FILE_COPY

On Sat, Feb 24, 2024 at 12:10 PM Noah Misch wrote: > Agreed, those don't touch relation data files. I think you've got all > relation data file mutations. XLOG_DBASE_CREATE_FILE_COPY and XLOG_DBASE_DROP > are the only record types that touch a relation data file without mentioning > it in XLogRe

Re: incremental backup mishandles XLOG_DBASE_CREATE_FILE_COPY

arize past a checkpoint, making that irrelevant. > > I'm not quite following this. It's true that we summarize from one > redo pointer to the next; but also, our summary is only trying to > ascertain which relation data blocks have been modified. Therefore, I > don't understand the relevance of nextXid here. No relevance, given incremental backup is incremental with respect to relation data blocks only.

Re: incremental backup mishandles XLOG_DBASE_CREATE_FILE_COPY

On Sat, Feb 24, 2024 at 10:05 AM Noah Misch wrote: > Regarding records the summarizer potentially can't ignore that don't deal in > relfilenodes, these come to mind: > > XLOG_DBASE_DROP - covered in this thread's patch > XLOG_RELMAP_UPDATE > XLOG_TBLSPC_CREATE > XLOG_TBLSPC_DROP > XLOG_XACT_PREPAR

Re: incremental backup mishandles XLOG_DBASE_CREATE_FILE_COPY

On Fri, Feb 23, 2024 at 08:47:52PM +0530, Robert Haas wrote: > If XLOG_DBASE_CREATE_FILE_COPY occurs between an incremental backup > and its reference backup, every relation whose DB OID and tablespace > OID match the corresponding values in that record should be backed up > in ful

incremental backup mishandles XLOG_DBASE_CREATE_FILE_COPY

If XLOG_DBASE_CREATE_FILE_COPY occurs between an incremental backup and its reference backup, every relation whose DB OID and tablespace OID match the corresponding values in that record should be backed up in full. Currently that's not happening, because the WAL summarizer doesn'

Re: cleanup patches for incremental backup

On Tue, Jan 30, 2024 at 11:52 AM Robert Haas wrote: > Here's a patch for that. I now think > a7097ca630a25dd2248229f21ebce4968d85d10a was actually misguided, and > served only to mask some of the failures caused by waiting for the WAL > summary file. Committed. -- Robert Haas EDB: http://www.en

Re: cleanup patches for incremental backup

On Tue, Jan 30, 2024 at 10:51 AM Robert Haas wrote: > I think the solution here is to find a better way to wait for the > inserts to be summarized, one that actually does wait for that to > happen. Here's a patch for that. I now think a7097ca630a25dd2248229f21ebce4968d85d10a was actually misguide

Re: cleanup patches for incremental backup

On Mon, Jan 29, 2024 at 4:13 PM Nathan Bossart wrote: > On Mon, Jan 29, 2024 at 03:18:50PM -0500, Robert Haas wrote: > > I'm wondering if what we need to do is run pg_walsummary on both > > summary files in that case. If we just pick one or the other, how do > > we know which one to pick? > > Even

Re: cleanup patches for incremental backup

On Mon, Jan 29, 2024 at 03:18:50PM -0500, Robert Haas wrote: > I'm wondering if what we need to do is run pg_walsummary on both > summary files in that case. If we just pick one or the other, how do > we know which one to pick? Even if we do that, isn't it possible that none of the summaries will

Re: cleanup patches for incremental backup

On Mon, Jan 29, 2024 at 1:21 PM Nathan Bossart wrote: > > Ah, I think this query: > > > > SELECT tli, start_lsn, end_lsn from pg_available_wal_summaries() > > WHERE tli = $summarized_tli AND end_lsn > '$summarized_lsn' > > > > is returning more than one row in some cases. I at

Re: cleanup patches for incremental backup

On Sat, Jan 27, 2024 at 10:31:09AM -0600, Nathan Bossart wrote: > On Sat, Jan 27, 2024 at 11:00:01AM +0300, Alexander Lakhin wrote: >> I'm discouraged by "\n1" in the file name and in the >> "examining summary..." message. >> regress_log_002_blocks from the following successful test run on the same

Re: cleanup patches for incremental backup

On Sat, Jan 27, 2024 at 11:00:01AM +0300, Alexander Lakhin wrote: > 24.01.2024 20:46, Robert Haas wrote: >> This is weird. There's a little more detail in the log file, >> regress_log_002_blocks, e.g. from the first failure you linked: >> >> [11:18:20.683](96.787s) # before insert, summarized TLI

Re: cleanup patches for incremental backup

24.01.2024 20:46, Robert Haas wrote: This is weird. There's a little more detail in the log file, regress_log_002_blocks, e.g. from the first failure you linked: [11:18:20.683](96.787s) # before insert, summarized TLI 1 through 0/14E09D0 [11:18:21.188](0.505s) # after insert, summarized TLI 1 th

Re: cleanup patches for incremental backup

Hello Robert, 26.01.2024 21:37, Robert Haas wrote: On Fri, Jan 26, 2024 at 12:39 PM Nathan Bossart wrote: On Fri, Jan 26, 2024 at 11:04:37AM -0500, Robert Haas wrote: Here is v2 with that addition. Looks reasonable. Thanks for the report & review. I have committed that version. While try

Re: cleanup patches for incremental backup

On Fri, Jan 26, 2024 at 12:39 PM Nathan Bossart wrote: > On Fri, Jan 26, 2024 at 11:04:37AM -0500, Robert Haas wrote: > > Here is v2 with that addition. > > Looks reasonable. Thanks for the report & review. I have committed that version. -- Robert Haas EDB: http://www.enterprisedb.com

Re: cleanup patches for incremental backup

On Fri, Jan 26, 2024 at 11:04:37AM -0500, Robert Haas wrote: > Here is v2 with that addition. Looks reasonable. -- Nathan Bossart Amazon Web Services: https://aws.amazon.com

Re: cleanup patches for incremental backup

On Thu, Jan 25, 2024 at 11:08 AM Nathan Bossart wrote: > On Thu, Jan 25, 2024 at 10:06:41AM -0500, Robert Haas wrote: > > On Wed, Jan 24, 2024 at 2:39 PM Nathan Bossart > > wrote: > >> That seems like a reasonable starting point. Even if it doesn't help > >> determine the root cause, it should

Re: cleanup patches for incremental backup

On Thu, Jan 25, 2024 at 10:06:41AM -0500, Robert Haas wrote: > On Wed, Jan 24, 2024 at 2:39 PM Nathan Bossart > wrote: >> That seems like a reasonable starting point. Even if it doesn't help >> determine the root cause, it should at least help rule out concurrent >> summary removal. > > Here is

Re: cleanup patches for incremental backup

On Wed, Jan 24, 2024 at 2:39 PM Nathan Bossart wrote: > That seems like a reasonable starting point. Even if it doesn't help > determine the root cause, it should at least help rule out concurrent > summary removal. Here is a patch for that. -- Robert Haas EDB: http://www.enterprisedb.com v1

Re: cleanup patches for incremental backup

On Wed, Jan 24, 2024 at 02:08:08PM -0500, Robert Haas wrote: > On Wed, Jan 24, 2024 at 1:05 PM Nathan Bossart > wrote: >> Otherwise, I think we'll probably need to add some additional logging to >> figure out what is happening... > > Where, though? I suppose we could: > > 1. Change the server c

Re: cleanup patches for incremental backup

On Wed, Jan 24, 2024 at 1:05 PM Nathan Bossart wrote: > There might be an overflow risk in the cutoff time calculation, but I doubt > that's the root cause of these failures: > > /* > * Files should only be removed if the last modification time > precedes the > * cutoff

Re: cleanup patches for incremental backup

On Wed, Jan 24, 2024 at 12:46:16PM -0500, Robert Haas wrote: > The "examining summary" line is generated based on the output of > pg_available_wal_summaries(). The way that works is that the server > calls readdir(), disassembles the filename into a TLI and two LSNs, > and returns the result. Then,

Re: cleanup patches for incremental backup

On Wed, Jan 24, 2024 at 12:08 PM Nathan Bossart wrote: > I'm seeing some recent buildfarm failures for pg_walsummary: > > > https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=sungazer&dt=2024-01-14%2006%3A21%3A58 > > https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=id

Re: cleanup patches for incremental backup

I'm seeing some recent buildfarm failures for pg_walsummary: https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=sungazer&dt=2024-01-14%2006%3A21%3A58 https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=idiacanthus&dt=2024-01-17%2021%3A10%3A36 https://buildfarm.p

Re: cleanup patches for incremental backup

On Thu, Jan 18, 2024 at 4:50 AM Matthias van de Meent wrote: > Sure, that's fine with me. OK, committed that way. -- Robert Haas EDB: http://www.enterprisedb.com

Re: cleanup patches for incremental backup

On Wed, 17 Jan 2024 at 21:10, Robert Haas wrote: > > On Wed, Jan 17, 2024 at 1:42 PM Matthias van de Meent > wrote: > > Sure, added in attached. > > I think this mostly looks good now but I just realized that I think > this needs rephrasing: > > + To restore incremental backups the tool link

Re: cleanup patches for incremental backup

On Wed, Jan 17, 2024 at 1:42 PM Matthias van de Meent wrote: > Sure, added in attached. I think this mostly looks good now but I just realized that I think this needs rephrasing: + To restore incremental backups the tool + is used, which combines incremental backups with a base backup a

Re: cleanup patches for incremental backup

further reflection, I think it's fine, > unless you feel otherwise. I removed "the" from the phrasing "the incremental backups", which makes it a bit less restricted. > The rest LGTM. In the latest patch I also fixed the casing of "Incremental Backup" to &q

Re: cleanup patches for incremental backup

On Tue, Jan 16, 2024 at 3:22 PM Matthias van de Meent wrote: > > One other thought is that the incremental backup only replaces > > relation files with incremental files, and it never does anything > > about FSM files. So the statement that it only contains data that was >

Re: cleanup patches for incremental backup

so this issue is fixed in the attached patch. > (2) The changes to monitoring.sgml contain an unrelated change, about > pg_stat_all_indexes.idx_scan. Thanks for noticing, fixed in attached. > Also, I think the "For more information, see /> bit should have a period after th

Re: cleanup patches for incremental backup

On Mon, Jan 15, 2024 at 3:31 PM Matthias van de Meent wrote: > Off-list I was notified that the new WAL summarizer process was not > yet added to the glossary, so PFA a patch that does that. > In passing, it also adds "incremental backup" to the glossary, and > updates t

Re: cleanup patches for incremental backup

> Thanks, committed. Off-list I was notified that the new WAL summarizer process was not yet added to the glossary, so PFA a patch that does that. In passing, it also adds "incremental backup" to the glossary, and updates the documented types of backends in monitoring.sgml with the new

Re: cleanup patches for incremental backup

On Sat, Jan 13, 2024 at 1:00 PM Alexander Lakhin wrote: > I've found one more typo in the sgml: > summarized_pid > And one in a comment: > sumamry > > A trivial fix is attached. Thanks, committed. -- Robert Haas EDB: http://www.enterprisedb.com

Re: cleanup patches for incremental backup

Hello Robert, 12.01.2024 17:50, Robert Haas wrote: On Thu, Jan 11, 2024 at 8:00 PM Shinoda, Noriyoshi (HPE Services Japan - FSIP) wrote: Thank you for developing the new tool. I have attached a patch that corrects the spelling of the --individual option in the SGML file. Thanks, committed.

Re: cleanup patches for incremental backup

On Thu, Jan 11, 2024 at 8:00 PM Shinoda, Noriyoshi (HPE Services Japan - FSIP) wrote: > Thank you for developing the new tool. I have attached a patch that corrects > the spelling of the --individual option in the SGML file. Thanks, committed. -- Robert Haas EDB: http://www.enterprisedb.com

RE: cleanup patches for incremental backup

Subject: Re: cleanup patches for incremental backup On Tue, Jan 9, 2024 at 1:18 PM Robert Haas wrote: > Here's v2. I plan to commit the rest of this fairly soon if there are > no comments. Done, with a minor adjustment to 0003. -- Robert Haas EDB: http://www.enter

Re: cleanup patches for incremental backup

On Tue, Jan 9, 2024 at 1:18 PM Robert Haas wrote: > Here's v2. I plan to commit the rest of this fairly soon if there are > no comments. Done, with a minor adjustment to 0003. -- Robert Haas EDB: http://www.enterprisedb.com

Re: cleanup patches for incremental backup

Hello again, I have now committed 0001. I got some off-list review of 0004; specifically, Michael Paquier said it looked OK, and Tom Lane found another bug. So I've added a fix for that in what's now 0003. Here's v2. I plan to commit the rest of this fairly soon if there are no comments. ...Rob

cleanup patches for incremental backup

Hi, I discovered that my patch to add WAL summarization added two new SQL-callable functions but failed to document them. 0001 fixes that. An outstanding item from the original thread was to write a better test for the not-yet-committed pg_walsummary utility. But I discovered that I couldn't do t

Re: trying again to get incremental backup

On Fri, Dec 22, 2023 at 12:00 AM Alexander Lakhin wrote: > My quick experiment shows that that TimestampDifferenceMilliseconds call > always returns zero, due to it's arguments swapped. Thanks. Tom already changed the unsigned -> int stuff in a separate commit, so I just pushed the fixes to Prepa

Re: trying again to get incremental backup

On Wed, Dec 27, 2023 at 10:36 AM Nathan Bossart wrote: > On Wed, Dec 27, 2023 at 09:11:02AM -0500, Robert Haas wrote: > > Thanks. I don't think there's a real bug, but I pushed a fix, same as > > what you had. > > Thanks! I also noticed that WALSummarizerLock probably needs a mention in > wait_ev

Re: trying again to get incremental backup

On Wed, Dec 27, 2023 at 09:11:02AM -0500, Robert Haas wrote: > Thanks. I don't think there's a real bug, but I pushed a fix, same as > what you had. Thanks! I also noticed that WALSummarizerLock probably needs a mention in wait_event_names.txt. -- Nathan Bossart Amazon Web Services: https://aws

Re: trying again to get incremental backup

On Sat, Dec 23, 2023 at 4:51 PM Nathan Bossart wrote: > My compiler has the following complaint: > > ../postgresql/src/backend/postmaster/walsummarizer.c: In function > ‘GetOldestUnsummarizedLSN’: > ../postgresql/src/backend/postmaster/walsummarizer.c:540:32: error: > ‘unsummarized_lsn’ may be u

Re: trying again to get incremental backup

My compiler has the following complaint: ../postgresql/src/backend/postmaster/walsummarizer.c: In function ‘GetOldestUnsummarizedLSN’: ../postgresql/src/backend/postmaster/walsummarizer.c:540:32: error: ‘unsummarized_lsn’ may be used uninitialized in this function [-Werror=maybe-uninitialized]

Re: trying again to get incremental backup

21.12.2023 23:43, Robert Haas wrote: There are also two deadcode.DeadStores complaints from clang. First one is about: /* * Align the wait time to prevent drift. This doesn't really matter, * but we'd like the warnings about how long we've been waiting to say

Re: trying again to get incremental backup

On Thu, Dec 21, 2023 at 10:00 AM Alexander Lakhin wrote: > Please look at the attached patch; it corrects all 29 items ("recods" > fixed in two places), but maybe you find some substitutions wrong... Thanks, committed with a few additions. > I've also observed that those commits introduced new w

Re: trying again to get incremental backup

- a/src/backend/backup/basebackup_incremental.c +++ b/src/backend/backup/basebackup_incremental.c @@ -158,7 +158,7 @@ CreateIncrementalBackupInfo(MemoryContext mcxt) /* * Before taking an incremental backup, the caller must supply the backup - * manifest from a prior backup. Each chunk of manifest data recieved +

Re: trying again to get incremental backup

On Wed, Dec 20, 2023 at 11:00 PM Alexander Lakhin wrote: > I've found several typos/inconsistencies introduced with 174c48050 and > dc2123400. Maybe you would want to fix them, while on it?: That's an impressively long list of mistakes in something I thought I'd been careful about. Sigh. I don't

Re: trying again to get incremental backup

Hello Robert, 20.12.2023 23:56, Robert Haas wrote: On Wed, Dec 20, 2023 at 8:11 AM Jakub Wartak wrote: the v15 patchset (posted yesterday) test results are GOOD: All right. I committed the main two patches, dropped the for-testing-only patch, and added a simple test to the remaining pg_walsum

Re: trying again to get incremental backup

On Wed, Dec 20, 2023 at 8:11 AM Jakub Wartak wrote: > the v15 patchset (posted yesterday) test results are GOOD: All right. I committed the main two patches, dropped the for-testing-only patch, and added a simple test to the remaining pg_walsummary patch. That needs more work, but here's what I h

Re: trying again to get incremental backup

Hi Robert, On Tue, Dec 19, 2023 at 9:36 PM Robert Haas wrote: > > On Fri, Dec 15, 2023 at 5:36 AM Jakub Wartak > wrote: > > I've played with with initdb/pg_upgrade (17->17) and i don't get DBID > > mismatch (of course they do differ after initdb), but i get this > > instead: > > > > $ pg_baseba

Re: trying again to get incremental backup

On Fri, Dec 15, 2023 at 6:58 AM Peter Eisentraut wrote: > A separate bikeshedding topic: The GUC "summarize_wal", could that be > "wal_something" instead? (wal_summarize? wal_summarizer?) It would be > nice if these settings names group together a bit, both with existing > wal_* ones and also wi

  1   2   3   4   >