gnal_backend".
I wouldn't call it "minimally privileged" (which feels wrong because it
wouldn't even have privileges on PUBLIC, as you say); I'd just say that
it's a type of role where those things just don't make sense.
--
Jeff Davis
PostgreSQL Contributor Team - AWS
think we need to special-case predefined roles though. I
think a lot of administrators would like to declare some roles that are
just a collection of inheritable privileges.
--
Jeff Davis
PostgreSQL Contributor Team - AWS
ainly a terminology problem there. Just to brainstorm on
some new names, we might want to call it something like "xid
reclamation" or "xid horizon advancement".
When it starts to run out, we can use words like "wraparound" or
"exhaustion".
--
Jeff Davis
PostgreSQL Contributor Team - AWS
it's
done. Let's be clear that it was merely the triggering criteria and
doesn't necessarily represent the work that is being done.
There are enough cases that it would be good to start a document and
outline the end behavior that your patch series is designed to
accomplish. In other
that are collation-dependenent, or perhaps just go through the
input and output functions and catch any errors.
* Consider better tracking of which collation versions were active on
a particular object since the last REINDEX (or REFRESH MATERIALIZED
VIEW, TRUNCATE, or othe
see what I come up
with.
Of course, the view will just show an "affected by" relationship, it
won't show which objects are actually in violation of the current
collation version. But it at least gives the administrator a starting
place.
Regards,
Jeff Davis
set it anywhere.
There were patches[1] from around the time of the commit to support
CREATE_REPLICATION_SLOT as well.
Is there a reason to support two-phase decoding, but not with the
replication protocol? If so, why change the CreateReplicationSlotCmd
structure as though we will support it?
Regard
CREATE_REPLICATION_SLOT changes and updating
pg_recvlogical, so that it can go in v14 (and
pg_create_logical_replication_slot() will match
CREATE_REPLICATION_SLOT). But if that's complicated or controversial,
then I'm fine waiting for the other work to complete.
Regards,
Jeff Davis
On Tue, 2020-10-27 at 23:39 -0700, Andres Freund wrote:
> Maybe we should just have --with-ssl={openssl,nss}? That'd avoid
> needing
> to check for errors.
[ apologies for the late reply ]
Would it be more proper to call it --with-tls={openssl,nss} ?
Regards,
Jeff Davis
path as well.
channel_binding=require is one way to do it, but it also requires ssl.
Regards,
Jeff Davis
t TRUNCATE), or issue a
warning/log/notice.
The biggest challenge would be: when should we detect that the reset
has happened? There might be a lot of entry points. Another idea would
be to just have a SQL function that the application could call whenever
it needs to know.
Thoughts?
Jeff Davis
sible option
> names etc, with support for legacy names.
Sounds good to me, though I haven't looked into how big of a diff that
will be.
Also, do we have precedent for GUC aliases? That might be a little
weird.
Regards,
Jeff Davis
On Thu, 2021-05-06 at 17:24 -0700, Jeff Davis wrote:
> It's the table AM's responsibility to detoast out-of-line datums and
> toast any values that are too large (see
> heapam.c:heap_prepare_insert()).
Do we have general agreement on this point? Did I miss another purpo
accept new reloptions
for a custom AM, we also need to accept options for toast tables of
that AM.
* Implementation-wise, the bytea representation of the options is not
very easy to extend. Should we have a new text field in the catalog to
hold the custom options?
Regards,
Jeff Davis
so, here
+* we have not check are keys ok or not.
+*/
and that language has just been carried forward for decades. I wonder
if there's any major reason this hasn't been done yet. Does it just not
improve performance for a heap, or is there some other reas
lude the change we removed as part of (a).
Yes, sounds good.
Regards,
Jeff Davis
On Fri, 2021-06-04 at 08:23 +0200, Mats Kindahl wrote:
> That is basically the question. I'm prepared to take a shot at it
> unless there is a good reason not to.
Sounds good, I can review.
Regards,
Jeff Davis
he case where this tuple has been already detoasted.
Yes. That's a current requirement, and any AM that doesn't do that is
already broken (e.g. for INSERT INTO ... SELECT).
Regards,
Jeff Davis
ink it will be a few
releases (and require a few more table AMs in the wild) to really nail
down the API.
Regards,
Jeff Davis
tartup checkpoint
after the most recent crash.
A SQL function could read the value. Perhaps we'd also have a SQL
function to reset it, but I don't see a use case for it.
Then, it's up to the client to check it against a stored value, and
clear/repopulate unlogged tables as necessary.
Regards,
Jeff Davis
o an
unlogged table with some empty shards and some populated ones). Should
also store the last promotion LSN and time as well? Does "promotion
count" make sense, and should we track that, too?
3. Should we try to track crash information across promotions, or just
start them at the initial
s good, and it works as I expect it to.
Regards,
Jeff Davis
ndle unlogged tables at the time. But
it's inconvenient to insert more tasks into a sensitive process like
failover/recovery. It's preferable to be able to detect the unlogged
table problem after the fact and handle it when the systems are all up
and stable.
Regards,
Jeff Davis
On Thu, 2021-06-03 at 14:36 -0700, Jeff Davis wrote:
> Do we have general agreement on this point? Did I miss another
> purpose
> of detoasting in tablecmds.c, or can we just remove that part of the
> patch?
Per discussion with Justin, I'll drive this patch. I merged the CF
e
_PASS_MISC;
> Maybe add a comment here?
Done. In that case, it doesn't matter because there's no work to be
done in Phase 2.
Regards,
Jeff Davis
From 051d067e07eaec29d221641da3bf28d0dd0731c8 Mon Sep 17 00:00:00 2001
From: Jeff Davis
Date: Wed, 5 May 2021 14:28:59 -0700
S
on with the wrong kind of slot would be a parse
error?
Regards,
Jeff Davis
the SQL function create_logical_replication_slot(), but it's
impossible over the replication protocol. That seems inconsistent to
me.
Regards,
Jeff Davis
CopyDone, or CopyFail messages
issued by the frontend will simply be dropped."
If the client does send a Sync, it results in an extra ReadyForQuery
message.
Diagnosed and reported by Petros Angelatos (petrosagg on Github).
Regards,
Jeff Davis
e I understand the comment overall. Why would the client
request something that it has already acknowledged, and why would the
server override that and just advance to the confirmed_lsn?
Regards,
Jeff Davis
wanted to look into doing it
as an extension using the CustomScan mechanism.
Do you have any solution to working better with multiple join keys? And
do you have thoughts on whether it would be a good candidate for the
CustomScan extension mechanism, which would make it easier to
experiment with?
Regards,
Jeff Davis
er might expect an error in that
case; but doesn't really address why the user would expect an error,
and why it's OK to violate that expectation.
Regards,
Jeff Davis
or and configuration, and whether that's a safe choice
or not.
The only difference is whether the server is safe-by-default with
intuitive semantics that match the documentation, or unsafe-by-default
with unexpected semantics that don't match the documentation.
Regards,
Jeff Davis
On Fri, 2021-06-11 at 10:40 -0700, Andres Freund wrote:
> Especially because it very well might break existing working
> setups...
Please address my concerns[1].
Regards,
Jeff Davis
[1]
https://www.postgresql.org/message-id/e22a4606333ce1032e29fe2fb1aa9036e6f0ca98.camel%40j-davis.com
iscussion.
Regards,
Jeff Davis
t result in a better
change, then we should probably just get it into the July CF for v15.
(My apologies if my opinion has drifted a bit since this thread began.)
Regards,
Jeff Davis
ld we just document how CopyBoth works with the simple query
protocol, or should we make it match the CopyIn docs?
Regards,
Jeff Davis
ors.
Clients should be careful to check confirmed_flush_lsn if starting at
the requested LSN is required."
3. upgrade DEBUG1 message to a WARNING
Can I get agreement on any of the above suggestions?
Regards,
Jeff Davis
ing strange happens, might
rule out some possibilities.
Regards,
Jeff Davis
Possibly
> the CopyOut docs should be made more similar as well.
I attached a doc patch that hopefully clarifies this point as well as
the weirdness around CopyIn/CopyBoth and the extended protocol. I
reorganized the sections, as well.
Regards,
Jeff Davis
diff --git a/doc/src/sgml/pr
am from %X/%X, minimum is
> %X/%X, forwarding",
> + elog(LOG, "%X/%X has been already streamed,
> forwarding to %X/%X",
>
> FWIW, I most prefer #1. I see #2 as optional. and see #3 as the
> above.
Attached.
Regards,
Jeff Davis
diff --git a/doc/src
ender it's trivial to compute.
[ digging up old thread ]
It seems everyone agrees that the current behavior is strange. Any
ideas on a solution here?
> Has anybody dug out the thread leading to the commit?
https://www.postgresql.org/message-id/CAMsr%2BYEN04ztb%2BSDb_UfD72Kg5M3F%2BCpad31QBKT2rRjysmxRg%40mail.gmail.com
Regards,
Jeff Davis
yIn/CopyBoth command without a Sync, but I'm not sure there are any
clients that do that, and it's arguable whether the documentation
permitted that or not anyway.
I hacked together a quick patch; attached.
Regards,
Jeff Davis
diff --git a/src/backend/commands/copyfromparse.
ID; and
also why there was a difference between IdentifySystem() and
StartReplication().
Simple patch attached. I didn't test it yet, but wanted to post my
analysis.
Regards,
Jeff Davis
diff --git a/src/backend/replication/walsender.c b/src/backend/replication/walsender.c
index 3224
or so that specifying the current
timeline as a number still means a historic timeline (e.g. it will stop
replicating there and emit a tuple)?
* Should we add some keywords like "latest" or "current" to the
START_REPLICATION command?
Regards,
Jeff Davis
On Fri, 2021-06-18 at 21:48 +0300, Heikki Linnakangas wrote:
> On 18/06/2021 20:27, Jeff Davis wrote:
> We could teach it to look into the timeline history to find the
> correct
> file, though.
That's how recovery_target_timeline behaves, and it would match my
in
the standby; but in that case the admin must be
sure not to fail over until there's a new standby fully caught-up.
The patch may be somewhat controversial, so I'll wait for feedback
before documenting it properly.
Regards,
Jeff Davis
diff --git a/src/backend/replication/syncre
On Tue, 2021-06-29 at 11:48 +0500, Andrey Borodin wrote:
> > 29 июня 2021 г., в 03:56, Jeff Davis
> > написал(а):
> >
> > The patch may be somewhat controversial, so I'll wait for feedback
> > before documenting it properly.
>
> The patch seems similar
he client knows the Sync was eaten and it
> has to send another one.
That's what I had in mind.
Regards,
Jeff Davis
> There is one more caveat we need to fix: we should prevent instant
> recovery from happening.
That can already be done with the restart_after_crash GUC.
Regards,
Jeff Davis
an admin command. Even for an admin, it might be hard to
understand why terminating a backend could result in losing a visible
transaction.
I'm not really seeing two use cases here for two GUCs. Are you sure you
want to disable only cancels but allow termination to proceed?
Regards,
Jeff Davis
dly wrong (low
memory, etc.) anyway. I don't see a better solution here.
I don't fully understand why you'd be concerned about cancellation but
not concerned about similar problems with termination, but if you think
two GUCs are important I can do that.
Regards,
Jeff Davis
l we've already
called CreateTupleDescCopy(). Otherwise, an allocation failure could
leave NextRecordTypmod unnecessarily incremented, which is a tiny leak.
Regards,
Jeff Davis
r modifications.
Regards,
Jeff Davis
t; [PATCH: rmgr_003.v1.patch]
I also like this idea, but can you describe the intended use case? I
looked through CheckPointGuts() and I'm not sure what else a custom AM
might want to do. Maybe sync special files in a way that's not handled
with RegisterSyncRequest()?
Regards,
Jeff Davis
On Thu, 2022-05-12 at 22:26 +0100, Simon Riggs wrote:
> I see multiple uses for the rm_checkpoint() point proposed and I've
> been asked multiple times for a checkpoint hook.
Can you elaborate and/or link to a discussion?
Regards,
Jeff Davis
bably pushes it to v16 given that it's so late in the cycle.
Regards,
Jeff Davis
C snapshot to get the old version of the
tuple,
* and can use SnapshotSelf to get the new version of the tuple.
Regards,
Jeff Davis
PS: I added this to the July CF:
https://commitfest.postgresql.org/38/3676/
sions to follow that rule?
Regards,
Jeff Davis
s that will be hard to keep.
Regards,
Jeff Davis
nterested in this discussion.]
Regards,
Jeff Davis
Patch attached. Some kinds of emit log hooks might find it useful to
also compute the log_line_prefix.
Regards,
Jeff Davis
From c3d4f14602c043918b8b6dab88a976dac1923208 Mon Sep 17 00:00:00 2001
From: Jeff Davis
Date: Tue, 28 Jun 2022 11:39:33 -0700
Subject: [PATCH] Export
Patch attached.
Helpful for debugging complex extension script problems.
From b278eba9ba35ec1c52a8c1aa5c080a6731f86fbe Mon Sep 17 00:00:00 2001
From: Jeff Davis
Date: Tue, 28 Jun 2022 12:06:03 -0700
Subject: [PATCH] Emit debug message when executing extension script.
Outputting script filenames
s.
Regards,
Jeff Davis
On Wed, 2022-06-29 at 10:17 +0900, Michael Paquier wrote:
> On Tue, Jun 28, 2022 at 11:52:56AM -0700, Jeff Davis wrote:
> > Patch attached. Some kinds of emit log hooks might find it useful
> > to
> > also compute the log_line_prefix.
>
> Have you played with anything
it would be difficult
to reuse extension code between those two hooks. It's probably better
to just always specify the snapshot unless you're sure you won't need a
post-alter hook.
It would be nice if it was easier to enforce that these hooks do the
right thing, though.
Regards,
Jeff Davis
rom/to version.
The output looks nicer and I don't have to worry about whether the user
should be able to know the share directory or not.
Regards,
Jeff Davis
From 3024b3189156402e0d4250e43dcccec5aa5d01a3 Mon Sep 17 00:00:00 2001
From: Jeff Davis
Date: Tue, 28 Jun 2022 12:06:03 -
On Fri, 2022-07-01 at 15:33 -0700, Nathan Bossart wrote:
> On Fri, Jul 01, 2022 at 03:24:27PM -0700, Jeff Davis wrote:
> > + ereport(DEBUG1, errmsg("executing extension update
> > script from version '%s' to '%s'", from_version, versio
gt; > to pass the format string as a parameter to the function instead of
> > relying on the GUC global.
That is nicer, attached.
I also renamed the function log_status_format(), and made
log_line_prefix() a thin wrapper over that. I think that's less
confusi
is AM, so caller can trigger option
> processing
> himself.
What about table access methods? There have been a couple attempts to
allow custom reloptions for table AMs. Does this patch help that use
case?
Regards,
Jeff Davis
f more use
cases come forward.
Regards,
Jeff Davis
ement_timeout or a termination due
to a network disconnect.
Separately, I'm taking a vacation. Since there are two versions of the
patch floating around, I will withdraw mine.
Regards,
Jeff Davis
o that other areas of the system might benefit
as well?
2. Should this marking be superuser-only, or user-specified?
3. Should it be related to the IMMUTABLE/STABLE/VOLATILE designation,
or completely separate?
Regards,
Jeff Davis
whether one
is a no-op, and it should probably throw a syntax error to match SET
TABLESPACE.
Minor nit: in tab-complete.c, why does it say ""? Is that just a
typo or is there a reason it's different from everything else, which
uses ""? And what does "sth" mean anyway?
Regards,
Jeff Davis
e,
> > which
> > uses ""? And what does "sth" mean anyway?
>
> "Something". That should be "" to be consistent with the area.
These two issues are pretty minor.
Regards,
Jeff Davis
gt; > > > multiple
> > > > SET ACCESS METHOD subcommands consistently, regardless of
> > > > whether
> > > > one
> > > > is a no-op, and it should probably throw a syntax error to
> > > > match
> > > > SET
> > > > TABLESPACE.
> > >
> > > Hmm. Okay.
>
> I'd still disagree with that.
OK, I won't press for a change here.
Regards,
Jeff Davis
s like anything we do here should be part of a larger change to
make it consistent. So I'm fine with the patch you posted.
Regards,
Jeff Davis
not so bad, and it's not clear how we could do any better. So I
> withdraw my previous complaint about this point.
Further thoughts on this? I don't feel comfortable making this change
without a stronger endorsement.
Regards,
Jeff Davis
extension functions
called from outside the extension script, also. It would be nice if we
could implicitly tack on a "SET search_path TO @extschema@, pg_catalog,
pg_temp" to each function in the extension. I'm not proposing that, but
perhaps a related idea might work. Probably outside the scope of your
proposal.
Regards,
Jeff Davis
ich can cause
an incorrect value to be returned. That can matter in some contexts
like a CHECK constraint.
Regards,
Jeff Davis
I'll see if removing the extra branches
mitigates it.
--
Jeff Davis
PostgreSQL Contributor Team - AWS
From 9f50c24878740acdd3f1bc036442a0fcc0ea1a5e Mon Sep 17 00:00:00 2001
From: Jeff Davis
Date: Wed, 5 Jun 2024 11:45:55 -0700
Subject: [PATCH v1 1/5] Make database default collation
ensions how will this have
> an impact if we set the search_path for definer functions.
If we only set the search path for SECURITY DEFINER functions, I don't
think that solves the whole problem.
Regards,
Jeff Davis
On Wed, 2024-06-05 at 17:23 -0700, Jeff Davis wrote:
> A brief test shows that there may be a performance regression for
> libc
> default collations. But if so, I'm not sure that's avoidable if the
> goal is to take away setlocale. I'll see if removing the extra
> bra
he search_path from the session".
Regards,
Jeff Davis
resql.org/48/5023/
Regards,
Jeff Davis
inition of absolute time and exposing a new function to retrieve
it.
Regards,
Jeff Davis
kinds of operations/transformations are supported?
3. I can't recall another API that uses absolute time for a timeout;
are you aware of a precedent?
Regards,
Jeff Davis
;t object to your
solutions for f5e4dedfa8.
Regards,
Jeff Davis
On Tue, 2024-06-11 at 14:56 +0200, Alexander Kukushkin wrote:
> Now attackers can just set search_path for the current session.
IIUC, the proposal is that only the function's "SET" clause can
override the behavior, not a top-level SET command.
Regards,
Jeff Davis
ed.
That sounds like a useful and non-controversial change.
Regards,
Jeff Davis
e
search_path setting per session.
Regards,
Jeff Davis
> what if the extension is installed into a schema that's writable by
> others, like public?
Jelte proposed something to fix that here:
https://www.postgresql.org/message-id/CAGECzQQzDqDzakBkR71ZkQ1N1ffTjAaruRSqppQAKu3WF%2B6rNQ%40mail.gmail.com
Regards,
Jeff Davis
On Thu, 2024-06-06 at 11:37 -0700, Jeff Davis wrote:
>
> I think this patch series is a nice cleanup, as well, making libc
> more
> like the other providers and not dependent on global state.
New rebased series attached with additional cleanup. Now that
pg_locale_t is never NULL, we
f we can close the performance
gap enough that it's not important?
(Note: the special case in lc_ctpye_is_c() is currently required for
correctness because hba.c uses C_COLLATION_OID for regexes before the
syscache is initialized. That can be fixed pretty easily a couple
different w
by superusers.
I'm not sure that it's specific to SECURITY DEFINER functions.
Regards,
Jeff Davis
g the libc provider, get_collation_actual_version() completely
ignores the ctype.
It would be interesting to consider tracking the versions separately,
though.
Regards,
Jeff Davis
we need to settle, along with
a lot of work. So I don't think we should pre-emptively block all
Unicode updates waiting for it.
> An alternative would be to make pg_upgrade reject
> operating on a cluster that contains use of $SUBJECT.
That wouldn't help anyone.
Regards,
Jeff Davis
n and
let's not lose sight of that.
Given that no code changes for v17 are proposed, I suggest that we
refrain from making any declarations until the next version of Unicode
is released. If the pattern holds, that will be around September, which
still leaves time to make reasonable decisions
on than to pin libc to a specific version.
> When doing that, are there any function that may have an immutability
> breakage problem with the built-in locale provider? (I would expect
> none).
Right, there wouldn't be any breakage without new data files.
Regards,
Jeff Davis
e and CC
me. I happen to think that around the release of the next version of
Unicode (in a couple months) would be the most productive time to have
that discussion, but you can start the discussion now if you like.
Regards,
Jeff Davis
ns a bit of cleanup and is intended for 17+18.
Regards,
Jeff Davis
From 1b24d08302e268370ebb14e732f4d5f1f1407726 Mon Sep 17 00:00:00 2001
From: Jeff Davis
Date: Mon, 8 Jul 2024 15:52:50 -0700
Subject: [PATCH v1] Fix missing invalidations for search_path cache.
Reported-by: Noah Misch
Discu
801 - 900 of 1501 matches
Mail list logo
