Tomas Vondra writes:
> Yeah, this seems like a clear bug - we should not fail queries like
> this. It's a sign statext_is_compatible_clause() and the MCV code
> disagrees which clauses are compatible.
Indeed. I attempted to fix that at e33ae53dd.
regards, tom lane
e-and-after scripts before applying though :-)
regards, tom lane
;AS".
(Mind you, I think the SQL spec made a serious design error
in allowing "AS" to be optional. But we have to live with that
as best we can.)
regards, tom lane
ing with
"pg_". So this idea seems like a wart rather than something
anybody would think is a nice improvement.
regards, tom lane
ask this sort of
question in a way that would obtain useful answers:
https://wiki.postgresql.org/wiki/Slow_Query_Questions
regards, tom lane
, and ask some hard questions about the reliability
of the storage stack you're sitting on.
regards, tom lane
pect not though, at least not without work that seems
rather pointless).
regards, tom lane
[1] https://en.wikipedia.org/wiki/Julian_day
x27;s not EOL.
regards, tom lane
per-setting documentation in chapter 20:
https://www.postgresql.org/docs/current/runtime-config-client.html#RUNTIME-CONFIG-CLIENT-FORMAT
regards, tom lane
three) sorts
of objects in the same catalog was a great design. However, that's
what we've got and changing it seems like more trouble than it'd be
worth.
regards, tom lane
object references in the function
are parsed at definition time.)
regards, tom lane
iciency; specifically to let constraints
be looked up by name+namespace without having to get other
catalogs involved. (SET CONSTRAINTS is one thing that requires
that, and I think there are others.)
regards, tom lane
produces a different plan. That's when it switches
> from planning every time to planning with generic arguments, as I
> recall.
In recent versions you can bypass that with
SET plan_cache_mode = force_generic_plan;
regards, tom lane
d, and (c) can be adapted to
a lot of other kinds of analysis besides plain count(*).
regards, tom lane
ck and a hard place.
Our experience has been that printing the coercions explicitly causes
fewer problems than not doing so, so that's what it does.
regards, tom lane
at's the software
stack on the client side, but it has to be coming from one or another
layer there.
regards, tom lane
er is doing that conversion on the client side.
regards, tom lane
l if it can't look up that
directory.
Why it's trying to resolve a symlink isn't apparent though.
Is the "psql" you're invoking a symlink to somewhere?
regards, tom lane
erson asking why you want to sudo to postgres
at all, though. It's generally safest if the client side isn't running
as the same user as the server.
regards, tom lane
[1] https://www.postgresql.org/message-id/797232.1662075573%40sss.pgh.pa.us
nown-good parameters and check
the system catalogs.
regards, tom lane
Ron writes:
> On 9/2/22 17:21, Tom Lane wrote:
>> That's a feature actually. The intended use of pg_isready is to
>> find out if the server is alive, not whether any particular user
>> or database name is correct.
> Then what's the point of the --username=U
have done ALTER USER SET or ALTER DATABASE SET
commands that'd change it in those sessions? You could look in
the pg_db_role_setting catalog to answer that definitively.
regards, tom lane
procedures'
session is changing the value itself. (This is scary, because it implies
that you're running those as superuser, which seems like a bad idea.)
You might have to enable log_statement = all to verify that.
regards, tom lane
"Dirschel, Steve" writes:
> I believe this clearly points to an issue with pg_cron. Would you agree?
Yeah, you certainly need to look into what sort of environment
that is setting up. I know zip about pg_cron, can't help you
there.
regards, tom lane
disk. You sound like you've set it up to be *more*
persistent (ie outside the container not inside), which surely is
exactly backwards.
regards, tom lane
_depend row having objid = 476444? What's in it?
regards, tom lane
Wen Yi writes:
> I want to do some research on the hstore,but I can't find its source.
It's in the Postgres source distribution, under contrib/hstore/
regards, tom lane
mless as far as I can see
from the OpenSSL docs.
regards, tom lane
Daniel Gustafsson writes:
> On 11 Sep 2022, at 17:08, Tom Lane wrote:
>> Don't believe so. The HAVE_CRYPTO_LOCK stuff is all obsolete and
>> not compiled if you built against 1.1.0. The only thing left that
>> will happen if you don't call PQinitOpenSSL is an ex
wever, this is unnecessary when using OpenSSL 1.1.0 or later,
+ as duplicate initializations are no longer problematic.
If you do use wording that specifically mentions PQinitOpenSSL,
it should also mention PQinitSSL, just for clarity.
regards, tom lane
psql -h 127.0.1.1
psql (16devel)
Type "help" for help.
postgres=# select client_addr from pg_stat_activity;
client_addr
-
...
127.0.0.1
...
Moral: don't try to use addresses in that range as real addresses.
regards, tom lane
Simon Riggs writes:
> On Sun, 21 Aug 2022 at 19:04, Tom Lane wrote:
>> There are existing equations for calculating Gregorian month/day/year from
>> Julian day count [1]. They work back to Julian day zero, at least if
>> you grant that proleptic Gregorian dates are s
Simon Riggs writes:
> On Mon, 12 Sept 2022 at 16:00, Tom Lane wrote:
>> No, it applies because we aren't sure that the math would operate
>> correctly with negative Julian day numbers --- for instance, division
>> roundoffs might happen in the wrong direction.
be was deemed to be a bug (after
> that behavior had survived from at least version 11) and that it's now been
> fixed!
No, it very much looks like pilot error. But you've not shown
us exactly what your test consisted of, so it's hard to say just
where it went off the rails.
regards, tom lane
ave to represent a compromise
that we think is generally useful. You're welcome to lock your
own installation down more than that, but it doesn't follow that
everybody else should too.
regards, tom lane
s about no-op
grants. I wonder if issuing a warning for no-op revokes would be
helpful.)
Jeremy's nearby theory that the REVOKE was done in a different
database seems like a pretty good explanation of Bryn's issue.
regards, tom lane
ther 90% are below 2
> seconds,
> i.e. this is digital: Or 2 seconds, or more than 180 seconds, no values
> between.
I'm wondering about a plan change. Can you install auto_explain on
the server and capture info about the fast and slow cases?
regards, tom lane
if that gets too
bloated. I don't recall much about how to control that, but I think
vacuuming the table will serve to empty the pending list. Also see
https://www.postgresql.org/docs/current/gin-implementation.html#GIN-FAST-UPDATE
regards, tom lane
... and here you're testing the permission in the "scott" database.
regards, tom lane
rm are limited as the overall design specifies.
is in any way sane or secure. There is not very much that the
database server can do to clean up after insecure client-side stacks.
regards, tom lane
ROLE
regression=# \c - joe
You are now connected to database "regression" as user "joe".
regression=> select 2+2; -- not so much for anybody else
ERROR: permission denied for function int4pl
regards, tom lane
ou have hostile actors able to issue arbitrary SQL
in your database, in which case you're in a world of trouble anyway.
regards, tom lane
Laurenz Albe writes:
> On Thu, 2022-09-15 at 11:19 -0400, Tom Lane wrote:
>> I'm a little bemused by your fixation on this particular CVE,
>> though. As such things go, it's not a very big deal.
> A lot of times, requests like that come from a brainless kind of
>
a workaround. I suspect
that Apple doesn't want people using these OS components from "outside",
and this is something they're intentionally doing to prevent it.
IOW: I think they want you to get that from macports or homebrew instead.
It certainly works a lot easier if you do.
tax. But ARRAY()'s problem is semantic not
syntactic.
regards, tom lane
handle
some related cases like "x => x IS NOT FALSE".
Whether it's worth the cycles isn't too clear to me, but we could
argue about that if somebody submitted a patch.
regards, tom lane
essary, *is* tolerated.
You can pretty much always add *extra* parens in any expression
context.
regards, tom lane
r and/or whatever else you
wish you could take back, end that session, restart the cluster.
(You're not the first to mess up like this.)
regards, tom lane
ing so, you could maybe ameliorate things by implementing the RLS
check functions in the fastest way you can, like writing C code
for them.
regards, tom lane
uot;.
then keepalives aren't necessarily the solution anyway. When is
this failure occurring ... is it while trying to establish the
database connection in the first place? Or does it only happen
if you've left the psql session sit idle for a long while?
regards, tom lane
hours, at least on my Linux box:
$ cat /proc/sys/net/ipv4/tcp_keepalive_time
7200
but it sounds like there's something between you and the database
server that will forget connections a lot quicker than that.
regards, tom lane
ement this
sort of behavior; they are less prone to surprises.
regards, tom lane
xit() with values 0 or 1. 255 would have to be coming
from some outside factor. You sure your shell script isn't
misbehaving and corrupting the reported return code?
regards, tom lane
ional sorting overhead, which is annoying. But work is
ongoing to recognize when the input is already correctly sorted
for an aggregate, so it should get better in PG 16 or so.
regards, tom lane
7;d make the whole affair annoyingly
data-type-specific. Not sure it's worth going there.
regards, tom lane
oint in user X mounting defenses against user X.)
So I think the concerns you're expressing here would be better addressed
at the next level up the stack.
regards, tom lane
le, there's
no need for privileges on individual children --- we only check
tables(s) directly named in the query.
regards, tom lane
ure that that's actually required, if your action is
only one C statement. I suspect it's just making the action into
a valid C compound block.
regards, tom lane
appears from
the discussion in [2] that we're probably going to stick to the
policy of not encouraging use of custom parameters as application
state, although if [1] keeps failing to land maybe that will change?
regards, tom lane
[1]
https://www.postgresql.org/mess
s undefined_table then you know what to do.
regards, tom lane
uestion. My gut feeling is that the subtransaction created by the
BEGIN ... EXCEPTION construct is more expensive than a no-op CREATE
IF NOT EXISTS. I've not measured it though; and I'm pretty sure that
the answer would vary depending on how often you expect the code to fall
through versus needing to create the table.
regards, tom lane
Steve Baldwin writes:
> Looks like it's official ? - https://www.postgresql.org/docs/release/15.0/
No, that's just the RC1 version. Note the "Release date:" line is still
not set.
regards, tom lane
ave to use PQcmdTuples(), and you have to convert the string to an
> integer.
> But don't worry: the result will *not* be "INSERT 0 5", it will be just "5",
> so
> you won't have to parse anything.
Yeah, just applying atoi() or atol() to the result should be enough.
regards, tom lane
ely that something quote_ident decides
not to quote would be rejected by some future PG version (not to mention
non-PG SQL databases). So I'm not really in a hurry to change the code.
Maybe we should tweak the docs a bit.
regards, tom lane
that you should not
rely on, and most certainly shouldn't try to make use of from user
code. It exists because very ancient versions of pg_dump didn't
know how to dump views as views. We're more likely to rip it out
as no-longer-needed than to expand what it does.
regards, tom lane
ntly the fix requires an
updated pg_dump more than pg_restore. However, I believe that only
happens with -c, so why are you using both -c and -C?
regards, tom lane
Ron writes:
> On 10/6/22 09:49, Tom Lane wrote:
>> Ron writes:
>>> pg_dump 9.6.24
>> You realize that that version's been out of support for a year?
> Yes, which is why I'm dumping from an EOL cluster, and restoring to a
> supported version.
But why
ike a table.
regards, tom lane
Kouber Saparev writes:
> Excuse me, I didn't understand what was about to be ripped out then.
The fact that creating a _RETURN rule for a table causes it to be
changed into a view. That's ugly and arguably dangerous.
regards, tom lane
tistics yet.
regards, tom lane
n you want.
If not, then there's something else going on besides poor estimates.
regards, tom lane
that the databases are
*not* identical. You just haven't figured out how yet. I'm wondering
if it has something to do with the dump/reload having compacted out
bloat in the tables or indexes, causing cost estimates to change.
regards, tom lane
o the
LIMIT estimation to reduce the chance of being fooled this way,
that would also discourage us from using fast-start plans when
they *do* help. So I don't see any easy fix.
regards, tom lane
r than 11.5, but I might've missed something.
regards, tom lane
customer has checksums enabled, which means that
> MarkBufferDirtyHint() should be guaranteed to mark the buffers as dirty, so
> I'm
> out of ideas to explain the different behavior on standbys.
Do we propagate visibility-map bits to standbys?
regards, tom lane
sed some in-fact-dead index entries to get cleaned out.
But ... if the primary is allowed to vacuum away an index
entry that it thinks is dead, exactly what is the point of
making standbys ignore LP_DEAD bits? There's no additional
interlock that guarantees the tuple will be there at all.
ate the result weight, so with a little code re-ordering we won't
need duplicative estimates. Don't have time to work on that right now
though ... Dean, are you interested in fixing this?
regards, tom lane
"
> I don't understand why this functions is included in the dump in the first
> place.
Indeed. No such function should be present in any version of contrib/xml2
that was ever converted to extension style. Have you never done that
in this DB?
regards, tom lane
ts, and produces a minimum of 16 significant digits,
> rather than 16 digits after the decimal point.
Right. I think this is not bad though. In a lot of cases (such
as the example here) the current behavior is just plastering on
useless zeroes.
regards, tom lane
to avoid fetching the OID altogether that way.
regards, tom lane
bpchar works for me.
regression=# select pg_typeof(torus(f1)) from char_tbl;
pg_typeof
---
character
Another possibility is to have just one function declared
to take and return anyelement. You'd get failures at
execution if the actual argument type isn't coercible
to and from text (since translate() deals in text) but
that might be fine.
regards, tom lane
field
Personally I'd also throw in "... and atttypid = 'bpchar'::regtype",
because that atttypmod calculation will give you garbage for types
other than bpchar and varchar.
regards, tom lane
Andrus writes:
> How to change this query so that it searches schemas in set search_path
> order and returns column width from it ? In this case p_namespace
> parameter can removed.
I showed you that already: regclass will take care of it.
regards, tom lane
hat there's too much code
involved to have much confidence that it would stay leakproof.
regards, tom lane
leakproof.
Please note that this definition talks only about the behavior
of the function itself. Re-reading your email, you seem to be
imagining that changes in a query's plan on the basis of changes in
collected statistics have something to do with this. They do not.
regards, tom lane
ble, or
maybe we could rerrange things to remove it. But there's still enough
code underneath the timezone conversion requirement that I'd be very
hesitant to apply a leakproof marking. In short: it might be leakproof
in practice, but we don't wish to offer a guarantee.
regards, tom lane
7;t throw errors.
I don't see a good argument for making a exception for this one.
regards, tom lane
tgres developers regard CHAR(N) as an
obsolete hangover from the days of punched cards, no such
optimizations have been attempted.
regards, tom lane
interpret that differently?
regards, tom lane
Dominique Devienne writes:
> On Tue, Oct 18, 2022 at 6:04 PM Tom Lane wrote:
>> Thus, there's always a header to store the actual length. That can
>> be either 1 or 4 bytes (I think the doc you are looking at might be
>> a little out of date on that point).
>
h changing the function to plpgsql
instead of SQL. Not sure about the relative performance of those
cases, but it's worth trying it both ways.
regards, tom lane
ies of the public schema will depend on whether you clone it
from template1 or template0. That definitely needs explained, and
maybe we should recommend that DBAs consider manually changing
what's in template1.
regards, tom lane
nts.
We don't have enough details to do more than guess, though.
regards, tom lane
ectory out of the way and move the new one to
/home/dmartuser/pgdata/data, if you like.
regards, tom lane
ere.
regards, tom lane
r plan, I suppose 14.something, but is it up to date?
There were Memoize-related bug fixes in 14.2 and 14.4, and the
one in 14.2 looks particularly likely to be relevant.
If you are on the current minor release, does "set enable_memoize = off"
change the behavior?
regards, tom lane
was an actual bug.
regards, tom lane
> but probably academic and thus Perl and others picked it up "from the
> source".
Looks to me like you suggested our use of the terminology:
https://www.postgresql.org/message-id/flat/CAKFQuwZQmCNyS_Vv2Jf3TNe7wRTiptWNs7xkgU%3DAEdqthkQe9A%40mail.gmail.com#bbcd739c97e28b17ef2e111be8
esn't depend
much at all on your data, just the schema.
regards, tom lane
o find one?
https://www.postgresql.org/docs/devel/system-catalog-initial-data.html#SYSTEM-CATALOG-OID-ASSIGNMENT
regards, tom lane
1201 - 1300 of 2962 matches
Mail list logo
