On Sun, Dec 18, 2022 at 03:30:18PM -0800, Nathan Bossart wrote:
> Here is a new version of the patch. Besides some cleanup, I added an index
> on reltoastrelid for the toast-to-main-relation lookup. Before I bother
> adjusting the tests and documentation, I'm curious to he
over from BuildRestoreCommand(), and AFAICT it
is only necessary because pg_rewind doesn't support %r in restore_command.
IMHO this behavior is counterintuitive and possibly error-prone and should
result in an ERROR instead. Since pg_rewind is the only special case, it
could independently chec
lidations so that we can get the latest state and then perform
> this check. I guess if we can do that then we can directly move the
> restart logic to the end.
IMO this shows the advantage of just waking up the worker. It doesn't
change the apply worker's behavior besides making it
On Wed, Jan 04, 2023 at 10:57:43AM +0530, Amit Kapila wrote:
> On Tue, Jan 3, 2023 at 11:40 PM Nathan Bossart
> wrote:
>> My approach was to add a variable to LogicalRepWorker that indicated
>> whether a worker needed to be restarted immediately. While this is a
>>
just keep
> things like that with the lack of noise.
I've proposed something like what you are describing in another thread [0].
I intended to simply fix and document the current behavior in this thread
and to take up any new changes in the other one.
[0] https://commitfest.postgresql.org/41/
On Wed, Jan 04, 2023 at 10:12:19AM -0800, Nathan Bossart wrote:
> From the discussion thus far, it sounds like the alternatives are to 1) add
> a global flag that causes wal_retrieve_retry_interval to be bypassed for
> all workers or to 2) add a hash map in the launcher and a
> restart
On Thu, Jan 05, 2023 at 09:09:12AM +0530, Amit Kapila wrote:
> On Wed, Jan 4, 2023 at 11:03 PM Nathan Bossart
> wrote:
>> On Wed, Jan 04, 2023 at 09:41:47AM +0530, Amit Kapila wrote:
>> > If so, we probably also need to
>> > ensure that table_states_vali
On Wed, Jan 04, 2023 at 08:12:37PM -0800, Nathan Bossart wrote:
> On Thu, Jan 05, 2023 at 09:09:12AM +0530, Amit Kapila wrote:
>> But there doesn't appear to be any guarantee that the result for
>> AllTablesyncsReady() will change between the time it is invoked
>> earl
e so that
> committers can decide here if it should be applied.
That's fine with me. I added the warning messages in v4.
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
diff --git a/doc/src/sgml/ref/cluster.sgml b/doc/src/sgml/ref/cluster.sgml
index 145101e6a5..749b410e16 100644
--- a
other patch or discard this one as needed. I'm
not positive that we'll proceed with the proposed approach for the other
one, but the patch tracked here should still be worthwhile regardless.
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
On Thu, Jan 05, 2023 at 11:34:37AM +0530, Amit Kapila wrote:
> On Thu, Jan 5, 2023 at 10:16 AM Nathan Bossart
> wrote:
>> In v12, I moved the restart for two_phase mode to the end of
>> process_syncing_tables_for_apply() so that we don't need to rely on another
&
s odd to me.
Yeah, this flag certainly feels hacky. With a shared hash table, we could
just have backends remove the last-start-time entry directly, and we
wouldn't need the flag.
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
On Thu, Jan 05, 2023 at 09:29:24AM -0800, Nathan Bossart wrote:
> On Thu, Jan 05, 2023 at 10:57:58AM +0530, Amit Kapila wrote:
>> True, if we want we can use dshash for this.
>
> I'll look into this.
Here is an attempt at using dshash. This is quite a bit cleaner since w
Apparently I forgot to run all the tests before posting v4. Here is a new
version of the patch that should pass all tests.
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
diff --git a/doc/src/sgml/ref/cluster.sgml b/doc/src/sgml/ref/cluster.sgml
index 145101e6a5..749b410e16 100644
I found some additional places that should remove the last-start time from
the hash table. I've added those in v14.
On Fri, Jan 06, 2023 at 10:30:18AM +0530, Amit Kapila wrote:
> On Thu, Jan 5, 2023 at 10:49 PM Nathan Bossart
> wrote:
>> On Thu, Jan 05, 2023 at 11:34:37AM +
temp tables normally aren't very interesting from a permissions
perspective, so perhaps there is an argument for always excluding temp
tables without a pattern. After all, \dp always excludes indexes and TOAST
tables. However, it looks like \dt includes temp tables, and I didn't see
any other meta-commands that excluded them.
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
g wal_retrieve_retry_interval to 1ms in the tests.
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
rebased for cfbot
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
>From 7e72b0a9f06fdfa00d5320d4c3303e67788878aa Mon Sep 17 00:00:00 2001
From: Nathan Bossart
Date: Thu, 29 Dec 2022 15:31:49 -0800
Subject: [PATCH v2 1/1] add PROCESS_MAIN to VACUUM
---
doc/src/sgml/
rebased for cfbot
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
diff --git a/doc/src/sgml/monitoring.sgml b/doc/src/sgml/monitoring.sgml
index cf220c3bcb..7661c0c86e 100644
--- a/doc/src/sgml/monitoring.sgml
+++ b/doc/src/sgml/monitoring.sgml
@@ -1996,6 +1996,16 @@ postgres
rebased for cfbot
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
>From 2466001a3ae6f94aac8eff45b488765e619bea1b Mon Sep 17 00:00:00 2001
From: Nathan Bossart
Date: Thu, 1 Dec 2022 20:50:21 -0800
Subject: [PATCH v2 1/1] suppress unnecessary wakeups in logical/worker.c
---
gh I appreciate that we do that now. There's nothing in the docs
> to indicate that that's the case.
Agreed.
> Anyway, I've pushed the v2 patch as-is. If anyone feels strongly
> enough that we should change its behaviour for temp tables, then we
> can still discuss that.
Thanks!
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
On Mon, Jan 09, 2023 at 09:36:12AM +0100, Peter Eisentraut wrote:
> On 04.01.23 01:37, Nathan Bossart wrote:
>> On Tue, Dec 20, 2022 at 06:30:40AM +0100, Peter Eisentraut wrote:
>> > + * A value may be NULL. If the corresponding placeholder is found in the
>> >
nsensitive? If not, I think there should be
a brief comment explaining why.
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
On Tue, Jan 03, 2023 at 03:45:49PM -0800, Nathan Bossart wrote:
> I'd like to get this fixed, but I have yet to hear thoughts on the
> suggested approach. I'll proceed with adjusting the tests and
> documentation shortly unless someone objects.
As promised, here is a new v
e
accurate. However, I see that workers also register a before_shmem_exit
callback that will send SIGUSR1 to the launcher_pid currently stored in
shared memory. (I wonder if there is a memory ordering bug here.)
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
diff --git a/doc/src/s
ack-patching the fix...
+1
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
ote would be to redefine the existing pg_input_error_message() function
to return a record, but I recognize that this would inflate the patch quite
a bit due to all the existing uses in the tests. If this is the only
argument against this approach, I'm happy to help with the patch.
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
() to limit
the sleep to at most 100ms when WalReceiverRequested is set, similar to how
the sleep is limited when background workers must be restarted.
[0] https://postgr.es/m/20221215224721.GA694065%40nathanxps13
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
problem goes away. IIUC the key part is that
the postmaster's latch gets set when SIGCHLD is received, so even if
SIGUSR1 and SIGCHLD are processed out of order, WalReceiverPID gets cleared
and we try to restart it shortly thereafter. I find this much easier to
reason about.
I'll
always calling WaitLatch(), even if
wal_retrieve_retry_interval milliseconds have already elapsed and the
timeout is 0.
[0] https://postgr.es/m/20221231235019.GA1223171%40nathanxps13
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
>From d08f01156ce1ce1290bad440da97852c2aa6c24b Mon
On Wed, Jan 11, 2023 at 02:22:26PM +0100, Gilles Darold wrote:
> I'm moving this commitfest entry to Ready for Committers.
Thank you for reviewing.
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
On Wed, Jan 11, 2023 at 11:09:01AM +0100, Peter Eisentraut wrote:
> committed with that fixed
While rebasing my recovery modules patch set, I noticed a couple of small
things that might be worth cleaning up.
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
diff --git a/src/back
g and
restoring archive files, the name still seemed somewhat accurate. That
being said, I don't mind renaming it if that's what folks want.
I've attached a new patch set that is rebased over c96de2c. There are no
other changes.
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.
u had in mind? If so, I'll
look around for anywhere else it is needed.
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
diff --git a/src/backend/postmaster/checkpointer.c b/src/backend/postmaster/checkpointer.c
index de0bbbfa79..e57be4f72b 100644
--- a/src/backend/postma
validAttrNumber instead of relying on it always being 0.
> - classoid == AggregateRelationId ||
I noticed that AggregateRelationId isn't listed in the ObjectProperty
array, so I think recordExtObjInitPriv() will begin erroring for that
classoid instead of ignoring it lik
lay whatever exists in pg_wal (which may be
un-filled or partly-filled) before attempting streaming. If that fails,
we'll go back to trying the archives again.
Would you mind testing this scenario?
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
On Wed, Jan 11, 2023 at 04:40:14PM -0800, Andres Freund wrote:
> On 2023-01-11 15:26:45 -0800, Nathan Bossart wrote:
>> On Wed, Jan 11, 2023 at 12:48:36PM -0800, Andres Freund wrote:
>> > Given that we check for interrupts in other parts of recovery with
>> > HandleSt
On Thu, Jan 12, 2023 at 12:20:50PM -0500, Tom Lane wrote:
> Peter Eisentraut writes:
>> On 12.01.23 01:04, Nathan Bossart wrote:
>> - classoid == AggregateRelationId ||
>>> I noticed that AggregateRelationId isn't listed in the ObjectP
On Thu, Jan 12, 2023 at 03:30:40PM +0900, Michael Paquier wrote:
> On Wed, Jan 11, 2023 at 11:29:01AM -0800, Nathan Bossart wrote:
>> I initially created a separate basic_restore module, but decided to fold it
>> into basic_archive to simplify the patch and tests. I hesitated
ring(pltdata, "name", pltname);
> Py_DECREF(pltname);
There's another "return" later on in this PG_TRY block. I wonder if it's
possible to detect this sort of thing at compile time.
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
ommit message:
We disable statement_timeout and lock_timeout during dump and restore,
to prevent any global settings that might exist from breaking routine
backups.
I imagine changing this could disrupt existing servers that depend on these
overrides during backups, although I
ver the distribution of data in its partitions changes
significantly.
[0]
https://www.postgresql.org/docs/devel/ddl-partitioning.html#DDL-PARTITIONING-DECLARATIVE
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
On Thu, Jan 12, 2023 at 09:49:00PM -0800, Andres Freund wrote:
> On 2023-01-12 10:44:33 -0800, Nathan Bossart wrote:
>> There's another "return" later on in this PG_TRY block. I wonder if it's
>> possible to detect this sort of thing at compile time.
>
on, shouldn't it be possible to vacuum it directly?
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
r avoiding the case where the TOAST table's OID
is reused by the time we get to it, but I'm not sure if it's sufficient to
prevent vacuuming if the privileges on the main relation have changed
across transactions. Even if it's not, I'm not sure that case is worth
worrying abou
On Fri, Jan 13, 2023 at 02:56:26PM -0800, Nathan Bossart wrote:
> Okay. Here is a new patch set.
And here is a rebased patch set (c44f633 changed the same LOCK TABLE docs).
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
>From 48be435025ba10235c821cbd298c43763cbc5a56 Mon
On Fri, Jan 13, 2023 at 03:24:09PM -0800, Jeff Davis wrote:
> For completeness, did you consider CLUSTER and REINDEX options as well?
I have not, but I can put together patches for those as well.
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
ecuted inside a transaction block.
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
I've attached a patch for $SUBJECT, which allows us to remove a use of the
unconstify macro in basic_archive. This is just a pet peeve, but maybe it
bothers others, too.
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
diff --git a/contrib/basic_archive/basic_archive.c b/co
we should keep this stuff.
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
On Sun, Jan 15, 2023 at 08:23:13AM -0500, Andrew Dunstan wrote:
> On 2023-01-14 Sa 18:11, Nathan Bossart wrote:
>> I've attached a patch for $SUBJECT, which allows us to remove a use of the
>> unconstify macro in basic_archive. This is just a pet peeve, but maybe it
>> b
ections and a predefined role
> pg_use_reserved_connections.
I've written something like this before, and I'd be happy to put together a
patch if there is interest.
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
On Mon, Jan 16, 2023 at 04:36:01PM +0900, Michael Paquier wrote:
> Once this issue was fixed, nothing else stood out, so applied this
> part.
Thanks! I've attached a rebased version of the rest of the patch set.
--
Nathan Bossart
Amazon Web Services: https://aws.amazo
On Mon, Jan 16, 2023 at 12:01:47PM +0100, Peter Eisentraut wrote:
> I have updated the patch as you suggested and split out the aggregate issue
> into a separate patch for clarity.
LGTM
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
I removed BuildRestoreCommand() in v8.
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
>From c710f5a9e294b198ce6bb2e8d9404cb26a76b913 Mon Sep 17 00:00:00 2001
From: Nathan Bossart
Date: Fri, 23 Dec 2022 16:53:38 -0800
Subject: [PATCH v8 1/2] Refactor code for restoring files via shell
On Mon, Jan 16, 2023 at 09:06:10PM -0500, Robert Haas wrote:
> On Mon, Jan 16, 2023 at 5:37 PM Nathan Bossart
> wrote:
>> On Mon, Jan 16, 2023 at 02:29:56PM -0500, Robert Haas wrote:
>> > 4. You can reserve a small number of connections for the superuser
>> > with
On Wed, Jan 18, 2023 at 09:05:52AM +0900, Michael Paquier wrote:
> Thanks, done.
Thanks!
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
On Tue, Jan 17, 2023 at 02:59:31PM -0500, Robert Haas wrote:
> On Tue, Jan 17, 2023 at 1:42 PM Nathan Bossart
> wrote:
>> If we create a new batch of reserved connections, only roles with
>> privileges of pg_use_reserved_connections would be able to connect if the
>> numb
On Wed, Jan 18, 2023 at 11:29:20AM +0900, Michael Paquier wrote:
> And 0002 is applied.
Thanks. Here's a rebased version of the last patch.
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
>From c262ed4701fdb417c1af3a6730499cebb9e25030 Mon Sep 17 00:00:00 2001
From: Nat
reserved_connections to 0 since it is new and doesn't have a
pre-existing default value.
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
>From 94ee89548fd1080447b784993a1418480f407b49 Mon Sep 17 00:00:00 2001
From: Nathan Bossart
Date: Tue, 17 Jan 2023 13:58:56 -0
ack-patched to v12.
On that note, I wonder if it's worth changing the "sorry, too many clients
already" message to make it clear that max_connections has been reached.
IME some users are confused by this error, and I think it would be less
confusing if it pointed to the parameter that
e to createrole with admin option;
GRANT ROLE
postgres=# set role createrole;
SET
postgres=> alter role otherrole with replication;
ERROR: must have replication privilege to change replication attribute
This probably shouldn't block your patch, but I think it's worth doing in
v16 since there are other changes in this area. I'm happy to help.
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
On Tue, Jan 17, 2023 at 07:44:52PM +0530, Bharath Rupireddy wrote:
> On Thu, Jan 12, 2023 at 6:21 AM Nathan Bossart
> wrote:
>> With your patch, we might replay one of these "old" files in pg_wal instead
>> of the complete version of the file from the archives,
s/m/20220703172732.wembjsb55xl63vuw%40awork3.anarazel.de
[1]
https://postgr.es/m/CANbhV-EagKLoUH7tLEfg__VcLu37LY78F8gvLMzHrRZyZKm6sw%40mail.gmail.com
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
kjdtdfqmjujt%40alap3.anarazel.de
[1] https://postgr.es/m/20220217065938.x2esfdppzypegn5j%40alap3.anarazel.de
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
On Sun, Apr 02, 2023 at 04:23:05PM -0400, Tom Lane wrote:
> Nathan Bossart writes:
>> On Sun, Apr 02, 2023 at 01:40:05PM -0400, Tom Lane wrote:
>>> * Why does LookupCustodianFunctions think it needs to search the
>>> constant array?
>
>> The order of the ta
On Sun, Apr 02, 2023 at 04:37:38PM -0400, Tom Lane wrote:
> Nathan Bossart writes:
>> It's been a little while since I dug into this, but I do see your point
>> that the wraparound risk could be higher in some cases. For example, if
>> you have a billion temp files
commitfest and marked the target version as v17.
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
I sent this one to the next commitfest and marked it as waiting-on-author
and targeted for v17. I'm aiming to have something that addresses the
latest feedback ready for the July commitfest.
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
e extension.
>>
>> I'd have no issue with that.
>
> Cool.
The six-element array approach won't show the number of dirty and pinned
buffers for each usage count, but I'm not sure that's a deal-breaker.
Barring objections, I'll post an updated patch s
On Wed, Apr 05, 2023 at 03:07:10PM -0400, Tom Lane wrote:
> Seems to me that six rows would be easier to aggregate manually.
> An array column seems less SQL-ish and harder to manipulate.
+1
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
hat quick summing
> up multple rows, just to get a quick overview over the number of dirty rows.
This is what v1-0001 does. We could probably make pg_buffercache_summary a
view on pg_buffercache_usage_counts, too, but that doesn't strike me as
tremendously important.
--
Nathan Bossart
Am
ess-aggregated summary function is clearly useful as well.
> So I'm now thinking that we do want the patch as-submitted.
> (Caveat: I've not read the patch, just the description.)
In case we want to do both, here's a 0002 that changes usagecount_avg to an
array of usage coun
o it seemed to me that sum(buffers) ought to agree with the
> shared_buffers setting.
Makes sense. Thanks!
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
you try to
use an option on and older server, anyway.
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
rebased
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
>From b8856e61d775bc248a292163facc0b227abdde97 Mon Sep 17 00:00:00 2001
From: Nathan Bossart
Date: Thu, 23 Feb 2023 14:27:48 -0800
Subject: [PATCH v15 1/7] Move extra code out of the Pre/PostRestoreCommand()
block.
Here is a new patch set. I've split it into two patches: one for the
64-bit functions, and one for the 32-bit functions. I've also added tests
for pg_lfind64/pg_lfind64_idx and deduplicated the code a bit.
--
Nathan Bossart
Amazon Web Services: https://aws.amazon
; every other known implementation, via TRUST_STRXFRM (or rather the
> lack of it). So I think it's time to remove that function; please see
> attached.
Seems reasonable to me.
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
t entry [0] is still set to
"needs review." Can it be closed now?
[0] https://commitfest.postgresql.org/43/4277/
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
dn't see any easy way to improve that situation though.)
Sorry, I think this was my fault. Thanks for fixing.
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
ly appealing.
AFAICT this would involve adding a bool to BackendParameters and using it
in save_backend_variables() and restore_backend_variables(), which is an
additional 3 lines of code. That doesn't sound too bad to me, but perhaps
I am missing something.
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
On Fri, Apr 14, 2023 at 03:07:37PM -0400, Jonathan S. Katz wrote:
> +1.
+1. I agree with the upthread discussion and support removing
vacuum_defer_cleanup_age.
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
definition of
BGW_MAXLEN. Also, I think there's a good chance that we'd forget to update
such documentation the next time we adjust it.
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
hank you all for the wishes.
Thanks everyone! And congratulations to Masahiko and Amit.
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
On Fri, Apr 21, 2023 at 01:50:34PM +0700, John Naylor wrote:
> On Wed, Mar 8, 2023 at 7:25 AM Nathan Bossart
> wrote:
>> was mostly a fun weekend project, and I don't presently have any concrete
>> examples of workloads where this might help.
>
> It seems like that
On Fri, Apr 21, 2023 at 10:49:48AM +0200, Daniel Gustafsson wrote:
> On 21 Apr 2023, at 01:32, Nathan Bossart wrote:
>> I am -0.5 for this. If you are writing a new background worker, it's
>> probably reasonable to expect that you can locate the definition of
>> BG
seems weird to me.)
Most of these commands have an existing note about the deprecated syntax.
Could those be removed with this change?
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
On Wed, Mar 01, 2023 at 03:13:04PM -0800, Andres Freund wrote:
> On 2023-03-01 14:47:51 -0800, Nathan Bossart wrote:
>> Here is an attempt at adding a signal safe function for writing to STDERR.
>
> Cool.
I'm gently bumping this thread to see if anyone had additional feed
ecated syntax.
>> Could those be removed with this change?
>
> Ah, yes. Good catch! I have removed these.
Thanks. I'll take a closer look at the patch soon.
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
n.wikipedia.org/wiki/Basic_Linear_Algebra_Subprograms
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
>From b54b938bf35f26bc8e07cd57d4bf616b7af36709 Mon Sep 17 00:00:00 2001
From: Nathan Bossart
Date: Sun, 19 Mar 2023 14:37:54 -0700
Subject: [PATCH v1 1/3] Refactor dsqrt().
This
ax was used before v14, but it's still the only way to
do a "verbose" CLUSTER without a table name in v15 and v16, too. Perhaps
we should break it apart, or maybe we can just say it was used before v17.
WDYT?
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
>From 48fff1
$$ = (Node *) n;
>> }
>> -| CLUSTER opt_verbose
>> + | CLUSTER '(' utility_option_list ')'
>
> It is too bad we can't do this the way VACUUM and ANALYZE do -- but
> since qualified_name is required if USING is included, I suppose we
> can't.
It might be possible to extract the name and index part to a separate
optional rule.
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
_builtin(&userSetDatum, 1,
BOOLOID);
}
index++;
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
On Thu, Apr 27, 2023 at 09:47:33PM +0300, David Steele wrote:
> That seems to work. The errors are now gone.
Great. Barring objections, I'll plan on committing this shortly.
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
On Thu, Apr 27, 2023 at 09:53:23PM +0300, Alexander Korotkov wrote:
> Thanks to everybody for catching and investigating this.
> Nathan, I'd like to push it myself. I'm also going to check the code
> for similar errors.
Sounds good!
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
would be nice to avoid adding a
new option if possible. It's not clear to me why we'd need to also check
privileges at login time as opposed to only checking them at ALTER ROLE SET
time. ISTM that the former approach would introduce some interesting
problems around dropping roles o
his, but I
haven't thought of a better option. We could error instead of returning
NULL, but IIUC that would go against d0aa965's stated purpose.
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
>From 12daf35ca398a34046d911270283f2cb7ebcbf3f Mon Sep 17 00:00:00 2001
From: Na
On Wed, May 03, 2023 at 04:33:32PM -0400, Tom Lane wrote:
> Nathan Bossart writes:
>> Here's a new version of the patch. Besides adding comments and a commit
>> message, I made sure to decrement the reference count for pltargs in the
>> PG_CATCH block (which means that
On Wed, May 03, 2023 at 01:58:38PM -0700, Nathan Bossart wrote:
> With this change, pltdata isn't modified in the PG_TRY section, and the
> only modification of pltargs happens after all elogs. It might be worth
> keeping pltargs volatile in case someone decides to add an elog() i
On Wed, May 03, 2023 at 09:54:13PM -0700, Nathan Bossart wrote:
> Here's a new patch that removes the volatile marker from pltdata.
Gah, right after I sent that, I realized we can remove one more volatile
marker. Sorry for the noise.
--
Nathan Bossart
Amazon Web Service
501 - 600 of 2983 matches
Mail list logo
