Igor Korot writes:
> On Tue, Mar 4, 2025 at 8:37 PM Tom Lane wrote:
>> ... but given that you didn't specify any data type, I think the
>> parser will fall back to assuming that $1 is the same type as
>> "abf_type", whatever that is. Passing data in bin
'$PASSWORD'"';'
Note this will fall over with potential for SQL injection if there's a
single quote in the password, so better not use it with untrusted
input. On the whole I'd say "find some other way to do that".
regards, tom lane
.
And the case can't really happen without a function referencing the
index's base table; for example, a query from another session can't
see the uncommitted index at all.
regards, tom lane
is. Passing data in binary is not at all
forgiving about getting the data type right.
regards, tom lane
might get different results in different months.
Another idea is to check, after doing each addition, to make
sure that the timestamp actually advanced in the expected
direction. But should we error out if not, or just stop?
regards, tom lane
difficulty of
identifying the sign of an interval.
regards, tom lane
diff --git a/src/backend/utils/adt/timestamp.c b/src/backend/utils/adt/timestamp.c
index 9682f9dbdca..202bbd1edcd 100644
--- a/src/backend/utils/adt/timestamp.c
+++ b/src/backend/utils/adt/timestamp.c
@@ -6622,6 +662
e usual Emacs combinations Ctrl-A, Ctrl-E, Escape-B, Escape-F
and so on work in psql. I don't believe I did anything special
to configure that. Check your local readline documentation.
As Adrian notes, there's also \e, which is good for entering
or editing multi-line queries.
regards, tom lane
ng to that, but I've not checked
into it.
regards, tom lane
think is
better: an example with only half a dozen rows is going to be
swamped by startup costs.
regards, tom lane
Dominique Devienne writes:
> On Fri, Feb 21, 2025 at 3:33 PM Tom Lane wrote:
>> REASSIGN OWNED then DROP OWNED is the recommended path.
> Hi. Am I missing something? foobar does not OWN anything in this case.
> So I don't see how these recommendations are relevant to th
ED then DROP OWNED is the recommended path.
regards, tom lane
ly
> certain lists (like hackers)?
It should work for any message that appears in our mail archives.
It's just a shortcut for
https://www.postgresql.org/message-id/MESSAGE_ID
regards, tom lane
g distinct grants (not same
grantor/grantee/granted roles). Wouldn't hurt to test.
regards, tom lane
have to say "GRANTED BY "
to get that effect. I'm not entirely sure, but I think this is closer
to what the SQL standard says.
regards, tom lane
ently,
> in two long running transactions? How am I supposed to resolve this?
The window is probably too small to hit if each restore is committing
as it goes, but if you run in --single-transaction mode then this
isn't surprising. I'd say don't try to run concurrent restores.
regards, tom lane
"David G. Johnston" writes:
> On Thu, Feb 20, 2025 at 9:05 AM Tom Lane wrote:
>> It used to be that if a superuser issued GRANT/REVOKE, the operation
>> was silently done as the owner of the affected object.
> That is still the case according to the docs (REVOKE)
te_subscripts($1, 1) i
$function$
regression=# create or replace function wrapper(anyarray)
RETURNS SETOF record LANGUAGE sql as
$$ select 1; select array_to_set($1); $$;
CREATE FUNCTION
regression=# select wrapper(array[44,55,66]);
wrapper
-
(1,44)
(2,55)
(3,66)
(3 rows)
regards, tom lane
ry shortly [1]. Maybe somebody
will be excited enough to consider changing the docs in the back
branches. But since it was like this for a couple of decades,
I bet not.
regards, tom lane
[1] https://www.postgresql.org/message-id/flat/8216639.NyiUUSuA9g%40aivenlaptop
n's plan cache, but implemented in about the stupidest
way possible. Jacking that up and rolling the plancache.c
infrastructure underneath has been on my to-do list for years.
regards, tom lane
ed to be scanned as a
consequence of noticing that the columns have significant correlation.
The shape of that penalty function would be mostly guesswork though,
I fear. (Even with a clear idea of what to do, making this happen
seems a little complex --- just a SMOP, but I'm not very sure how to
wire it up.)
regards, tom lane
ave autonomous transactions (not yet anyway),
and you can't fake them like that.
A way that does work, I believe, is to set up a second session with
dblink[1] and use that to issue the autonomous transaction. Ugly
and inefficient for sure, but if you've gotta have it...
llowing the original INSERT (which was outside both subtransactions)
to complete.
regards, tom lane
ide regex, which is a facility pg_restore
doesn't have access to. Maybe it'd be good enough to implement
the "*" and "?" wildcards and stop there, but I'm not sure.
regards, tom lane
gsql's FOREACH SLICE syntax:
https://www.postgresql.org/docs/devel/plpgsql-control-structures.html#PLPGSQL-FOREACH-ARRAY
You could probably make a custom version of unnest that uses that
and then keep your query about the same.
regards, tom lane
ntially usable for this query, and they all have different cost
curves depending on how selective the col_a condition is. Even the
index on col_b alone could potentially be the best, because it'll be
smaller than the two-column indexes. So if the col_a condition is
very unselective then it
"David G. Johnston" writes:
> On Thu, Mar 20, 2025 at 2:56 PM Tom Lane wrote:
>> That's documented elsewhere, I believe. For the foo_d.h files,
>> I think it'd be sufficient to do something like 0001 attached.
> WFM. Thanks.
Thanks for looking at it.
&
ml#350
regards, tom lane
?
If you think there are changes we need to make, you'd better get
specific sooner not later. I'm not aware of any large fixes that
are pending, cf
https://wiki.postgresql.org/wiki/PostgreSQL_18_Open_Items
regards, tom lane
rticularly short on coverage here:
one or the other code path is fully exercised in each case,
according to the coverage.postgresql.org results.
regards, tom lane
eans.
Sorry --- it means BRIN indexes that use one of the "xxx_bloom_ops" opclasses.
https://www.postgresql.org/docs/current/brin.html#BRIN-BUILTIN-OPCLASSES
regards, tom lane
;s an additional optimization blocker. I'd look
closely at whether the output column types of the UNION arms match.
regards, tom lane
that's your problem. The source tables' column types
need to match. Otherwise the UNIONs don't get flattened and you
don't get indexscans.
regards, tom lane
Markus Demleitner writes:
> On Tue, May 13, 2025 at 10:12:46AM -0400, Tom Lane wrote:
>> Oh, well, that's your problem. The source tables' column types
>> need to match. Otherwise the UNIONs don't get flattened and you
>> don't get indexscans.
> Ahhh
Alvaro Herrera writes:
> I'm going to fix the query in the release notes for all past branches
> now, to avoid confusing people upgrading in the future ... hopefully not
> many, but I don't think it's going to be zero people.
OK, thanks.
regards, tom lane
ugh:
https://www.postgresql.org/docs/current/regress-coverage.html
regards, tom lane
"lists." is
preferred nowadays, but there is no functional difference.
regards, tom lane
ssues in some
contexts.
regards, tom lane
iness of using
passwords rather than other ID technologies (SSL certificates,
Kerberos/GSS tickets, etc) is feeling pretty twentieth-century.
regards, tom lane
ot;my_database_ro";
Well, you aren't going to be able to do that if you're not superuser.
You could undo that ALTER in the source database and re-make the dump,
or edit the dump script to remove this command, or not use
pg_restore's "-1" switch and just ignore this error.
regards, tom lane
r a new backend process to figure
out which database it's supposed to connect to and then detect whether
the per-DB connection limit is exceeded. In the meantime, that
session does count against the global limit, so yeah this isn't
surprising if the connection arrival rate is high enough.
Arnold Hendriks writes:
> Is there a way to ensure new IDs are in the usual range when starting
> in in single user mode?
No. Start the DB in normal mode, then create objects that you
want to be considered user-defined.
regards, tom lane
list of
all of t's columns, just as would happen in a SELECT's output list.
Try
returning merge_action(), t
It might also be necessary to declare the target variable
"m_new_data" as being of type my_table rather than generic
"record"; not sure about that.
regards, tom lane
te field). I didn't try this approach though.
regards, tom lane
R triggers run as the instigating user.
regards, tom lane
an option in the client execute functions (and/or implement
> the backend support) to specify the expected number of statements.
I don't see the need for this given #2.
regards, tom lane
, we'd much rather
find it and fix it before 18.0 comes out.
regards, tom lane
ndroppable
built-in types, we don't bother to make dependencies on them. And
you're not changing the domain's schema or owner, so its other
dependencies don't need to change.
regards, tom lane
or
handling in COPY.
As you say, there are some cases where it's hard to avoid
an exception, but I'm not sure that "better error message"
is a good justification for throwing one. Still, in the
end it's your own judgment to make.
regards, tom lane
tivity() takes a snapshot of the view's contents and then
holds onto that snapshot until end of transaction. You can get
around that with pg_stat_clear_snapshot().
regards, tom lane
ty
hazards already. We'd do better to remove them, not add more.
So in short, while it would not be terribly hard to put in what
you suggest, we'd be creating a lot of work for people other than
ourselves. And the end result when all the dust had settled would
likely be just marginal security gains for a small subset of users.
regards, tom lane
it a try; be sure to use one of the pg_dump modes
that compress the data.
regards, tom lane
to some less PG-unfriendly distro while
you are at it.
regards, tom lane
ly (mainly to capture
your role definitions) and then pg_dump each database into a separate
compressed file.
regards, tom lane
essage-id/flat/680bdaf6-f7d1-4536-b580-05c2760c67c6%40deepbluecap.com
We'll have a fix in next month's quarterly releases. For the moment,
you could either roll back to 15.12 or cherry-pick the fix at
commit fc0fb77c5.
regards, tom lane
ite permissions on the mount
point, which dictates making a separate data directory (with
different ownership/permissions) just below the mount.
Do not bypass that ownership/permissions check. It is there
for very good reasons.
regards, tom lane
things, both during inserts and searches".
If you had some evidence about when and how the index became corrupt,
it'd be worth studying that, but it sounds like you don't.
regards, tom lane
ate before it fails.
It occurs to me to wonder though if we couldn't provide more
context in the error about what lock is being waited for.
regards, tom lane
"Peter J. Holzer" writes:
> On 2025-07-14 10:07:20 -0400, Tom Lane wrote:
>> That is primarily for safety reasons: if for some reason the
>> filesystem gets dismounted, or hasn't come on-line yet during
>> a reboot, you do not want Postgres to be able to wr
ike that. There might be related
discussion in our archives, but finding it could be difficult.)
regards, tom lane
storage.
(But I too would not use Postgres-over-NFS for any critical data.
Too many moving parts. It's tough enough to ensure crash safety
with local storage.)
regards, tom lane
apply to large
tables.
regards, tom lane
[1]
https://www.postgresql.org/docs/current/using-explain.html#USING-EXPLAIN-CAVEATS
that should have gone out with
floppy disks.
You need some extremely fundamental re-examination of your
design decisions. At the moment I am content to say that
Postgres does not support this storage mechanism and we
do not intend to do so in the future.
regards, tom lane
2901 - 2962 of 2962 matches
Mail list logo
