nd follow elog.h's recommendation to the letter, but
following your mental model upthread, it doesn't seem to be strictly
necessary, and we'd need to set pltargs to NULL after decrementing its
reference count in the PG_TRY section for such future-proofing to be
effective, anyway.
Than
bytes
> test-case 1: -t1000, WAL ~16 bytes
I wonder if it's worth doing a couple of long-running tests, too.
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
ery confusing. How about naming
>>> the hash "EventTriggerCacheHash" or so?
>>
>> I think the level is the indicator here, but I have no strong opinions,
>> EventTriggerCacheHash is fine by me.
>
> The attached trivial diff does that, parking this i
e, 0001 LGTM.
I haven't had a chance to look at 0002 closely yet.
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
nsactional.
Looks reasonable to me. IIUC calling pgstat_drop_subscription() earlier
makes no real difference (besides avoiding this bug) because it is uѕing
pgstat_drop_transactional() behind the scenes.
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
ror messages, I found a few dozen
"must be superuser" errors that might be improved with the new style. If
folks feel this is worthwhile, I'll put together a patch.
[0] https://postgr.es/m/20230126002251.GA1506128%40nathanxps13
--
Nathan Bossart
Amazon Web Services: https://a
On Fri, May 12, 2023 at 04:43:08PM -0400, Tom Lane wrote:
> Nathan Bossart writes:
>> While looking around for other such error messages, I found a few dozen
>> "must be superuser" errors that might be improved with the new style. If
>> folks feel this is worthw
to break something anyway.
ERROR-ing in SetConfigOption() might be another way to dissuade folks from
messing with GUCs. This is obviously not a perfect solution.
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
On Thu, Mar 24, 2022 at 02:07:26PM +0100, Magnus Hagander wrote:
> On Wed, Mar 23, 2022 at 7:25 AM Michael Paquier wrote:
>> On Tue, Mar 15, 2022 at 03:44:39PM -0700, Nathan Bossart wrote:
>> > A simple approach could be to just set log_min_messages to PANIC before
>> >
On Thu, Mar 24, 2022 at 01:31:08PM -0700, Nathan Bossart wrote:
> A couple of other options to consider:
>
> 1) Always set log_min_messages to WARNING/ERROR/FATAL for 'postgres -C'.
> We might need some special logic for handling the case where the user is
> inspec
t;> until pg_backup_stop() is called.\n\n"));
>> }
>>
>> print_msg(_("waiting for server to shut down..."));
>
> This... can't actually happen anymore, right? Shouldn't we just pull
> all of this out?
done
so I don't intend to carry this patch further
if anyone is opposed.
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
>From 295e1e93a2ff4e655e85040d931c0d332d14b5bd Mon Sep 17 00:00:00 2001
From: Nathan Bossart
Date: Tue, 29 Mar 2022 14:56:47 -0700
Subject: [PATCH v1 1/1] R
g is seriously busted and that's ERROR-worthy.
I agree. I'll switch it to ReadDir() in the next revision so that we ERROR
instead of INFO.
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
On Tue, Mar 29, 2022 at 03:48:32PM -0700, Nathan Bossart wrote:
> On Thu, Mar 24, 2022 at 01:17:01PM +1300, Thomas Munro wrote:
>> /* we're only handling directories here, skip if it's not ours */
>> -if (lstat(path, &statbuf) == 0 && !S_ISDIR(sta
ds() stuff if
we made the value available in _PG_init() and stopped supporting GUC
overrides by extensions (e.g., ERROR-ing in SetConfigOption() when
process_shared_preload_libraries_in_progress is true).
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
On Wed, Mar 23, 2022 at 12:49:06PM -0400, Tom Lane wrote:
> Nathan Bossart writes:
>> Bertand, do you think this has any chance of making it into v15? If not,
>> are you alright with adjusting the commitfest entry to v16 and moving it to
>> the next commitfest?
>
>
d, let the server decide whether a given relation can be
+ * processed in which case the user will know about it.
+ */
nitpick: This change seems unnecessary.
I noticed upthread that there was some discussion around adding a way to
specify a schema in VACUUM and ANALYZE commands. I think this patch is
useful even if such an option is eventually added, as we'll still want
vacuumdb to obtain the full list of tables to process so that it can
effectively parallelize.
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
I think we should give this module a .gitignore file. Patch attached.
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
>From 7466f18b7cb781f4db4919faf15b1b1d3cd7bc7a Mon Sep 17 00:00:00 2001
From: Nathan Bossart
Date: Wed, 30 Mar 2022 15:28:38 -0700
Subject: [PATCH 1/1]
anged to "the
records capture every change") subtly changes the meaning of the sentence.
The rest looks good to me.
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
e aim of the log is
to ensure that the log is written..." Isn't the aim of the log to record
the database activity? Perhaps we should rewrite it to something like the
following:
A basic rule of WAL is that the log must be written before the database
files are altered, but this can be...
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
ts between server
> log and the tap test (often there's no logging for statements in the
> regress_log_*).
+1
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
t
for deviating from the standard role privilege checks.
Thoughts?
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
>From 5c1a5aaaff949fc25afaa6856ca2a85a54c8efdc Mon Sep 17 00:00:00 2001
From: Nathan Bossart
Date: Fri, 1 Apr 2022 11:40:51 -0700
Subject: [PATCH v1 1/1] Use has_pr
On Fri, Apr 01, 2022 at 10:01:28AM -0500, Justin Pryzby wrote:
> On Wed, Mar 30, 2022 at 02:22:58PM -0700, Nathan Bossart wrote:
>> I'm personally -1 for the --exclude-schema option. I don't see any
>> existing "exclude" options in vacuumdb, and the uses for su
On Mon, Apr 04, 2022 at 09:56:26AM -0400, David Steele wrote:
> Minor typo in the docs:
>
> + * capable of doing an online backup, but exclude then just in case.
>
> Should be:
>
> capable of doing an online backup, but exclude them just in case.
fixed
--
Nath
On Mon, Apr 04, 2022 at 09:36:13AM -0400, Joshua Brindle wrote:
> Good catch, I think this is a logical followup to the previous
> has_privs_of_role patch.
>
> Reviewed and +1
Thanks! I created a commitfest entry for this:
https://commitfest.postgresql.org/38/3609/
--
Na
e
all this in the attached patch.
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
>From 5d79d79472252207eea5b7dcc52010736da10296 Mon Sep 17 00:00:00 2001
From: Nathan Bossart
Date: Wed, 1 Dec 2021 23:50:49 +
Subject: [PATCH v10 1/1] remove exclusive backup mode
---
doc/
rrying about the chance of a 'stray' backup_label file existing, which
> isn't possible any longer), along with some additional testing and
> review. This is looking pretty good to me, but other thoughts are
> certainly welcome. Otherwise, I'm hoping to commit this tomorr
On Wed, Apr 06, 2022 at 03:29:15PM -0400, Stephen Frost wrote:
> This has now been committed- thanks again to everyone for their help!
Thanks!
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
erver concurrently writes to the same file via the aforementioned
bug.
[0] https://www.postgresql.org/message-id/20220222011948.GA3850532%40nathanxps13
[1] https://www.postgresql.org/message-id/20220222173711.GA3852671%40nathanxps13
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
On Thu, Feb 24, 2022 at 09:55:53AM -0800, Nathan Bossart wrote:
> Yes. I found that a crash at an unfortunate moment can produce multiple
> links to the same file in pg_wal, which seemed bad independent of archival.
> By fixing that (i.e., switching from durable_rename_excl() to
> du
On Fri, Apr 08, 2022 at 10:20:27AM -0400, Robert Haas wrote:
> On Thu, Apr 7, 2022 at 6:23 PM Nathan Bossart
> wrote:
>> On Thu, Feb 24, 2022 at 09:55:53AM -0800, Nathan Bossart wrote:
>> > Yes. I found that a crash at an unfortunate moment can produce multiple
>>
is stuff a bit closer. I've
frequently found myself trying to reason about all the different states
that callers of these functions can produce, so any changes that help
simplify matters are a win in my book.
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
On Fri, Apr 08, 2022 at 09:53:12AM -0700, Nathan Bossart wrote:
> On Fri, Apr 08, 2022 at 10:38:03AM -0400, Robert Haas wrote:
>> I'd actually be in favor of nuking durable_rename_excl() from orbit
>> and putting the file-exists tests in the callers. Otherwise, someone
>
-then-durable-rename version of this for back-patching
if that is still the route we want to go.
[0] https://postgr.es/me/20210318014812.ds2iz4jz5h7la6un%40alap3.anarazel.de
[1] https://postgr.es/m/20210318023004.gz2aejhze2kkkqr2%40alap3.anarazel.de
--
Nathan Bos
On Wed, Mar 30, 2022 at 09:21:30AM -0700, Nathan Bossart wrote:
> Here is an updated patch set.
rebased
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
>From a92ccf47c9c334eea5b8d07b8fcab7031181c37e Mon Sep 17 00:00:00 2001
From: Nathan Bossart
Date: Tue, 15 Feb 2022 09
On Thu, Mar 17, 2022 at 04:12:12PM -0700, Nathan Bossart wrote:
> It seems unlikely that this will be committed for v15, so I've adjusted the
> commitfest entry to v16 and moved it to the next commitfest.
rebased
--
Nathan Bossart
Amazon Web Services: https://aws.amazo
tch I posted in August, and 0003 is an attempt at blocking
GUC changes in preloaded libraries' _PG_init() functions.
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
>From 286e9d0c4d3de9d40a0021c9e18e06baf50abb74 Mon Sep 17 00:00:00 2001
From: Nathan Bossart
Date: Sat, 9 Apr 2022 1
rd to locate contemporaneous discussion.)
I traced this back a while ago. I believe the link() was first added in
November 2000 as part of f0e37a8. This even predates WAL recycling, which
was added in July 2001 as part of 7d4d5c0.
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
gt; - if (!tables_listed)
> + if (!objects_listed || objfilter == 'n')
> {
> appendPQExpBufferStr(&catalog_query, " WHERE c.relkind
> OPERATOR(pg_catalog.=) ANY (array["
>
> CppAsString2(RELKIND_RELATION) ", "
I think this deserveѕ a comment.
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
On Mon, Apr 11, 2022 at 04:36:36PM -0400, Robert Haas wrote:
> On Mon, Apr 11, 2022 at 12:44 PM Nathan Bossart
> wrote:
>> Here are some patches. 0001 reverts all the recent commits in this area,
>> 0002 is the patch I posted in August, and 0003 is an attempt at blocking
On Mon, Apr 11, 2022 at 01:44:42PM -0700, Nathan Bossart wrote:
> On Mon, Apr 11, 2022 at 04:36:36PM -0400, Robert Haas wrote:
>> If we throw an error while defining_custom_guc is true, how will it
>> ever again become false?
>
> Ah, I knew I was forgetting something this m
which GUC is being modified.
My intent was to make it clear that no parameters can be updated while
loading s_p_l, but I agree that we should mention the specific GUC
somewhere. Maybe this could go in a hint?
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
On Tue, Apr 12, 2022 at 03:46:31PM +0900, Kyotaro Horiguchi wrote:
> At Mon, 11 Apr 2022 09:52:57 -0700, Nathan Bossart
> wrote in
>> I traced this back a while ago. I believe the link() was first added in
>> November 2000 as part of f0e37a8. This even predates WAL recyc
On Tue, Apr 12, 2022 at 10:44:27AM -0700, Andres Freund wrote:
> On 2022-04-11 14:14:35 -0700, Nathan Bossart wrote:
>> Here's a new patch set. I've only changed 0003 as described above. My
>> apologies for the unnecessary round trip.
>
> ISTM we shouldn'
e.
I think that is doable. IMO it should be ѕomething like _PG_change_GUCs()
that is called before _PG_init(). The other option is to add a hook called
after _PG_init() where MaxBackends is available (in which case we likely
want GetMaxBackends() again). Thoughts?
> Meanwhile, committed 0001
t after the
> fact? But maybe there's some use case in which it makes sense to do it
> that way. A read-only GUC that advertises some calculated value,
> perhaps?
I think it'd be reasonable to allow changing custom GUCs in _PG_init().
Those aren't going to impact things like MaxBackends.
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
On Tue, Apr 12, 2022 at 04:33:39PM -0400, Tom Lane wrote:
> Nathan Bossart writes:
>> On Tue, Apr 12, 2022 at 03:12:42PM -0400, Robert Haas wrote:
>>> But if there's even one use case where adjusting GUCs at this phase is
>>> reasonable, then 0003 isn't rea
On Tue, Apr 12, 2022 at 04:58:42PM -0400, Tom Lane wrote:
> Nathan Bossart writes:
>> I think it'd be reasonable to allow changing custom GUCs in _PG_init().
>> Those aren't going to impact things like MaxBackends.
>
> It's reasonable to allow changing *most*
On Tue, Apr 12, 2022 at 05:46:36PM -0400, Tom Lane wrote:
> Nathan Bossart writes:
>> If we allow changing GUCs in _PG_init() and provide another hook where
>> MaxBackends will be initialized, do we need to introduce another GUC flag,
>> or can we get away with just blocking
ok, do we want to disallow
shmem requests anywhere else, or should we just leave it up to extension
authors to do the right thing? Many shmem requests in _PG_init() are
probably okay unless they depend on MaxBackends or another GUC that someone
might change. Given that, I think I currently prefer t
this area.
[0] https://postgr.es/m/4ad69a4c-cc9b-0dfe-0352-8b1b0cd36c7b%402ndquadrant.com
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
>From 754429b5ad4c9c8b40b66c9c0ede0a7572f0e071 Mon Sep 17 00:00:00 2001
From: Nathan Bossart
Date: Mon, 4 Apr 2022 11:56:21 -0700
Subjec
Thanks for taking a look!
On Thu, Apr 14, 2022 at 11:36:11AM +0900, Kyotaro Horiguchi wrote:
> At Wed, 13 Apr 2022 14:35:21 -0700, Nathan Bossart
> wrote in
>> I initially set out to see if it was possible to automatically adjust these
>> parameters on a standby, but that is
On Thu, Apr 14, 2022 at 01:50:24PM +0800, Julien Rouhaud wrote:
> On Wed, Apr 13, 2022 at 11:30:40AM -0700, Nathan Bossart wrote:
>> If we do move forward with the shmem request hook, do we want to disallow
>> shmem requests anywhere else, or should we just leave it up to extensio
omething that we think is safer (e.g., stat then
rename), but that might just introduce a different set of problems.
[0] https://postgr.es/m/20220408194345.GA1541826%40nathanxps13
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
bother filtering by relation type. Instead, let the server
> + * decide whether a given relation can be processed in which case the
> + * user will know about it. If there is a filter by schema the use of
> + * --table is not possible so we have to filter by relation type too.
>*/
> - if (!tables_listed)
> + if (!objects_listed || objfilter == OBJFILTER_SCHEMA)
Do we need to check for objects_listed here? IIUC we can just check for
objfilter != OBJFILTER_TABLE.
Unless I'm missing something, schema_is_exclude appears to only be used for
error checking and doesn't impact the generated catalog query. It looks
like the relevant logic disappeared after v4 of the patch.
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
On Thu, Apr 14, 2022 at 12:39:46PM -0400, Tom Lane wrote:
> Robert Haas writes:
>> On Thu, Apr 14, 2022 at 12:22 PM Nathan Bossart
>> wrote:
>>>> I'd be in favor of a hard break.
>
>>> Yeah, this is a good point. If we're okay with breaking ex
On Mon, Apr 18, 2022 at 07:33:54PM -0400, Tom Lane wrote:
> Nathan Bossart writes:
>> I noticed that requests for more LWLocks follow a similar pattern as
>> regular shared memory requests, and I figured that we would want to do
>> something similar for those, but I wasn&
On Tue, Apr 19, 2022 at 05:49:13PM +0800, Julien Rouhaud wrote:
> On Mon, Apr 18, 2022 at 08:17:04PM -0400, Tom Lane wrote:
>> Nathan Bossart writes:
>> > I'm looking for a clean way to ERROR if someone attempts to call
>> > RequestAddinShmemSpace() or RequestNam
ems to me that the
> crash recovery case, which doesn't have that complication, ought to be
> safe too. But I might well be missing something, so if you see a
> problem, please speak up!
Your reasoning seems sound to me.
[0] https://postgr.es/m/C1EE64B0-D4DB-40F3-98C8-0CED324D34CB%40amazon.com
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
. I'm just curious
> if anyone has a quick answer for this unusual correspondence.
I see that SlruInternalWritePage() increments ckpt_bufs_written, so my
first guess would be that it's due to something like CheckPointCLOG().
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
an optimization in
some cases, but I am skeptical that it really makes that much of a
difference in practice.
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
Thanks for the new patch! I think this is on the right track.
On Wed, Apr 20, 2022 at 05:15:02PM +0200, Gilles Darold wrote:
> Le 18/04/2022 à 23:56, Nathan Bossart a écrit :
>> > - if (!tables_listed)
>> > + if (!objects_listed || objfilter == OBJFILTER_SCHEMA)
>&
On Wed, Apr 20, 2022 at 12:40:52PM -0500, Justin Pryzby wrote:
> On Wed, Apr 20, 2022 at 10:38:46AM -0700, Nathan Bossart wrote:
>> Furthermore, do you think it'd be possible to dynamically generate the
>> message?
>
> Not in the obvious way, because that breaks t
her values, this seems
reasonable to me. I would even suggest removing the limit completely so
this doesn't need to be revisited in the future.
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
ou think.
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
>From c180a56055bb9c61c4bb81d586aeb99241596457 Mon Sep 17 00:00:00 2001
From: Nathan Bossart
Date: Fri, 22 Apr 2022 22:34:38 -0700
Subject: [PATCH v11 1/1] Add --schema and --exclude-schema options to
vacuumdb.
These two new
On Fri, Apr 22, 2022 at 10:57:46PM -0700, Nathan Bossart wrote:
> On Fri, Apr 22, 2022 at 11:57:05AM +0200, Gilles Darold wrote:
>> Patch v10 attached.
>
> Thanks! I've attached a v11 with some minor editorialization. I think I
> was able to improve the error handling f
On Mon, Apr 25, 2022 at 08:50:09AM +0200, Gilles Darold wrote:
> Can I change the commitfest status to ready for committers?
I've marked it as ready-for-committer.
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
#x27;m not
wedded to this approach.
[0] https://postgr.es/m/C1F7905E-5DB2-497D-ABCC-E14D4DEE506C%40yandex-team.ru
[1] https://postgr.es/m/cac4b9df-92c6-77aa-687b-18b86cb13728%40stratox.cz
[2] https://postgr.es/m/FDE157D7-3F35-450D-B927-7EC2F82DB1D6%40amazon.com
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
It's been a few weeks, so I'm marking the commitfest entry as
waiting-on-author.
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
27;t use the "TO" prefix for "ROLE" - but taking that
> liberty for consistency here is very appealing and there isn't another SQL
> clause that it would be confused with.
+1 for "member". It might not be perfect, but IMO it's the clearest
option.
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
ve in server logs along
>> > with the time it took for removing/syncing them. Thoughts?
I took another look at the example output, and I think I agree that logging
the total time for logical decoding operations is probably the best path
forward. This information would be enough to clue an administrator into
the possible causes of lengthy checkpoints, but it also wouldn't disrupt
the readability of the log statement too much.
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
> + 'cannot use options -a and -d at the same time');
> This set of tests had better use command_fails_like() to make sure
> that the correct error patterns from check_objfilter() show up?
Yes. I did this in v13.
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
&g
I don't understand the purpose of these changes. Are these related to the
fix, or is this just tidying up?
[0]
https://postgr.es/m/CA%2BTgmoY%2BSJLTjma4Hfn1sA7S6CZAgbihYd%3DKzO6srd7Ut%3DXVBQ%40mail.gmail.com
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
h for each back-branch if needed.
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
>From d489c2bff029db6e07e5028788faf869c35f886b Mon Sep 17 00:00:00 2001
From: Nathan Bossart
Date: Tue, 26 Apr 2022 11:56:50 -0700
Subject: [PATCH v3 1/2] Replace calls to durable_renam
On Wed, Apr 27, 2022 at 10:43:53AM +0900, Kyotaro Horiguchi wrote:
> At Tue, 26 Apr 2022 11:33:49 -0700, Nathan Bossart
> wrote in
>> I suspect we'll start seeing this problem more often once end-of-recovery
>> checkpoints are removed [0]. Would you mind creating a commi
> Crucial log: "invalid primary checkpoint record", "could not locate a valid
> checkpoint record".
I think this is the same issue tracked here: [0].
[0]
https://postgr.es/m/20220316.102444.2193181487576617583.horikyota.ntt%40gmail.com
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
On Wed, Apr 27, 2022 at 02:16:01PM +0900, Michael Paquier wrote:
> On Tue, Apr 26, 2022 at 08:26:09PM -0700, Nathan Bossart wrote:
>> On Wed, Apr 27, 2022 at 10:43:53AM +0900, Kyotaro Horiguchi wrote:
>>> + ControlFile->minRecoveryPoint = InvalidXLogRecPtr;
>&g
h set with these assertions added. I think at least the
xlog.c change ought to be back-patched. The problem may be unlikely, but
AFAICT the possible consequences include WAL corruption.
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
>From 8ffc337621f8a287350a7a55256b58b0585f7a1f M
Committed and back-patched.
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
On Tue, Oct 17, 2023 at 10:46:47AM -0500, Nathan Bossart wrote:
> Committed and back-patched.
... and it looks like some of the back-branches are failing for Windows.
I'm assuming this is because c290e79 was only back-patched to v15. My
first instinct is just to back-patch that one all
On Tue, Oct 17, 2023 at 12:47:29PM -0400, Tom Lane wrote:
> Nathan Bossart writes:
>> ... and it looks like some of the back-branches are failing for Windows.
>> I'm assuming this is because c290e79 was only back-patched to v15. My
>> first instinct is just to back-pat
rebased
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
>From 0934f23773a612051c36070ed1f3b8ab100c4c65 Mon Sep 17 00:00:00 2001
From: Nathan Bossart
Date: Wed, 15 Feb 2023 14:28:53 -0800
Subject: [PATCH v16 1/5] introduce routine for checking mutually exclusive
string G
rebased
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
>From 9618c243cbd3056006acda0136036b432af37830 Mon Sep 17 00:00:00 2001
From: Nathan Bossart
Date: Wed, 28 Jun 2023 15:12:18 -0700
Subject: [PATCH v2 1/3] vacuumdb: allow specifying tables or schemas to
process in
I
think standardizing on the trailing comma style will actually improve
git-blame because patches won't need to add a comma to the previous line
when adding a value.
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
> runtimes it'd allow us to start vacuuming early enough to prevent hitting
> thresholds, adapt pacing, prioritize between tables etc.
Big +1 to all of this.
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
o work, so maybe that's a good reason to keep them together. If we
do elect to keep them combined, I'd be okay with renaming it to
pg_get_identity_sequence() along with your other proposed changes.
[0] https://postgr.es/m/20170912212054.25640.55202%40wrigleys.postgresql.org
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
TRAP: failed Assert("n >= 0 && n < list->length"), File: "list.c",
Line: 770, PID: 902807
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
ink it's worth a try. It does seem simpler, and it might allow us to
sidestep some concerns about scaling when the SLRU pages are in
shared_buffers [0].
[0] https://postgr.es/m/ZPsaEGRvllitxB3v%40tamriel.snowman.net
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
dup with Heikki's pg_waldump
benchmark [0]. I haven't had a chance to dig further, unfortunately.
Assuming I'm not doing something wrong, I don't think such a result should
necessarily disqualify this optimization, though.
[0] https://postgr.es/m/ec487192-f6aa-509a-cacb-6642dad14209%40iki.fi
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
On Tue, Oct 24, 2023 at 04:09:54PM -0500, Nathan Bossart wrote:
> I'm able to reproduce the speedup with the provided benchmark on an Apple
> M1 Pro (which appears to have the required instructions). There was almost
> no change for the 512-byte case, but there was a ~60% speedup
On Tue, Oct 24, 2023 at 06:58:04PM +0200, Jelte Fennema wrote:
> On Tue, 24 Oct 2023 at 18:47, Nathan Bossart wrote:
>> BTW after applying your patches, initdb began failing with the following
>> for me:
>>
>> TRAP: failed Assert("n >= 0 && n
atch and around 2.4 seconds with it (a 25% improvement).
Given the performance characteristics and relative simplicity of the patch,
I think this could be worth doing. I suspect we'll want to do something
similar for x86, too.
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
in some way and don't negatively impact performance, then I retract my
previous comment.
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
to verify
that hash_search() works every time it is called. This behavior seems
unlikely to change anytime soon, too.
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
the
intrinsics.
Separately, I wonder if we should just always do runtime checks for the CRC
stuff whenever we can produce code with the intrinics, regardless of
whether we need extra CFLAGS. The check doesn't look terribly expensive,
and it might allow us to simplify the code a bit (especially
On Wed, Oct 25, 2023 at 02:53:31PM -0400, David Steele wrote:
> It looks like this code was missed in 39969e2a when exclusive backup was
> removed.
Indeed. I'll plan on committing this shortly.
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
On Wed, Oct 25, 2023 at 03:02:01PM -0500, Nathan Bossart wrote:
> On Wed, Oct 25, 2023 at 02:53:31PM -0400, David Steele wrote:
>> It looks like this code was missed in 39969e2a when exclusive backup was
>> removed.
>
> Indeed. I'll plan on committing this shortl
On Thu, Oct 26, 2023 at 07:28:35AM +, Xiang Gao wrote:
> On Wed, 25 Oct, 2023 at 10:43:25 -0500, Nathan Bossart wrote:
>>+# Use ARM VMULL if available and ARM CRC32C intrinsic is avaliable too.
>>+if test x"$USE_ARMV8_VMULL" = x"" && (tes
On Thu, Oct 26, 2023 at 08:53:31AM +, Xiang Gao wrote:
> On Tue, 24 Oct, 2023 20:45:39PM -0500, Nathan Bossart wrote:
>>I tried this. pg_waldump on 2 million ~8kB records took around 8.1 seconds
>>without the patch and around 7.4 seconds with it (an 8% improvement).
&g
about committable)
still applies for me, too.
[0]
https://postgr.es/m/BYAPR13MB2677ED1797C81779D17B414CA03EA%40BYAPR13MB2677.namprd13.prod.outlook.com
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
601 - 700 of 2774 matches
Mail list logo
