outside the mailing list and report back!
I see many projects have files like SECURITY.md, CODE_OF_CONDUCT.md, and
CONTRIBUTING.md, and I think it would be relatively easy to add content to
each of those for PostgreSQL, even if they just link elsewhere.
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
On Wed, Feb 28, 2024 at 02:21:49PM -0600, Nathan Bossart wrote:
> On Wed, Feb 28, 2024 at 02:07:34PM -0600, Andrew Atkinson wrote:
>> I agree that starting with the direct conversion is reasonable. Markdown
>> "modernizes" the file using a popular plain text file fo
On Wed, Feb 28, 2024 at 10:05:26PM +0100, Daniel Gustafsson wrote:
>> On 28 Feb 2024, at 19:51, Nathan Bossart wrote:
>> Is there any interest in this? If not, I'll withdraw the commitfest entry.
>
> I'm still interested, please leave it in and I'll cir
Committed. Thank you for reviewing!
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
Here is a new version of the patch that uses the new atomic read/write
functions with full barriers that were added in commit bd5132d. Thoughts?
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
>From c40594c62ccfbf75cb0d3787cb9367d15ae37de8 Mon Sep 17 00:00:00 2001
From: Nat
Committed.
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
On Thu, Feb 29, 2024 at 10:02:21PM +, Maiquel Grassi wrote:
> Sorry for the delay. I will make the adjustments as requested soon.
Looking forward to it.
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
If the benchmarks show that
the locking is a problem, we can reevaluate, but otherwise IMHO we should
try to keep it as simple/flexible as possible.
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
{
Most, if not all, of these changes seem extraneous. Do we actually need to
more strictly check SIZEOF_VOID_P?
[0] https://commitfest.postgresql.org/48/
[1] https://postgr.es/m/20230211020042.uthdgj72kp3xlqam%40awork3.anarazel.de
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
but that looks clean IMHO.
Would you ever see "conflict" as false and "invalidation_reason" as
non-null for a logical slot?
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
uot;.
Neither of these seems particularly severe to me, especially for a
benchmarking program, but I'd be curious to hear what others think.
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
On Sun, Mar 03, 2024 at 11:40:00PM +0530, Bharath Rupireddy wrote:
> On Sat, Mar 2, 2024 at 3:41 AM Nathan Bossart
> wrote:
>> Would you ever see "conflict" as false and "invalidation_reason" as
>> non-null for a logical slot?
>
> No. Because both
document the errormessage there.
Thanks for reviewing. How does this look?
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
>From 437e4fa9ec27ecf870530fc579cd7673dfcf96af Mon Sep 17 00:00:00 2001
From: Nathan Bossart
Date: Mon, 4 Mar 2024 11:15:37 -0600
Subject: [PATCH v5 1/1] Add macro
m his e-mail signature,
which has an accent over the first 'A'. I assume that's why it's not
showing up correctly in some places.
Anyway, I've committed this now. Thanks for taking a look!
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
cked up by a committer, given it has been reviewed by multiple
> committers so far? The scope of the change is pretty contained as well.
I think so. I would still encourage you to create an entry for this so
that it is automatically tested via cfbot [0].
[0] http://commitfest.cputube.org/
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
ing" and/or moved to the top of the page? This
seems like a relatively important notice that folks should see when
beginning to use pgcrypto.
* Should we actually document the exact list of algorithms along with
detailed reasons? This list seems prone to becoming outdated.
--
Nathan Bo
# in milliseconds; 0 disables
I think we might want to turn this feature off by default, at least for the
first release.
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
On Mon, Oct 23, 2023 at 03:25:42PM -0500, Nathan Bossart wrote:
> rebased
I saw that this thread was referenced elsewhere [0], so I figured I'd take
a fresh look. From a quick glance, I'd say 0001 and 0002 are pretty
reasonable and could probably be committed for v17. 0003 prob
EM/PGDay_2024_Developer_Meeting#The_Path_to_un-reverting_the_MAINTAIN_privilege
[1] https://commitfest.postgresql.org/47/4836/
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
>From d2598b78f0796be20ad322fcb3b9ef7cfaa76491 Mon Sep 17 00:00:00 2001
From: Nathan Bossart
Date: Tue, 5 Mar 2
On Tue, Mar 05, 2024 at 11:50:36AM +0100, Daniel Gustafsson wrote:
>> On 4 Mar 2024, at 23:49, Nathan Bossart wrote:
>> * Should this be a "Warning" and/or moved to the top of the page? This
>> seems like a relatively important notice that folks should see when
&
//wiki.postgresql.org/wiki/Mailing_Lists#Email_etiquette_mechanics
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
On Wed, Mar 06, 2024 at 12:50:38AM +0530, Bharath Rupireddy wrote:
> On Mon, Mar 4, 2024 at 2:11 PM Bertrand Drouvot
> wrote:
>> On Sun, Mar 03, 2024 at 03:44:34PM -0600, Nathan Bossart wrote:
>> > Unless I am misinterpreting some details, ISTM we could renam
On Tue, Mar 05, 2024 at 11:38:37PM +0530, Bharath Rupireddy wrote:
> On Tue, Mar 5, 2024 at 7:34 AM Nathan Bossart
> wrote:
>> Is there any way to simplify this? For
>> example, would it be possible to make an enum that tracks the
>> streaming_replication_retry_interval
the
init_callback.
> /*
> * Module Load Callback
> */
> void
> _PG_init(void)
> {
> + if (!process_shared_preload_libraries_in_progress)
> + ereport(ERROR,
> +
> (errcode(ERRCODE_OBJECT_NOT_IN_PREREQUISITE_STATE),
>
On Tue, Mar 05, 2024 at 05:14:46PM -0800, Jacob Champion wrote:
> On Tue, Mar 5, 2024 at 1:51 PM Nathan Bossart
> wrote:
>> I don't have a strong opinion about making this configurable, but I do
>> think we should consider making this a hash table so that we can set
&
On Wed, Mar 06, 2024 at 10:02:43AM +0530, Bharath Rupireddy wrote:
> On Wed, Mar 6, 2024 at 1:22 AM Nathan Bossart
> wrote:
>> I was thinking of something more like
>>
>> typedef enum
>> {
>> NO_FORCE_SWITCH_TO_STREAMING,
Here is another rebase. Given the size of this patch set and the lack of
review, I am going to punt this one to v18.
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
>From dd69e5987b477818f60b202af5fb9b2603dc8acb Mon Sep 17 00:00:00 2001
From: Nathan Bossart
Date: Wed, 15 Feb 2
;d allow similar combinations in vacuumdb, but I believe that
would require a much more invasive patch, and I've already spent far more
time on this change than I wanted to.
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
>From 84b3f5a8275d53707b15208d761567372b7b20a5 Mon Sep 1
On Tue, Mar 05, 2024 at 10:12:35AM -0600, Nathan Bossart wrote:
> Thanks to Jeff's recent work with commits 2af07e2 and 59825d1, the issue
> that led to the revert of the MAINTAIN privilege and the pg_maintain
> predefined role (commit 151c22d) should now be resolved. Specifically,
I don't think anything discussed in this thread is ready for v17, so I am
going to punt it to v18.
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
for the
> previous message?
I do not know, sorry. I personally use mutt for the lists.
> BTW: Created the commit-fest submission.
Thanks. I intend to provide a more detailed review shortly, as I am aiming
to get this one committed for v17.
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
nf;
> the configure file in the submitted patch is not relevant, only
> configure.ac matters.
Agreed. I didn't intend for this to be a major review point, and I
apologize for the extra noise.
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
eful. I scanned
through this thread and didn't see any recent benchmark results for the
latest form of the patch. I think it's worth verifying that we are still
seeing the expected improvements.
[0] https://postgr.es/m/202402071953.5c4z7t6kl7ts%40alvherre.pgsql
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
se...
[0]
https://postgr.es/m/CA%2BhUKGL0bikWSC2XW-zUgFWNVEpD_gEWXndi2PE5tWqmApkpZQ%40mail.gmail.com
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
testing it out and looking at the code, and it seems generally reasonable
to me. Do you think it's worth adding something like a
pg_column_toast_num_chunks() function that returns the number of chunks for
the TOASTed value, too?
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
essages, and I am
planning to commit this early next week.
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
>From 460da2161265b042079727c1178eff92b3d537b6 Mon Sep 17 00:00:00 2001
From: Nathan Bossart
Date: Fri, 8 Mar 2024 14:35:07 -0600
Subject: [PATCH v4 1/3] vacuumdb: Allow
On Fri, Mar 08, 2024 at 03:31:55PM +0900, Yugo NAGATA wrote:
> On Thu, 7 Mar 2024 16:56:17 -0600
> Nathan Bossart wrote:
>> to me. Do you think it's worth adding something like a
>> pg_column_toast_num_chunks() function that returns the number of chunks for
>> the T
tes the test
> timeout.
Thanks for confirming! I'm assuming this just masks the underlying
issue...
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
On Sat, Mar 09, 2024 at 11:57:18AM +0900, Yugo NAGATA wrote:
> On Fri, 8 Mar 2024 16:17:58 -0600
> Nathan Bossart wrote:
>> Is this guaranteed to be TOASTed for all possible page sizes?
>
> Should we use block_size?
>
> SHOW block_size \gset
> INSERT INTO test
#x27;max_slot_xid_age' can be
> another parameter to allow vacuum to proceed removing the rows which
> otherwise it wouldn't have been as those would be required by some
> slot.
Yeah, the idea is to help prevent transaction ID wraparound, so I would
expect max_slot_xid_age to
On Fri, Mar 08, 2024 at 04:03:22PM -0600, Nathan Bossart wrote:
> On Fri, Mar 08, 2024 at 09:33:19AM +, Dean Rasheed wrote:
>> I think this is good to go.
>
> Thanks. In v4, I've added a first draft of the commit messages, and I am
> planning to commit this earl
tc. in minor releases. I think a "minor release" of Postgres is
more similar to what other projects would call a "patch version."
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
Else, we'll try to process it in 32-bit chunks. Any remaining
bytes will be processed one-by-one.
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
On Mon, Mar 11, 2024 at 05:17:13PM -0400, Bruce Momjian wrote:
> On Mon, Mar 11, 2024 at 04:12:04PM -0500, Nathan Bossart wrote:
>> I've read that the use of the term "minor release" can be confusing. While
>> the versioning page clearly describes what is eligib
On Thu, Mar 07, 2024 at 10:50:00AM -0600, Nathan Bossart wrote:
> Given all of this code was previously reviewed and committed, I am planning
> to forge ahead and commit this early next week, provided no objections or
> additional feedback materialize.
Jeff Davis and I spent some additi
I did some light editing to prepare this for commit.
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
>From 38c78bd92a7b4d4600e6f0dbe58283c21ea87d50 Mon Sep 17 00:00:00 2001
From: Nathan Bossart
Date: Tue, 12 Mar 2024 22:04:25 -0500
Subject: [PATCH v10 1/1]
rrounding large portions of
the popcount code with this macro. This might even be a necessary step
towards building these files in an architecture-specific fashion.
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
g these files in
>> an
>> architecture-specific fashion.
>
> I see the point here; however, this will take some time to get right
> especially since I don't have a Windows box to do compiles on. Should I
> attempt to do this in this patch?
This might also be less importa
no one else volunteers, I could probably give this a try once v17 is
frozen.
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
On Wed, Mar 13, 2024 at 09:49:26AM -0700, Jeff Davis wrote:
> Looks good to me. Thank you for expanding on the comment, as well.
Thanks for reviewing! Committed.
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
On Mon, Dec 12, 2022 at 07:01:01AM -0500, Andrew Dunstan wrote:
> On 2022-12-09 Fr 13:44, Nathan Bossart wrote:
>> Any thoughts on $SUBJECT?
>
> Yeah, the discussion got way off into the weeds here. I think the
> original proposal seems reasonable. Please add it to the next C
On Mon, Dec 12, 2022 at 11:15:43AM -0500, Robert Haas wrote:
> Any strenuous objections?
Nope. In fact, +1. Until more work is done to alleviate the performance
issues, this information will likely prove useful.
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
On Sat, Dec 10, 2022 at 12:41:09PM -0800, Nathan Bossart wrote:
> On Sat, Dec 10, 2022 at 12:07:12PM -0800, Jeff Davis wrote:
>> It seems like the discussion on VACUUM/CLUSTER/REINDEX privileges is
>> happening in the other thread. What would you like to accomplish in
>> th
On Mon, Dec 12, 2022 at 12:04:27PM -0800, Nathan Bossart wrote:
> Patch attached. I ended up reverting some parts of the VACUUM/ANALYZE
> patch that were no longer needed (i.e., if the user doesn't have permission
> to VACUUM, we don't need to separately check whether the user
conds to 95 seconds on my machine. This probably lowers the amount
of test coverage we get on the wal_retrieve_retry_interval code paths, but
if that's a concern, perhaps we should write a test specifically for
wal_retrieve_retry_interval.
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
need to be
started, it only wakes up every 3 minutes.
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
][2].
Will take a look.
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
d with
> his suggested fix. I intend to commit soon.
LGTM
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
On Tue, Dec 13, 2022 at 04:41:05PM -0800, Nathan Bossart wrote:
> On Tue, Dec 13, 2022 at 07:20:14PM -0500, Tom Lane wrote:
>> I certainly don't think that "wake the apply launcher every 1ms"
>> is a sane configuration. Unless I'm missing something basic about
committed.
Thanks for reviewing.
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
to simplify it. It uses the philosophy that, if you have
> permissions to lock at a given mode, you should be able to lock at
> strictly less-conflicting modes as well.
+1. Your patch looks reasonable to me.
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
On Thu, Dec 08, 2022 at 04:08:40PM -0500, Robert Haas wrote:
> On Thu, Dec 8, 2022 at 1:13 PM Nathan Bossart
> wrote:
>> Currently, CLUSTER, REFRESH MATERIALIZED VIEW, and REINDEX (minus REINDEX
>> SCHEMA|DATABASE|SYSTEM) require ownership of the relation or superuser. In
>
On Wed, Dec 14, 2022 at 12:42:32PM -0500, Tom Lane wrote:
> Nathan Bossart writes:
>> My first thought is that the latter two uses should be moved to a new
>> parameter, and the apply launcher should store the last start time for each
>> apply worker like the apply workers
On Wed, Dec 14, 2022 at 07:05:34PM +0100, Alvaro Herrera wrote:
> On 2022-Dec-14, Nathan Bossart wrote:
>> On Wed, Dec 14, 2022 at 12:07:13PM +0300, Pavel Luzanov wrote:
>> > I found that granting MAINTAIN privilege does not allow the TOAST table to
>> > be vacuumed.
&
On Wed, Dec 14, 2022 at 01:23:18PM -0500, Tom Lane wrote:
> Nathan Bossart writes:
>> I'm reasonably certain the launcher is already signaled like you describe.
>> It'll just wait to start new workers if it's been less than
>> wal_retrieve_retry_interval
ual, so the launcher would typically start new workers
immediately. But if you and/or others feel this is worthwhile, I don't
mind working on the patch.
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
On Wed, Dec 14, 2022 at 11:05:13AM -0800, Jeff Davis wrote:
> On Wed, 2022-12-14 at 10:16 -0800, Nathan Bossart wrote:
>> Okay. Should all the privileges governed by MAINTAIN apply to a
>> relation's
>> TOAST table as well?
>
> Yes, I agree.
This might be tricky,
On Thu, Dec 15, 2022 at 09:12:26AM +0900, Michael Paquier wrote:
> On Wed, Dec 14, 2022 at 03:29:39PM -0800, Nathan Bossart wrote:
>> On Wed, Dec 14, 2022 at 11:05:13AM -0800, Jeff Davis wrote:
>>> On Wed, 2022-12-14 at 10:16 -0800, Nathan Bossart wrote:
>>>> Ok
easons you describe.
[0] https://postgr.es/m/BA8951E9-1524-48C5-94AF-73B1F0D7857F%40amazon.com
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
D patched (v9)
check-world -j8 165 138
subscription 120 75
recovery 111 108
[0] https://postgr.es/m/21344.1498494720%40sss.pgh.pa.us
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
>From a80c2b3b2a80d024b72be9fca6b5d4136b8b8272 Mon Sep 17 00:00
ansaction block, which should probably be added to my documentation patch
[0].
[0] https://commitfest.postgresql.org/41/4054/
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
diff --git a/src/backend/commands/cluster.c b/src/backend/commands/cluster.c
index 8966b75bd1..6d09d1c6
Here is a new version of the patch. I've moved the privilege checks to a
new function, and I added a note in the docs about clustering partitioned
tables in a transaction block (it's not allowed).
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
diff --git a/doc/sr
think this would be easy to
change.
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
On Thu, Dec 15, 2022 at 09:13:54PM -0800, Nathan Bossart wrote:
> I do wonder whether this is something we really need to be concerned about.
> In the worst case, you might be able to VACUUM a table with a concurrent
> owner change.
I suppose we might want to avoid running the index fun
ands on its TOAST table. Also, the maintenance
commands that flow through to the partitions or the TOAST table should no
longer error due to permissions when the user only has MAINTAIN on the
paritioned table or main relation.
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
d
> nit: it would be better if the variable `root` can be aligned with variable
> `ancestors`.
Hm. It looked alright on my machine. In any case, I'll be sure to run
pgindent at some point. This patch is still in early stages.
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.
On Thu, Dec 15, 2022 at 02:47:21PM -0800, Nathan Bossart wrote:
> I tried setting wal_retrieve_retry_interval to 1ms for all TAP tests
> (similar to what was done in 2710ccd), and I noticed that the recovery
> tests consistently took much longer. Upon further inspection, it looks
> l
On Sun, Dec 18, 2022 at 04:25:15PM -0800, Ted Yu wrote:
> + * Note: Because this function assumes that the realtion whose OID is
> passed as
>
> Typo: realtion -> relation
Thanks, fixed.
--
Nathan Bossart
Amazon Web Services: https://aws.a
p for use as an
archive_cleanup_library, but I don't think that needs to be a part of this
patch set.
[0] https://postgr.es/m/668D2428-F73B-475E-87AE-F89D67942270%40amazon.com
[1] https://git.postgresql.org/gitweb/?p=postgresql.git;a=commit;h=5ef1eef
--
Nathan Bossart
Amazon Web Service
On Tue, Dec 27, 2022 at 02:11:11PM -0800, Andres Freund wrote:
> On 2022-12-27 11:24:49 -0800, Nathan Bossart wrote:
>> I've attached a patch set that adds the restore_library,
>> archive_cleanup_library, and recovery_end_library parameters to allow
>> archive recovery v
On Tue, Dec 27, 2022 at 02:45:30PM -0800, Andres Freund wrote:
> On 2022-12-27 14:37:11 -0800, Nathan Bossart wrote:
>> On Tue, Dec 27, 2022 at 02:11:11PM -0800, Andres Freund wrote:
>> > On 2022-12-27 11:24:49 -0800, Nathan Bossart wrote:
>> >> * pg_rewind uses rest
d mine is that I've
exposed vac_update_datfrozenxid() via a function instead of a VACUUM
option. IMHO that feels a little more natural, but I can't say I feel too
strongly about it.
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
>From a46934c1a6cec7a5efe8a25d49507a7a2f59c928 Mon Sep 17
SlotsWaitCompletion() to mark the slots as idle so that the
slot array can be reused after it is called.
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
On Wed, Dec 28, 2022 at 04:20:19PM -0500, Tom Lane wrote:
> Nathan Bossart writes:
>> I think the main difference between your patch and mine is that I've
>> exposed vac_update_datfrozenxid() via a function instead of a VACUUM
>> option. IMHO that feels a little more
Thanks for reviewing.
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
es the action like most of the other options,
but I think both choices are sufficiently clear.
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
values. The
overwrite-corrupt-values logic might make this a little more complicated,
but I think it'd be sufficient to force the pg_class scan to complete if we
ever see a value "in the future." Overwriting the corrupt value might be
delayed, but it would eventually happen once th
, I've introduced an
optional shutdown callback.
* Parameter misconfigurations are now always ERRORs. I'm less confident
that we can get by with just a WARNING now that restore_library can be
changed via SIGHUP, and this makes things more consistent with
archive_library/command.
--
Nath
On Thu, Dec 29, 2022 at 03:29:15PM -0500, Tom Lane wrote:
> Nathan Bossart writes:
>> On Thu, Dec 29, 2022 at 12:22:58PM -0500, Tom Lane wrote:
>>> Justin Pryzby writes:
>>>> VACUUM (UPDATE_DATABASE_STATS {yes,no,only})
>>>>> VACUUM (DATABAS
s://postgr.es/m/BA8951E9-1524-48C5-94AF-73B1F0D7857F%40amazon.com
[1] https://postgr.es/m/20221215191246.GA252861%40nathanxps13
[2] https://postgr.es/m/20221229213719.GA301584%40nathanxps13
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
>From b123ddaf560a647536f5a7e52993401755da8650 M
hange, we'd loop through
the timelines for both XLOG_FROM_PG_ARCHIVE and XLOG_FROM_PG_WAL, whereas
now we only loop through the timelines once. However, I doubt this makes
much difference in practice. You'd only do the extra loop whenever
restoring from the archives failed.
--
Nat
On Wed, Dec 14, 2022 at 05:09:46AM +, Imseih (AWS), Sami wrote:
> Attached version addresses the above and the previous comments.
cfbot is complaining that this patch no longer applies. Sami, would you
mind rebasing it?
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
I filed a commitfest entry for this so that it doesn't get lost:
https://commitfest.postgresql.org/41/4093
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
On Tue, Dec 13, 2022 at 07:40:59PM -0800, Nathan Bossart wrote:
> Granted, this likely won't create as much noise as a database-wide VACUUM,
> but perhaps we could add a relkind check in expand_vacuum_rel() and swap
> the checks in vacuum_rel()/analyze_rel(), too. I don't know
On Sun, Dec 18, 2022 at 03:36:07PM -0800, Nathan Bossart wrote:
> This seems to have somehow broken the archiving tests on Windows, so
> obviously I owe some better analysis here. I didn't see anything obvious
> in the logs, but I will continue to dig.
On Windows, WaitForWALToB
Here is a rebased patch set for cfbot.
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
>From 7fecc9c9dc8a0ebbfbb1828a8410dac1be1ce7f5 Mon Sep 17 00:00:00 2001
From: Nathan Bossart
Date: Fri, 23 Dec 2022 16:35:25 -0800
Subject: [PATCH v3 1/3] Move the code to restore files via
On Tue, Jan 03, 2023 at 11:03:32AM +0530, Amit Kapila wrote:
> On Thu, Dec 15, 2022 at 4:47 AM Nathan Bossart
> wrote:
>> On Wed, Dec 14, 2022 at 02:02:58PM -0500, Tom Lane wrote:
>> > Maybe we could have workers that are exiting for that reason set a
>> > flag say
On Tue, Jan 03, 2023 at 11:43:59AM +0530, Amit Kapila wrote:
> On Wed, Dec 7, 2022 at 11:42 PM Nathan Bossart
> wrote:
>> After sleeping on this, I think we can do better. IIUC we can simply check
>> for AllTablesyncsReady() at the end of process_syncing_tables_for_apply()
plicit by
> setting currentSource to XLOG_FROM_PG_WAL in the state machine. I
> think it doesn't alter the existing state machine or add any new extra
> lookups in pg_wal.
I'm assuming this change would simplify your other patch that modifieѕ
WaitForWALToBecomeAvailable() [0]. Is tha
On Tue, Jan 03, 2023 at 09:59:17AM -0800, Nathan Bossart wrote:
> Here is a rebased patch set for cfbot.
I noticed that cfbot's Windows tests are failing because the backslashes in
the archive directory path are causing escaping problems. Here is an
attempt to fix that by conver
401 - 500 of 2774 matches
Mail list logo
