On Tue, Mar 26, 2024 at 02:14:14PM -0500, Nathan Bossart wrote:
> On Mon, Jan 15, 2024 at 08:50:25AM -0600, Nathan Bossart wrote:
>> Thanks for reviewing. I've marked this as ready-for-committer, and I'm
>> hoping to commit it in the near future.
>
> This one probably ought to go into v17, but I
On Mon, Jan 15, 2024 at 08:50:25AM -0600, Nathan Bossart wrote:
> Thanks for reviewing. I've marked this as ready-for-committer, and I'm
> hoping to commit it in the near future.
This one probably ought to go into v17, but I wanted to do one last call
for feedback prior to committing.
--
Nathan
On Mon, Jan 15, 2024 at 12:21:44PM +, Li, Yong wrote:
> The patch looks good to me. With the context explained in the thread,
> the patch is easy to understand.
> The patch serves as a refactoring which pulls up common memory management
> and error handling concerns into the pgarch.c. With th
> On Nov 29, 2023, at 01:18, Nathan Bossart wrote:
>
> External Email
>
> Here is a new version of the patch with feedback addressed.
>
> --
> Nathan Bossart
> Amazon Web Services: https://aws.amazon.com
Hi Nathan,
The patch looks good to me. With the context explained in the thread, the
Here is a new version of the patch with feedback addressed.
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
>From 3cda5bb87c82738ad6f8a082ef5dfeb49cd51392 Mon Sep 17 00:00:00 2001
From: Nathan Bossart
Date: Tue, 28 Nov 2023 11:17:13 -0600
Subject: [PATCH v3 1/1] archiver exception
On Mon, Nov 13, 2023 at 03:35:28PM -0800, Andres Freund wrote:
> On 2023-11-13 16:42:31 -0600, Nathan Bossart wrote:
>> There seems to be no interest in this patch, so I plan to withdraw it from
>> the commitfest system by the end of the month unless such interest
>> materializes.
>
> I think it m
Hi,
On 2023-11-13 16:42:31 -0600, Nathan Bossart wrote:
> There seems to be no interest in this patch, so I plan to withdraw it from
> the commitfest system by the end of the month unless such interest
> materializes.
I think it might just have arrived too shortly before the feature freeze to be
There seems to be no interest in this patch, so I plan to withdraw it from
the commitfest system by the end of the month unless such interest
materializes.
On Fri, Feb 17, 2023 at 01:56:24PM -0800, Nathan Bossart wrote:
> The first one is the requirement that archive module authors create their
>
On Tue, Nov 15, 2022 at 12:57:49PM -0800, Nathan Bossart wrote:
> On Tue, Nov 15, 2022 at 06:14:25PM +0100, Alvaro Herrera wrote:
>> Hmm, really? It seems to me that we will have two slightly different
>> behaviors in 15 and master, which may be confusing later on. I think
>> it'd be better to ma
On Tue, Nov 15, 2022 at 06:14:25PM +0100, Alvaro Herrera wrote:
> On 2022-Nov-15, Nathan Bossart wrote:
>
>> On Tue, Nov 15, 2022 at 10:31:44AM +0100, Peter Eisentraut wrote:
>
>> > The surrounding code has changed a bit between PG15 and master, so if we
>> > wanted to backpatch this, we'd need a
On 2022-Nov-15, Nathan Bossart wrote:
> On Tue, Nov 15, 2022 at 10:31:44AM +0100, Peter Eisentraut wrote:
> > The surrounding code has changed a bit between PG15 and master, so if we
> > wanted to backpatch this, we'd need another patch from you. However, at
> > this point, I'm content to just l
On Tue, Nov 15, 2022 at 10:31:44AM +0100, Peter Eisentraut wrote:
> I have committed this to master.
Thanks!
> The surrounding code has changed a bit between PG15 and master, so if we
> wanted to backpatch this, we'd need another patch from you. However, at
> this point, I'm content to just leav
On 05.11.22 21:51, Nathan Bossart wrote:
On Fri, Nov 04, 2022 at 12:05:26PM +0900, Ian Lawrence Barwick wrote:
cfbot reports the patch no longer applies [1]. As CommitFest 2022-11 is
currently underway, this would be an excellent time to update the patch.
Indeed. Here is a new version of the
On Mon, Nov 07, 2022 at 03:20:31PM +0900, Michael Paquier wrote:
> On Sat, Nov 05, 2022 at 02:08:58PM -0700, Nathan Bossart wrote:
>> Perhaps we could eventually move the archive_command functionality to a
>> contrib module (i.e., "shell_archive") so that users must always set
>> archive_library.
On Sat, Nov 05, 2022 at 02:08:58PM -0700, Nathan Bossart wrote:
> Such a module could define a custom GUC that accepts a shell command. I
> don't think we should overload the meaning of archive_command based on the
> whims of whatever archive module is loaded. Besides the potential end-user
> con
On Mon, Oct 17, 2022 at 02:49:51PM +0900, Michael Paquier wrote:
> And, by the way, this patch would prevent the existence of archive
> modules that need to be loaded but *want* an archive_command with
> what they want to achieve. That does not strike me as a good idea if
> we want to have a maxim
On Fri, Nov 04, 2022 at 12:05:26PM +0900, Ian Lawrence Barwick wrote:
> cfbot reports the patch no longer applies [1]. As CommitFest 2022-11 is
> currently underway, this would be an excellent time to update the patch.
Indeed. Here is a new version of the patch.
--
Nathan Bossart
Amazon Web Se
2022年10月16日(日) 16:36 Bharath Rupireddy :
>
> On Sat, Oct 15, 2022 at 3:13 AM Nathan Bossart
> wrote:
> >
> > On Fri, Oct 14, 2022 at 11:51:30AM -0700, Nathan Bossart wrote:
> > > On Fri, Oct 14, 2022 at 12:10:18PM +0530, Bharath Rupireddy wrote:
> > >> 2) I think we have a problem - set archive_m
On Mon, Oct 17, 2022 at 11:20 AM Michael Paquier wrote:
>
> On Mon, Oct 17, 2022 at 01:46:39PM +0900, Kyotaro Horiguchi wrote:
> > As the code written, when archive library is being added while archive
> > command is already set, archiver first emits seemingly positive
> > message "restarting arch
On Mon, Oct 17, 2022 at 01:46:39PM +0900, Kyotaro Horiguchi wrote:
> As the code written, when archive library is being added while archive
> command is already set, archiver first emits seemingly positive
> message "restarting archive process because of..", then errors out
> after the resatart and
At Fri, 14 Oct 2022 14:42:56 -0700, Nathan Bossart
wrote in
> As promised...
As the code written, when archive library is being added while archive
command is already set, archiver first emits seemingly positive
message "restarting archive process because of..", then errors out
after the resata
On Sat, Oct 15, 2022 at 3:13 AM Nathan Bossart wrote:
>
> On Fri, Oct 14, 2022 at 11:51:30AM -0700, Nathan Bossart wrote:
> > On Fri, Oct 14, 2022 at 12:10:18PM +0530, Bharath Rupireddy wrote:
> >> 2) I think we have a problem - set archive_mode and archive_library
> >> and start the server, then
On Fri, Oct 14, 2022 at 11:51:30AM -0700, Nathan Bossart wrote:
> On Fri, Oct 14, 2022 at 12:10:18PM +0530, Bharath Rupireddy wrote:
>> 2) I think we have a problem - set archive_mode and archive_library
>> and start the server, then set archive_command, reload the conf, see
>> [3] - the archiver n
On Fri, Oct 14, 2022 at 12:10:18PM +0530, Bharath Rupireddy wrote:
> +ereport(ERROR,
> +(errcode(ERRCODE_INVALID_PARAMETER_VALUE),
> + errmsg("both archive_command and archive_library
> specified"),
> + errdetail("Only one of archive_command,
On Fri, Oct 14, 2022 at 6:00 AM Michael Paquier wrote:
>
> On Thu, Oct 13, 2022 at 02:53:38PM -0400, Tom Lane wrote:
> > Yeah, it really does not work to use GUC hooks to enforce multi-variable
> > constraints. We've learned that the hard way (more than once, if memory
> > serves).
>
> 414c2fd is
On Thu, Oct 13, 2022 at 02:53:38PM -0400, Tom Lane wrote:
> Yeah, it really does not work to use GUC hooks to enforce multi-variable
> constraints. We've learned that the hard way (more than once, if memory
> serves).
414c2fd is one of the most recent ones. Its thread is about the same
thing.
--
Nathan Bossart writes:
> On Thu, Oct 13, 2022 at 03:25:27PM +0530, Bharath Rupireddy wrote:
>> The intent here looks reasonable to me. However, why should the user
>> be able to set both archive_command and archive_library in the first
>> place only to later fail in LoadArchiveLibrary() per the pa
On Thu, Oct 13, 2022 at 03:25:27PM +0530, Bharath Rupireddy wrote:
> The intent here looks reasonable to me. However, why should the user
> be able to set both archive_command and archive_library in the first
> place only to later fail in LoadArchiveLibrary() per the patch? IMO,
> the check_hook()
On Mon, Oct 10, 2022 at 1:17 PM Peter Eisentraut
wrote:
>
> On 05.10.22 20:57, Nathan Bossart wrote:
> >> What we are talking about here is, arguably, a misconfiguration, so it
> >> should result in an error.
> >
> > Okay. What do you think about something like the attached?
The intent here look
On 05.10.22 20:57, Nathan Bossart wrote:
On Wed, Oct 05, 2022 at 07:55:58PM +0200, Peter Eisentraut wrote:
Leaving archive_command empty is an intentional configuration choice.
What we are talking about here is, arguably, a misconfiguration, so it
should result in an error.
Okay. What do you
On Wed, Oct 05, 2022 at 07:55:58PM +0200, Peter Eisentraut wrote:
> Leaving archive_command empty is an intentional configuration choice.
>
> What we are talking about here is, arguably, a misconfiguration, so it
> should result in an error.
Okay. What do you think about something like the attac
On 23.09.22 18:14, Nathan Bossart wrote:
On Fri, Sep 23, 2022 at 05:58:42AM -0400, Peter Eisentraut wrote:
On 15.09.22 00:27, Nathan Bossart wrote:
Both archive_command and archive_library are PGC_SIGHUP, so IIUC that
wouldn't be sufficient. I attached a quick sketch that seems to provide
the
On Fri, Sep 23, 2022 at 05:58:42AM -0400, Peter Eisentraut wrote:
> On 15.09.22 00:27, Nathan Bossart wrote:
>> Both archive_command and archive_library are PGC_SIGHUP, so IIUC that
>> wouldn't be sufficient. I attached a quick sketch that seems to provide
>> the desired behavior. It's nowhere ne
On 15.09.22 00:27, Nathan Bossart wrote:
Both archive_command and archive_library are PGC_SIGHUP, so IIUC that
wouldn't be sufficient. I attached a quick sketch that seems to provide
the desired behavior. It's nowhere near committable yet, but it
demonstrates what I'm thinking.
What is the ef
On Wed, Sep 14, 2022 at 09:33:46PM +0200, Peter Eisentraut wrote:
> Another question on this feature: Currently, if archive_library is set,
> archive_command is ignored. I think if both are set, it should be an error.
> Compare for example what happens if you set multiple recovery_target_xxx
> set
On 17.09.22 11:49, Peter Eisentraut wrote:
On 14.09.22 23:09, Nathan Bossart wrote:
On Wed, Sep 14, 2022 at 09:31:04PM +0200, Peter Eisentraut wrote:
Here is a patch that addresses this.
My intent was to present archive_command as the built-in archive library,
but I can see how this might cau
On 14.09.22 23:09, Nathan Bossart wrote:
On Wed, Sep 14, 2022 at 09:31:04PM +0200, Peter Eisentraut wrote:
Here is a patch that addresses this.
My intent was to present archive_command as the built-in archive library,
but I can see how this might cause confusion, so this change seems
reasonabl
On Wed, Sep 14, 2022 at 06:12:09PM -0400, Tom Lane wrote:
> Nathan Bossart writes:
>> On Wed, Sep 14, 2022 at 04:47:23PM -0400, Tom Lane wrote:
>>> Yeah, the objection there is only to trying to enforce such
>>> interrelationships in GUC hooks. In this case it seems to me that
>>> we could easily
Nathan Bossart writes:
> On Wed, Sep 14, 2022 at 04:47:23PM -0400, Tom Lane wrote:
>> Yeah, the objection there is only to trying to enforce such
>> interrelationships in GUC hooks. In this case it seems to me that
>> we could easily check and complain at the point where we're about
>> to use the
On Wed, Sep 14, 2022 at 04:47:23PM -0400, Tom Lane wrote:
> Peter Eisentraut writes:
>> On 14.09.22 22:03, Nathan Bossart wrote:
>>> I originally did it this way, but changed it based on this feedback [0]. I
>>> have no problem with the general idea, but the recovery_target_* logic does
>>> have
On Wed, Sep 14, 2022 at 09:31:04PM +0200, Peter Eisentraut wrote:
> Here is a patch that addresses this.
My intent was to present archive_command as the built-in archive library,
but I can see how this might cause confusion, so this change seems
reasonable to me.
> +
> +It is important tha
Peter Eisentraut writes:
> On 14.09.22 22:03, Nathan Bossart wrote:
>> I originally did it this way, but changed it based on this feedback [0]. I
>> have no problem with the general idea, but the recovery_target_* logic does
>> have the following note:
>>
>> * XXX this code is broken by design.
On 14.09.22 22:03, Nathan Bossart wrote:
On Wed, Sep 14, 2022 at 09:33:46PM +0200, Peter Eisentraut wrote:
Another question on this feature: Currently, if archive_library is set,
archive_command is ignored. I think if both are set, it should be an error.
Compare for example what happens if you
On Wed, Sep 14, 2022 at 09:33:46PM +0200, Peter Eisentraut wrote:
> Another question on this feature: Currently, if archive_library is set,
> archive_command is ignored. I think if both are set, it should be an error.
> Compare for example what happens if you set multiple recovery_target_xxx
> set
Another question on this feature: Currently, if archive_library is set,
archive_command is ignored. I think if both are set, it should be an
error. Compare for example what happens if you set multiple
recovery_target_xxx settings. I don't think silently turning off one
setting by setting ano
On 14.09.22 07:25, Michael Paquier wrote:
removed or recycled until they are archived. If WAL archiving cannot keep
up
- with the pace that WAL is generated, or if
archive_command
+ with the pace that WAL is generated, or if
archive_library
fails repeatedly, old WAL files will ac
On Wed, Sep 14, 2022 at 06:37:38AM +0200, Peter Eisentraut wrote:
> I noticed that this patch has gone around and mostly purged mentions of
> archive_command from the documentation and replaced them with
> archive_library. I don't think this is helpful, since people still use
> archive_command and
I noticed that this patch has gone around and mostly purged mentions of
archive_command from the documentation and replaced them with
archive_library. I don't think this is helpful, since people still use
archive_command and will want to see what the documentation has to say
about it. I suggest
On Sat, Sep 10, 2022 at 04:44:16PM -0400, Tom Lane wrote:
> Nathan Bossart writes:
>> Of course. I've marked it as ready-for-committer.
>
> Pushed with a bit of additional wordsmithing.
Thanks!
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
Nathan Bossart writes:
> Of course. I've marked it as ready-for-committer.
Pushed with a bit of additional wordsmithing.
regards, tom lane
On Tue, Aug 30, 2022 at 09:49:20AM +0200, Benoit Lobréau wrote:
> Ok done, https://commitfest.postgresql.org/39/3856/ (is that fine if I
> added you as a reviewer ?)
Of course. I've marked it as ready-for-committer.
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
On Tue, Aug 30, 2022 at 12:46 AM Nathan Bossart
wrote:
> I would advise that you create a commitfest entry for your patch so that it
> isn't forgotten.
>
Ok done, https://commitfest.postgresql.org/39/3856/ (is that fine if I
added you as a reviewer ?)
and thanks for the added links in the patch
On Thu, Aug 25, 2022 at 01:06:00PM -0700, Nathan Bossart wrote:
> On Thu, Aug 25, 2022 at 03:29:41PM +0200, talk to ben wrote:
>> Here is a patch with the proposed wording.
>
> Here is the same patch with a couple more links.
I would advise that you create a commitfest entry for your patch so tha
On Thu, Aug 25, 2022 at 03:29:41PM +0200, talk to ben wrote:
> Here is a patch with the proposed wording.
Here is the same patch with a couple more links.
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
>From 92a6d8669d9e5b527a7ac9af7eb359a86526775b Mon Sep 17 00:00:00 2001
From: b
Here is a patch with the proposed wording.
From 7fce0073f8a53b3e9ba84fa10fbc7b8efef36e97 Mon Sep 17 00:00:00 2001
From: benoit
Date: Mon, 22 Aug 2022 12:00:46 +0200
Subject: [PATCH] basic_archive parameter visibility doc patch
Module parameters are only visible from the pg_settings view once
the
On Wed, Aug 24, 2022 at 10:05:55AM +0200, talk to ben wrote:
> This view does not display linkend="runtime-config-custom">customized options
> - until the extension module that defines them has been loaded.
> + until the extension module that defines them has been loaded. Therefore,
> any
Nathan Bossart writes:
> On one hand, it seems like folks will commonly encounter this behavior
with this
> module, so this feels like a natural place for such a note.
Yes, I looked there first.
Would this addition to the pg_settings description be better ?
From 5346a8a0451e222e6592baacb994e6a0
Nathan Bossart writes:
> I don't know if it makes sense to document this in basic_archive. On one
> hand, it seems like folks will commonly encounter this behavior with this
> module, so this feels like a natural place for such a note. But on the
> other hand, this is generic behavior for any li
On Tue, Aug 23, 2022 at 04:18:52PM +0200, talk to ben wrote:
> --- a/doc/src/sgml/basic-archive.sgml
> +++ b/doc/src/sgml/basic-archive.sgml
> @@ -68,6 +68,19 @@ basic_archive.archive_directory =
> '/path/to/archive/directory'
> to any archiving still in progress, but users should use extra ca
Would this addition to the documentation be ok ? I hope the english is not
too broken ..
From 8ea8c21413eeac8fbd37527e64820cbdca3a5d7a Mon Sep 17 00:00:00 2001
From: benoit
Date: Mon, 22 Aug 2022 12:00:46 +0200
Subject: [PATCH] basic_archive parameter visibility doc patch
Module parameters are on
On Thu, Jul 07, 2022 at 11:48:20AM -0400, Tom Lane wrote:
> Alvaro Herrera writes:
>> Well, this does sound unsatisfactory. I suppose one answer would be to
>> load the module in all backends, in case the user wants to look at the
>> value. But that would be wasteful. Maybe we should have a war
Alvaro Herrera writes:
> Well, this does sound unsatisfactory. I suppose one answer would be to
> load the module in all backends, in case the user wants to look at the
> value. But that would be wasteful. Maybe we should have a warning
> about it in the docs -- tell people to LOAD the library
On 2022-Jul-07, talk to ben wrote:
> The modified archive module parameters are visible in pg_file_settings.
> They don't show up in \dconfig+, which I understand given the query used by
> the meta command, but I find a little confusing from an end user POV.
Well, this does sound unsatisfactory.
(Sorry for the spam Nathan)
With the list in CC and additional information :
The modified archive module parameters are visible in pg_file_settings.
They don't show up in \dconfig+, which I understand given the query used by
the
meta command, but I find a little confusing from an end user POV.
> I think the reason is that only the archiver process loads the library, so
> the GUC isn't registered at startup like you'd normally see with
> shared_preload_libraries. IIUC the server will still create a placeholder
> GUC during startup for custom parameters, which is why it shows up for SHOW
On Wed, Jul 06, 2022 at 06:21:24PM +0200, talk to ben wrote:
> I am not sure why, but I can't find "basic_archive.archive_directory" in
> pg_settings the same way I would find for example :
> "pg_stat_statements.max".
>
> [local]:5656 benoit@postgres=# SELECT count(*) FROM pg_settings WHERE name
>
Hi,
I am not sure why, but I can't find "basic_archive.archive_directory" in
pg_settings the same way I would find for example :
"pg_stat_statements.max".
[local]:5656 benoit@postgres=# SELECT count(*) FROM pg_settings WHERE name
= 'basic_archive.archive_directory';
count
---
0
(1 row)
On Thu, Feb 03, 2022 at 04:45:52PM -0500, Robert Haas wrote:
> On Thu, Feb 3, 2022 at 4:25 PM Nathan Bossart
> wrote:
>> 024_archive_recovery.pl seems to do something similar. Patch attached.
>
> Committed. I think this is mostly an issue for pg_regress tests, as
> opposed to 024_archive_recove
On Thu, Feb 3, 2022 at 4:25 PM Nathan Bossart wrote:
> 024_archive_recovery.pl seems to do something similar. Patch attached.
Committed. I think this is mostly an issue for pg_regress tests, as
opposed to 024_archive_recovery.pl, which is a TAP test. Maybe I'm
wrong about that, but it looks to m
On Thu, Feb 03, 2022 at 04:15:30PM -0500, Robert Haas wrote:
> On Thu, Feb 3, 2022 at 4:11 PM Nathan Bossart
> wrote:
>> On Thu, Feb 03, 2022 at 04:04:33PM -0500, Robert Haas wrote:
>> > So apparently we need to either skip this test when wal_level=minimal,
>> > or force a higher wal_level to be
On Thu, Feb 3, 2022 at 4:11 PM Nathan Bossart wrote:
> On Thu, Feb 03, 2022 at 04:04:33PM -0500, Robert Haas wrote:
> > So apparently we need to either skip this test when wal_level=minimal,
> > or force a higher wal_level to be used for this particular test. Not
> > sure what the existing precede
On Thu, Feb 03, 2022 at 04:04:33PM -0500, Robert Haas wrote:
> So apparently we need to either skip this test when wal_level=minimal,
> or force a higher wal_level to be used for this particular test. Not
> sure what the existing precedents are, if any.
The only precedent I've found so far is test
On Thu, Feb 3, 2022 at 2:27 PM Nathan Bossart wrote:
> On Thu, Feb 03, 2022 at 02:11:18PM -0500, Robert Haas wrote:
> > Committed. I'm going to be 0% surprised if the buildfarm turns pretty
> > colors, but I don't know how to know what it's going to be unhappy
> > about except by trying it, so her
On Thu, Feb 03, 2022 at 02:11:18PM -0500, Robert Haas wrote:
> Committed. I'm going to be 0% surprised if the buildfarm turns pretty
> colors, but I don't know how to know what it's going to be unhappy
> about except by trying it, so here goes.
Thanks! I'll keep an eye on the buildfarm and will s
On Wed, Feb 2, 2022 at 5:44 PM Nathan Bossart wrote:
> > I would suggest s/if it eventually/only when it/
>
> Done.
Committed. I'm going to be 0% surprised if the buildfarm turns pretty
colors, but I don't know how to know what it's going to be unhappy
about except by trying it, so here goes.
--
Thanks for the review!
On Wed, Feb 02, 2022 at 01:42:55PM -0500, Robert Haas wrote:
> I think avoiding ERROR is going to be impractical. Catching it in the
> contrib module seems OK. Catching it in the generic code is probably
> also possible to do in a reasonable way. Not catching the error also
On Mon, Jan 31, 2022 at 8:36 PM Nathan Bossart wrote:
> If basic_archive is to be in contrib, we probably want to avoid restarting
> the archiver every time the module ERRORs. I debated trying to add a
> generic exception handler that all archive modules could use, but I suspect
> many will have
On Sat, Jan 29, 2022 at 09:01:41PM -0800, Nathan Bossart wrote:
> On Sat, Jan 29, 2022 at 04:31:48PM -0800, Nathan Bossart wrote:
>> On Sat, Jan 29, 2022 at 12:50:18PM -0800, Nathan Bossart wrote:
>>> Here is a new revision. I've moved basic_archive to contrib, hardened it
>>> as suggested, and ad
On Sat, Jan 29, 2022 at 04:31:48PM -0800, Nathan Bossart wrote:
> On Sat, Jan 29, 2022 at 12:50:18PM -0800, Nathan Bossart wrote:
>> Here is a new revision. I've moved basic_archive to contrib, hardened it
>> as suggested, and added shutdown support for archive modules.
>
> cfbot was unhappy with
On Sat, Jan 29, 2022 at 12:50:18PM -0800, Nathan Bossart wrote:
> Here is a new revision. I've moved basic_archive to contrib, hardened it
> as suggested, and added shutdown support for archive modules.
cfbot was unhappy with v14, so here's another attempt. One other change I
am pondering is sur
Here is a new revision. I've moved basic_archive to contrib, hardened it
as suggested, and added shutdown support for archive modules.
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
>From f62fea53b93ba7181dfe084b4100eba59eb82aaa Mon Sep 17 00:00:00 2001
From: Nathan Bossart
Date:
On Fri, Jan 28, 2022 at 03:20:41PM -0500, Robert Haas wrote:
> On Fri, Jan 28, 2022 at 3:01 PM Nathan Bossart
> wrote:
>> I discussed the two main deficiencies I'm aware of with basic_archive
>> earlier [0]. The first one is the issue with "incovenient" server crashes
>> (mentioned below).
>
>
On Fri, Jan 28, 2022 at 3:01 PM Nathan Bossart wrote:
> I discussed the two main deficiencies I'm aware of with basic_archive
> earlier [0]. The first one is the issue with "incovenient" server crashes
> (mentioned below).
Seems easy enough to rectify, if it's just a matter of silently-succeed-i
On Fri, Jan 28, 2022 at 02:06:50PM -0500, Robert Haas wrote:
> I've committed 0001 now. I don't see anything particularly wrong with
> the rest of this either, but here are a few comments:
Thanks!
> - I wonder whether it might be better to promote the basic archiving
> module to contrib (as compa
On Thu, Jan 13, 2022 at 2:38 PM Bossart, Nathan wrote:
> Here is another rebase for cfbot.
I've committed 0001 now. I don't see anything particularly wrong with
the rest of this either, but here are a few comments:
- I wonder whether it might be better to promote the basic archiving
module to co
On 11/2/21, 8:07 AM, "Bossart, Nathan" wrote:
> The main motivation is provide a way to archive without shelling out.
> This reduces the amount of overhead, which can improve archival rate
> significantly. It should also make it easier to archive more safely.
> For example, many of the common she
On 11/10/21, 10:42 AM, "David Steele" wrote:
> OK, I haven't had to go over the patch in detail so I didn't realize the
> module was not backwards compatible. I'll have a closer look soon.
It's backward-compatible in the sense that you'd be able to switch
archive_library to "shell" to continue us
On 11/10/21 1:22 PM, Bossart, Nathan wrote:
On 11/10/21, 8:10 AM, "David Steele" wrote:
I would prefer this module to be in core as our standard implementation
and load by default in a vanilla install.
Hm. I think I disagree with putting it in contrib and with making it
the default archive
On 11/10/21, 8:10 AM, "David Steele" wrote:
> On 11/7/21 1:04 AM, Fujii Masao wrote:
>> It's helpful if you share how much this approach reduces
>> the amount of overhead.
>
> FWIW we have a test for this in pgBackRest. Running
> `archive_command=pgbackrest archive-push ...` 1000 times via system(
On 11/7/21 1:04 AM, Fujii Masao wrote:
On 2021/11/03 0:03, Bossart, Nathan wrote:
On 11/1/21, 9:44 PM, "Fujii Masao" wrote:
What is the main motivation of this patch? I was thinking that
it's for parallelizing WAL archiving. But as far as I read
the patch very briefly, WAL file name is still
On 2021/11/03 0:03, Bossart, Nathan wrote:
On 11/1/21, 9:44 PM, "Fujii Masao" wrote:
What is the main motivation of this patch? I was thinking that
it's for parallelizing WAL archiving. But as far as I read
the patch very briefly, WAL file name is still passed to
the archive callback functio
On 11/2/21, 9:46 AM, "Robert Haas" wrote:
> On Tue, Nov 2, 2021 at 12:39 PM Bossart, Nathan wrote:>
>> On 11/2/21, 9:17 AM, "Robert Haas" wrote:
>> You could still introduce GUCs in _PG_init(), but they couldn't be
>> defined as PGC_POSTMASTER.
>
> It seems like PGC_POSTMASTER isn't very desirab
On Tue, Nov 2, 2021 at 12:39 PM Bossart, Nathan wrote:>
> On 11/2/21, 9:17 AM, "Robert Haas" wrote:
> You could still introduce GUCs in _PG_init(), but they couldn't be
> defined as PGC_POSTMASTER.
It seems like PGC_POSTMASTER isn't very desirable anyway. Wouldn't you
want PGC_SIGHUP? I mean I'm
On 11/2/21, 9:17 AM, "Robert Haas" wrote:
> On Tue, Nov 2, 2021 at 12:10 PM Bossart, Nathan wrote:
>> Yes, that seems doable. My point is that I've intentionally chosen to
>> preload the libraries at the moment so that it's possible to define
>> PGC_POSTMASTER GUCs and to use RegisterBackgroundW
On Tue, Nov 2, 2021 at 12:10 PM Bossart, Nathan wrote:
> Yes, that seems doable. My point is that I've intentionally chosen to
> preload the libraries at the moment so that it's possible to define
> PGC_POSTMASTER GUCs and to use RegisterBackgroundWorker(). If we
> think that switching archive m
On 11/2/21, 8:57 AM, "Robert Haas" wrote:
> On Tue, Nov 2, 2021 at 11:26 AM Bossart, Nathan wrote:
>> Well, the current patch does require a reload since the modules are
>> preloaded, but maybe there is some way to avoid that.
>
> I think we could set things up so that if the value changes, you c
On Tue, Nov 2, 2021 at 11:26 AM Bossart, Nathan wrote:
> Well, the current patch does require a reload since the modules are
> preloaded, but maybe there is some way to avoid that.
I think we could set things up so that if the value changes, you call
a shutdown hook for the old library, load the
On 11/2/21, 8:11 AM, "Robert Haas" wrote:
> Why in the world would you want a plain hook rather than something
> closer to the way logical replication works?
>
> Plain hooks are annoying to use. If you load things at the wrong time,
> it silently doesn't work. It's also impossible to unload anythi
I've just realized I forgot to CC the active participants on the last
thread to this one, so I've attempted to do that now. I didn't
intentionally leave anyone out, but I'm sorry if I missed someone.
On 11/1/21, 10:24 PM, "Michael Paquier" wrote:
> It seems to me that this patch is not moving in
On Tue, Nov 2, 2021 at 1:24 AM Michael Paquier wrote:
> It seems to me that this patch is not moving into the right direction
> implementation-wise (I have read the arguments about
> backward-compatibility that led to the introduction of archive_library
> and its shell mode), for what looks like a
1 - 100 of 103 matches
Mail list logo
