uthentication time with only the connection information and a
password. It could be useful to authenticate against different
services, or some kind of attack detection, etc.
Regards,
Jeff Davis
> plaintext
> exchange. Radius, Ldap, Pam afaics could be implemented as an
> extension?
Yes, and it means that we won't have to extend that list in core in the
future when new methods become popular.
Regards,
Jeff Davis
a good idea.
I don't understand your point. Can't you just use "hostssl" rather than
"host"?
Also there are some useful cases that don't really require SSL, like
when the client and host are on the same machine, or if you have a
network secured some other way.
Regards,
Jeff Davis
or hostgssenc.
It might annoy people who have a network secured at some other layer,
or who have the client on the same machine as the host. We could allow
plain "host" if someone specifies "customplain" explicitly.
Regards,
Jeff Davis
fuse to send a password in
plaintext?
> I also have in mind here that there has been discussion of giving
> libpq a feature to refuse, on the client side, to send cleartext
> passwords.
I am generally in favor of that idea, but I'm not sure that will
completely resolve the issue. For instance, should it also refuse MD5?
Regards,
Jeff Davis
to a contrib module
that implements it as a custom auth method.
Regards,
Jeff Davis
I'm not 100% clear on the
standards for that marker, but it seems reasonable for a database owner
with the right privileges might want to install it.
* pg_get_raw_wal_record() seems too powerful for pg_monitor. Maybe that
function should require pg_read_server_files? Or at least
pg_read_all_data?
Regards,
Jeff Davis
towards $owners in general and should be thinking about how we
> can allow admins, providers, whomever, the ability to control what
> rights users are given. If they're all lumped under 'owner' then
> there's no way for people to provide granular access to just those
> things they wish and intend to.
Not sure I understand, but that sounds like a larger discussion.
Regards,
Jeff Davis
and the point, but it also has a flip side: if custom auth
works, why do we need to block waiting for a complete core OAUTH
feature?
Authentication seems like a good candidate for allowing custom methods.
New ones are always coming along, being used in new ways, updating to
newer crypto, or falling out of favor. We've accumulated quite a few.
Regards,
Jeff Davis
to require
provider to be first, but needs to be documented/commented somewhere).
* If you are intending for your custom provider to be open source, it
would be helpful to show the code (list, github link, whatever), even
if rough. That would ensure that it's really solving at least on
en
set the format code to 1 (indicating binary)?
For clients that do look at the descriptor, they are more likely to get
it right; and for clients that don't look at the descriptor, there will
be no change.
Regards,
Jeff Davis
her approach; but in any case, I don't see the point
in sending an incorrect RowDescription.
Regards,
Jeff Davis
[1] https://postgr.es/m/20201008235250.ga1...@paquier.xyz
diff --git a/doc/src/sgml/protocol.sgml b/doc/src/sgml/protocol.sgml
index 4899bacda7b..f383223f462 100
ch a way as to let non-ASCII data in there.
This is probably the best approach, and it builds on your previous
patch (which already got consensus) rather than replacing it.
Regards,
Jeff Davis
> likely be broken anyway, without any way to test it.
I tried to add streaming replication support (still a work in progress)
to the rust client[1], and I ran into this problem.
The core of the rust client is fully pipelined and async, so it's a bit
annoying to work around this problem.
r than documenting the possibility of non-ASCII text.
Regards,
Jeff Davis
[1]
https://www.postgresql.org/message-id/3679218.1602770626%40sss.pgh.pa.us
From b9381a62ab9616da3062827f84b72844748fd3fc Mon Sep 17 00:00:00 2001
From: Jeff Davis
Date: Tue, 15 Dec 2020 01:06:21 -0800
Subject: [P
the simplest thing I could think
of that would allow an extension to have its own options, even if it's
a bit hacky. I'm open to alternatives.
Regards,
Jeff Davis
On Tue, 2020-12-15 at 12:54 -0800, Andres Freund wrote:
> Hi,
>
> On 2020-12-15 01:22:44 -0800, Jeff Davis wrote:
> > Attached a simple patch that enforces an all-ASCII restore point
> > name
> > rather than documenting the possibility of non-ASCII text.
>
> +1
D. Is acquire_sample_rows() doing
something it shouldn't, or is the comment mistaken?
Regards,
Jeff Davis
rting extensible reloptions, there will be no hacks in the wild to
learn from.
Regards,
Jeff Davis
uests in this
manner.
Also, I'm curious if we know about other areas where the protocol
doesn't mix nicely with pipelining.
In a related note, I think the documentation text above is also
incorrect, because streaming from an old timeline will send a tuple
back before CommandComplete.
R
er. If the premise is
that a given custom AM may be much more efficient at bulk inserts than
retail inserts (which is reasonable), then it makes sense to handle the
case of a transaction with many single-tuple inserts. But keeping
insert state across statement boundaries also raises a few potential
problems.
Regards,
Jeff Davis
On Tue, 2021-01-05 at 09:17 -0800, Jeff Davis wrote:
> The reason I ask is because it makes clients that do pipelining more
> complex. If the server always enters copy mode, then the client can
> send a CopyDone and then pipeline more requests behind it. But if the
> server may or m
the worst kinds of surprises.
Regards,
Jeff Davis
run before
START_REPLICATION, and always issue a WARNING if that's not done (an
ERROR might break existing applications); or
2. If the commit is out of date and no longer needed, or if it's easy
enough to fix, just remove the error (and Assert a valid
ThisTimeLineID).
Regards,
Jeff Davis
On Fri, 2021-01-15 at 13:55 -0800, Andres Freund wrote:
> 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
.
How should the API interact with INSERT INTO ... SELECT? Right now it
doesn't appear to be integrated at all, but that seems like a fairly
important path for bulk inserts.
Regards,
Jeff Davis
tegrated in to the patch.
I think the patch should support INSERT INTO ... SELECT, and it will be
easier to tell if we have the right API when that's integrated.
Regards,
Jeff Davis
On Mon, 2021-12-13 at 11:20 -0800, Mark Dilger wrote:
> - The logical replication subscription patch needs to consider RLS.
> (Jeff Davis)
>
> This is implemented but I still need to update the documentation
> before
> posting.
We also discussed how much of the i
ready has a
path to consider relcache invalidation, so it would also be a good
place to check if the table has RLS enabled.
Regards,
Jeff Davis
opyData
[ server ignores CopyData ]
-> CopyDone
[ server ignores CopyDone ]
-> Sync
[ server processes Sync ]
<- ReadyForQuery
The last case is not great, because I could imagine it confusing a
client, but I'm not sure about exactly how, and maybe it's something we
can document around?
Regards,
Jeff Davis
orum should always be ahead of the async
replicas. Unless I'm missing a use case, or there is some kind of
performance gotcha.
Regards,
Jeff Davis
t transactions.
With the proposed change: an LSN can be replicated to all sync replicas
as soon as it's durable on the primary; and an LSN can be replicated to
all async replicas as soon as it's durable on the primary *and* the
sync rep quorum is satisfied.
Regards,
Jeff Davis
sync rep] extends that standard level of durability offered by a
transaction commit... [sync rep] can provide a much higher level of
durability..."
If we take that at face value, then it seems logical to say that async
read replicas should not get ahead of sync replicas.
Regards,
Jeff Davis
er
rack. Sync replicas are geographically distributed with quorum commit.
Read replica gets the WAL first (because it's closest), starts
answering queries that include that WAL, and then the entire rack
catches fire. Now you've returned results to the client, but lost the
transactions.
Regards,
Jeff Davis
Do you have a different opinion?
Regards,
Jeff Davis
On Wed, 2021-12-15 at 12:23 -0800, Mark Dilger wrote:
> > On Nov 24, 2021, at 4:30 PM, Jeff Davis wrote:
> >
> > We need to do permission checking for WITH CHECK OPTION and RLS.
> > The
> > patch right now allows the subscription to write data that an RLS
> &g
On Sat, 2022-01-08 at 15:35 +0530, Amit Kapila wrote:
> On Sat, Jan 8, 2022 at 1:01 PM Jeff Davis wrote:
> >
> > On Sat, 2022-01-08 at 12:27 +0530, Amit Kapila wrote:
> > > For Update/Delete, we do read the table first via
> > > FindReplTupleInLocalRel(), so is
t's in line with the
other tests.
Regards,
Jeff Davis
On Mon, 2021-11-08 at 15:36 -0800, Jeff Davis wrote:
> The attached patch (against v14, so it's easier to test columnar) is
> somewhat like a simplified version of [3] combined with refactoring
> to
> make decoding a part of the rmgr.
New patches attached (v3). Essentially the c
thers who felt this approach
is wasteful, which it is. But if this patch still has potential, I'm
happy to pursue it along with the extensible rmgr approach.
> So I'm signing up as a reviewer and we'll see if this is good to go.
Great, I attached a rebased version.
Regards,
On Fri, 2020-07-24 at 21:16 +0200, Tomas Vondra wrote:
> Surely more recursive spilling should do more I/O, but the Disk Usage
> reported by explain analyze does not show anything like ...
I suspect that's because of disk reuse in logtape.c.
Regards,
Jeff Davis
or the
number of groups (and therefore the number of partitions) that we need
when we recurse, which would reduce the number of overall batches at
higher work_mem settings. But I didn't get a chance to implement that
yet.
Regards,
Jeff Davis
can deal with a lot of slop -- e.g. HashJoin vs
MergeJoin -- because a small factor often doesn't make the difference
between plans. But HashAgg and Sort are more competitive with each
other, so costing needs to be more precise.
Regards,
Jeff Davis
which I believe is the cause of this discontinuity.
It's not clear to me that overpartitioning is a real problem in this
case -- but I think the fact that it's causing confusion is enough
reason to see if we can fix it.
Regards,
Jeff Davis
to
overpartition, or if the cost of doing the HLL itself is significant.
Regards,
Jeff Davis
From 424f611f442e36a91747fd39cd28acba42eb958b Mon Sep 17 00:00:00 2001
From: Jeff Davis
Date: Sat, 25 Jul 2020 14:29:59 -0700
Subject: [PATCH] HLL
---
src/backend/executor/nodeAgg.c | 64 ++
~10.64 seconds.
I saw less of an improvement than you or Andres (perhaps just more
noise). But given that both you and Andres are reporting a measurable
improvement, then I went ahead and committed it. Thank you.
Regards,
Jeff Davis
g the costing, if necessary.
Regards,
Jeff Davis
ances with
overpartitioning[1]. I think it's overall an improvement, but
addHyperLogLog() itself seemed to show up as a cost, so it can hurt
spilled-but-still-in-memory cases. I'd also like to backpatch this to
13 (as I already did for 9878b643), if that's acceptable.
Regards,
there's an objection
because that would affect other users of HLL.
Regards,
Jeff Davis
[1]
https://www.postgresql.org/message-id/17068336d300fab76dd6131cbe1996df450dde38.ca...@j-davis.com
ctice.
Yes, the difference (at least in a tight loop, on my machine) is not
subtle. I went ahead and committed and backpatched.
Regards,
Jeff Davis
before I committed the patch (and therefore not on
the same exact SHA1s) were 6812, 7158, and 6898. So my most recent
batch of results is slightly worse, but the most recent commit
(fd734f38) still does show an improvement of a couple percent.
Regards,
Jeff Davis
text10m;
HashAgg: 10.5s
Sort+Distinct: 46s
I'm inclined toward option #1 for simplicity unless you feel strongly
about option #2. Specifically, I was thinking of a 1.5X penalty for
HashAgg disk costs.
Regards,
Jeff Davis
oaches, but they all seemed like over-
engineering, so the attached patch just passes validate=false to
fillRelOptions() for heaps. That allows custom table access methods to
just define new options of kind RELOPT_KIND_HEAP.
Regards,
Jeff Davis
diff --git a/src/backend/access/common/relopt
had originally tried to limit the cost model changes to the new plans
I am introducing -- that is, HashAgg plans expected to require disk.
That's why I came up with a rather arbitrary penalty.
Regards,
Jeff Davis
e extra code for TOAST tables,
because they can also be a custom table access method. The benefit over
my current patch is that extensions wouldn't be creating new options
for RELOPT_KIND_HEAP, they would create them only for their own custom
relopt kind, so if you try to use those options with a heap, you would
get an error.
Suggestions welcome.
Regards,
Jeff Davis
I was reacting mostly to changing the cost of Sort. Do you think
changes to Sort are required or did I misunderstand?
Regards,
Jeff Davis
g is still unfairly favored over Sort, at least
for these cases.
Regards,
Jeff Davis
create table t10m(i int);
insert into t10m select (random()*10)::int from
generate_series(1,1000);
explain analyze select distinct i from t10m;
create table t100m(i int);
insert into t100m sel
On Wed, 2020-09-02 at 17:35 -0700, Peter Geoghegan wrote:
> On Wed, Sep 2, 2020 at 5:18 PM Jeff Davis wrote:
> > create table text10m(t text collate "C.UTF-8", i int, n numeric);
> > insert into text10m select s.g::text, s.g, s.g::numeric from
> > (select
> >
STABLE, with and without the
CP_SMALL_TLIST change, and I saw only a tiny difference. Do you have a
current case that shows a larger difference?
The only thing I can think of that might change is the size of the null
bitmap or how fields are aligned.
Regards,
Jeff Davis
ion at
spill time. But I don't know if that's worth the extra complexity.
Regards,
Jeff Davis
ment that this would make
> measurable difference ...
I meant "projection of all input tuples" (i.e. CP_SMALL_TLIST) has a
cost. If we project only at spill time, it should be fine.
Regards,
Jeff Davis
t; of
> this cost/duration metric), although for higher work_mem values
> there's
> still a clear gap where the hashing seems to be under-costed by a
> factor
> of ~2 or more.
There seems to be a cliff right after 4MB. Perhaps lookup costs on a
larger hash table?
Regards,
Jeff Davis
attached to disable preallocation for Sort.
I'm still looking into the other concerns.
Regards,
Jeff Davis
diff --git a/src/backend/executor/nodeAgg.c b/src/backend/executor/nodeAgg.c
index 9776263ae75..f74d4841f17 100644
--- a/src/backend/executor/nodeAgg.c
+++ b/src/backend/e
fit for
instrumentation purposes. So I'd be inclined to return (nBlocksWritten
- nHoleBlocks).
The only thing I can think of that would be better is if BufFile
tracked for itself the logical vs. physical size, which might be a good
improvement to make (and would mean that logtape.c wouldn't be
responsible for tracking the holes itself).
Thoughts?
Regards,
Jeff Davis
w kind of like a SECURITY DEFINER function so that the
superuser would only need to issue a GRANT statement on the view?
Regards,
Jeff Davis
the owner of
the view. Maybe we need a concept where the function is executed as
neither the invoker or the definer, but as the owner of the view (or
something else), which sounds appealing, but sounds more like a new
feature.
Regards,
Jeff Davis
are of course security implications with any change like that,
but it seems like a fairly minor one unless I'm missing something. Why
would an admin give someone the privileges to read a view if it will
always fail due to lack of execute privilege?
Regards,
Jeff Davis
appealing: that we have to document a lot
of currently-undocumented internal functions like
pg_get_backend_memory_contexts(), pg_lock_status(), etc., so that users
can grant fine-grained permissions.
Regards,
Jeff Davis
ice if there was some kind of improvement here, but I
won't push too hard for it if there are security concerns.
Regards,
Jeff Davis
ood to be explicit that they are bypassing something
configured by their pseudo-admin.
Regards,
Jeff Davis
I suppose it would default to BYPASS_EVENT_TRIGGERS for superusers and
not for non-superusers. A little awkward to have different defaults,
but it seems sensible in this case.
Would this bypass all event triggers, or only the event triggers of
another user?
Regards,
Jeff Davis
ases. There might be some options here, like allowing
any user to create an event trigger that only affects that user.
Regards,
Jeff Davis
(Aside: I'm not really sure where the line is between adding a
predefined role and adding a user option. Are user options just the old
way, and predefined roles the new way?)
what the scope is. For
instance:
CREATE EVENT TRIGGER name
ON event
[ FOR {ALL|OWNED} ROLES ]
[ WHEN filter_variable IN (filter_value [, ... ]) [ AND ... ] ]
EXECUTE { FUNCTION | PROCEDURE } function_name()
For a superuser ALL and OWNED would be the same, but regular users
would need to specify "FOR OWNED ROLES" or they'd get an error.
Regards,
Jeff Davis
by the apply worker on subscriber
- apply worker runs as subscription owner, so doesn't seem
like a problem?
* connection info may be visible to non-superusers
- seems either solvable or not necessarily a problem
Regards,
Jeff Davis
I'm OK to move past this and continue with Mark's approach.
Noah made the original complaint, though, so he might have something to
add.
Regards,
Jeff Davis
of
> time (with a GUC) so that it can keep looking for the required WAL.
How is archiving configured, and would it be possible to introduce
logic into the restore_command to handle slow-to-arrive WAL?
Regards,
Jeff Davis
ulate how long recovery might take for a given restore point, or
whether it's not going to work at all because there's not enough WAL.
Regards,
Jeff Davis
houghts on this are more clear.
Regards,
Jeff Davis
Simple patch to implement $SUBJECT attached.
pg_signal_backend seems like the appropriate predefined role, because
pg_log_backend_memory_contexts() is implemented by a sending signal.
Regards,
Jeff Davis
From 473e0bb2e1ae0d56dbc6b0262c16b10c6c0454cc Mon Sep 17 00:00:00 2001
From: Jeff
ry_contexts():
https://www.postgresql.org/message-id/flat/e5cf6684d17c8d1ef4904ae248605ccd6da03e72.ca...@j-davis.com
So we can consider that patch separately.
Regards,
Jeff Davis
Add new predefined role pg_maintenance, which can issue VACUUM,
ANALYZE, CHECKPOINT.
Patch attached.
Regards,
Jeff Davis
From e615ad4b4a8c390a4b937dbb5721de5daad5 Mon Sep 17 00:00:00 2001
From: Jeff Davis
Date: Sat, 23 Oct 2021 13:41:41 -0700
Subject: [PATCH] Predefined role
lling the postmaster, not an ordinary backend.
Also, those functions are already GRANTable, so I think we should leave
them as-is.
Regards,
Jeff Davis
From 3be296819d6195cbafce72ab085c8430f1e8a502 Mon Sep 17 00:00:00 2001
From: Jeff Davis
Date: Fri, 22 Oct 2021 13:40:35 -0700
Subject: [PATC
riate to have it in this patch, but please mention it in
> the commit message on why we do this change. I will remove this
> change
> from my patch at [3].
> -SELECT * FROM pg_log_backend_memory_contexts(pg_backend_pid());
> +SELECT pg_log_backend_memory_contexts(pg_backend_pid());
What would you like me to mention?
Regards,
Jeff Davis
e a little too specific for a generic maintenance
operation -- it's unlikely that you'd want to perform those expensive
operations just to tidy up. But if you think something else should fit,
let me know.
Thank you,
Jeff Davis
T anything, and leave that up to the administrator to choose who
can use it.
Regards,
Jeff Davis
n motivation is CHECKPOINT and database-wide VACUUM and ANALYZE.
I'm fine extending it if others think it would be worthwhile, but it
goes beyond my use case.
Regards,
Jeff Davis
rop the idea of granting to that predefined role.
Regards,
Jeff Davis
diff --git a/doc/src/sgml/func.sgml b/doc/src/sgml/func.sgml
index 5677032cb28..b7003fd37a3 100644
--- a/doc/src/sgml/func.sgml
+++ b/doc/src/sgml/func.sgml
@@ -25332,7 +25332,8 @@ SELECT collation for ('foo'
CKPOINT right now has an explicit superuser check, and it would
be nice to be able to avoid that.
It's pretty normal to issue a CHECKPOINT right after a data load and
before running a performance test, right? Shouldn't there be some way
to do that without superuser?
Regards,
Jeff Davis
ten one).
I can cut out the in-function check entirely if there's no objection.
Regards,
Jeff Davis
[1] https://postgr.es/m/33f34f0c-bb16-48de-b125-95d340a54...@amazon.com
On Mon, 2021-10-25 at 17:55 -0300, Alvaro Herrera wrote:
> Maybe you just need pg_checkpointer.
Fair enough. Attached simpler patch that only covers checkpoint, and
calls the role pg_checkpointer.
Regards,
Jeff Davis
diff --git a/doc/src/sgml/ref/checkpoint.sgml b/doc/src/sgml/
widespread. I guess it does feel excessive to have its own predefined
role, but at the same time it's hard to group a command like CHECKPOINT
into a category. Maybe if we named it something like pg_performance or
something we could make a larger group?
Regards,
Jeff Davis
use a function instead, but then
what's the point of the syntax?
Should we just add a builtin function pg_checkpoint(), and deprecate
the syntax?
Regards,
Jeff Davis
ers if
desired.
Thanks everyone for looking.
Regards,
Jeff Davis
On Wed, 2021-10-27 at 16:10 -0400, Robert Haas wrote:
> But the thing that defines a tenant need not be a role. It can be
> some
> other kind of object. Suppose we invent a CREATE TENANT command.
Would it be a recursive concept? Could a tenant create a sub-tenant?
Regards,
Jeff Davis
vent trigger
> patch set to not depend on the role ownership patch set.
Your patch[0] causes role membership to control whether and event
trigger fires. If it was solely based on role *ownership* and had
nothing to do with role *membership*, that does seem better to me.
[0]
https://postgr.es/m/914ff898-5ac4-4e02-8a05-387608700...@enterprisedb.com
Regards,
Jeff Davis
use the function and some will use the
command, creating inconsistency in examples and scripts, and people
will wonder which one is the "right" one.
Regards,
Jeff Davis
[0]
https://postgr.es/m/ca+tgmobqowzn62qwrx+oofjbphdubxytbeo-gsnpclvbhh4...@mail.gmail.com
[1] https://postgr.es/m/8c661979-af85-4ae1-9e2b-2a091da3d...@amazon.com
update/delete).
I'm looking for some review on the approach and structure before I
polish and test it. Note that my main test case is columnar, which
doesn't support update/delete. Also note that the patch is against v14
(for now).
Regards,
Jeff Davis
[0] https://github.com/c
attached.
This feels like a good pattern that we might want to use elsewhere, if
the need arises.
Regards,
Jeff Davis
diff --git a/doc/src/sgml/func.sgml b/doc/src/sgml/func.sgml
index 4b49dff2ffc..1e3152c39b1 100644
--- a/doc/src/sgml/func.sgml
+++ b/doc/src/sgml/func.sgml
@@ -25487
in this
thread.
Robert had a good idea over here though:
https://postgr.es/m/20211101165025.gs20...@tamriel.snowman.net
which gives fine-grained control without the "clutter" of extra
predefined roles.
Regards,
Jeff Davis
s?
Is there a reason you think the messages should be different for heap
versus another table AM? Isn't the table AM a physical implementation
detail?
Regards,
Jeff Davis
1 - 100 of 1478 matches
Mail list logo
