hat to_char
knows about. (I have no idea which locales use that, but I doubt they'd
have put in that complication without need.)
regards, tom lane
o live. As already noted, if it doesn't do
what you want, don't use it.
regards, tom lane
e has any objects/privileges in.
You might need a manual revoke on "the_database" too; I'm not sure
if DROP OWNED does anything about DB-level privileges.
regards, tom lane
he
database thinks.
A different line of thought is that ProcArray slots can be consumed by
things that aren't client connection processes, in particular
(1) parallel-query workers
(2) autovacuum workers
Looking into pg_stat_activity when you see this issue might help
clarify that.
regards, tom lane
. If you don't want to pass 'em as
distinct parameters, then you have to obey some kind of composite-value
syntax.
regards, tom lane
being blocked on a lock,
eg. due to something taking an exclusive lock on pg_authid or pg_database.
pg_locks might be interesting to check.
regards, tom lane
red relation.
Try "select * from pg_locks where locktype = 'relation' and database = 0".
regards, tom lane
.org/docs/current/populate.html
regards, tom lane
e.
ANALYZE (and VACUUM) update the table's pg_class row non-transactionally.
See the comments for vac_update_relstats():
https://git.postgresql.org/gitweb/?p=postgresql.git;a=blob;f=src/backend/commands/vacuum.c;h=5c4bc15b441b36da99b0703500a3268086b40d9e;hb=HEAD#l1266
regards, tom lane
r ICU). You'd need to file bugs against those libraries if you
think their behavior should change.
regards, tom lane
just telling you that the last thing that session
did, four days ago, was a ROLLBACK.
regards, tom lane
n't especially want to write/maintain such logic ourselves,
but there don't seem to be any suitable libraries available that
(a) can be called from C and (b) have a compatible license.
regards, tom lane
that is a hard
fail when cross-compiling, and I don't see a reason for it to be that.
We could just assume that /dev/urandom will be available --- that's no
worse than a lot of the other optimistic assumptions that configure
makes in that mode.
regards, tom lane
Daniel Gustafsson writes:
>> On 30 Nov 2021, at 20:59, Tom Lane wrote:
>> AFAICS this is the only test in our configure script that is a hard
>> fail when cross-compiling, and I don't see a reason for it to be that.
>> We could just assume that /dev/urandom wi
st x"$cross_compiling" = x"yes"; then
+ AC_MSG_RESULT([assuming /dev/urandom])
else
AC_MSG_RESULT([/dev/urandom])
AC_CHECK_FILE([/dev/urandom], [], [])
Off to see if I can verify that before pushing.
regards, tom lane
t all feasible to maintain a
cross-compiling buildfarm member ...
regards, tom lane
The test is useful on net, and I don't particularly
believe that /dev/urandom will be there on one instance of a platform
and not another.
regards, tom lane
6). Why this change
> was made?
You'd have to talk to the packager of whatever distribution you're using.
No such change was made in the core PG code: the configure script still
defaults to LIBDIR=EPREFIX/lib.
regards, tom lane
that
file wasn't there last time you did this, or its contents changed
underneath you.
regards, tom lane
SQL Padawan writes:
> Why is my decrypt function not return the string 'da'? Have I not understand
> something important?
See the bytea_output setting.
regards, tom lane
x27;t
actually tested this, but given the way the code works I'm pretty
sure it's so.) Again, it's hard to see how to do better atop a POSIX
locale library.
regards, tom lane
renthesize it to do so:
... ON CONFLICT (("Lockers"."Uuid"))
regards, tom lane
"Jenda Krynicky" writes:
> From: Tom Lane
>> It's also possible to qualify the name in the ON CONFLICT clause,
>> although I think you have to parenthesize it to do so:
>> ... ON CONFLICT (("Lockers"."Uuid"))
> ERROR:
Vincas Dargis writes:
> Should we expect this fix in the next 14 patch release, or only in 15.x?
I did push it into v14:
https://git.postgresql.org/gitweb/?p=postgresql.git;a=commitdiff;h=175edafd1f30a78643359b56c5545b5e7aabfb50
regards, tom lane
"Sonai muthu raja M" writes:
> Kindly help us to provide the details that how to find User creation date in
> postgresql Database.
This information is not stored by Postgres, so you can't.
regards, tom lane
PI doesn't even pass
the typmod.
regards, tom lane
nLock hold, where it can block the entire system not just
the one process. But even without that, this seems like a performance
penalty with basically no real-world benefit. People who have issues
like this are not going to want to trawl the postmaster log for such
messages.
regards, tom lane
n might try to contact the server.
And it's not hard to see which ones are local state inspection.
regards, tom lane
apparent, thanks to
CLOBBER_FREED_MEMORY and other debug support.
regards, tom lane
Matt Magoffin writes:
> On 5/12/2021, at 5:16 AM, Tom Lane wrote:
>> Are you testing in an --enable-cassert build? If not, do that;
>> it might make the cause of the crashes more apparent, thanks to
>> CLOBBER_FREED_MEMORY and other debug support.
> I did build with --e
results. Why stop there?
AFAICS, PQfinish() already acts that way, at least up to the same level of
guarantee as you have for "all other methods". That is, if you previously
set the connection into nonblock mode, it won't block.
regards, tom lane
Vikas Sharma writes:
> Is it possible in postgres to get the value of the parameter currently set
> in the session of the other user?
No. That information only exists within the other session's process.
regards, tom lane
here are
no triggers, but are you sure? (what about foreign keys?)
Otherwise, it seems possible that you've identified a memory leak,
but there's not enough detail here to investigate. Can you create
a reproducible test case?
regards, tom lane
every type, surely it should mention
bigint, numeric, and timestamptz ...
regards, tom lane
to be MD5-hashed instead of SCRAM-hashed
(see server's password_encryption setting). v14 changed the default
for that from md5 to scram-sha-256.
regards, tom lane
If DO blocks had parameters, the conclusion might be different,
but they don't so far.)
regards, tom lane
ma=gamma || "#postfix#"
> makes the process memory balloon to the point of OOM.
That seems like a bug, but please supply a self-contained test case
rather than expecting other people to reverse-engineer one.
regards, tom lane
Klaudie Willis writes:
> I'll repost it here, corrected, for others to use who wants to exhaust their
> memory:
> --PG-14.1
This leak is new in v14, possibly that's why Vincent didn't reproduce it.
regards, tom lane
counts[i] is zero.
That's seemingly not your problem right now, since the ereport(NOTICE)
is being reached; but it sure looks like trouble waiting to happen.
regards, tom lane
n multiple aggregate declarations on top
of that. Alternatively you can declare one set of polymorphic
functions and aggregates, in which case you'll need to closely
study the stuff about the finalfunc_extra option [2].
regards, tom lane
[1]
ht
effort; though I'd be dubious about the
value. But the fact that it'd have to be transformed into something
testing whether the table is nonempty makes it fairly nontrivial.
I doubt it's worth the development cost plus the cycles imposed
on every other query.
regards, tom lane
ggers, weird constraints, or the like? What is the
actual WHERE clause (ie, I wonder if you have simplified away some
relevant query detail)? What PG version is this exactly?
regards, tom lane
I'm not sure what would be involved in making
that better, but I am sure it'd be a lot of work :-(
regards, tom lane
iulian dragos writes:
> Is there any way to validate the bloated index hypothesis before I invest
> too much in this direction?
A plain old VACUUM ought to take care of most of the problem.
regards, tom lane
&& !pertrans->inputtypeByVal)
pfree(DatumGetPointer(oldVal));
regards, tom lane
a_changes
regards, tom lane
ully, because at
least one of the above statements must be wrong.
(I guess if you were feeling *really* paranoid, you could wonder
whether somebody replaced your postmaster executable with a hacked
version that doesn't apply any pg_hba checks. But pilot error
seems like a far more probable explanation.)
regards, tom lane
ata recovery, rather than trying to handle it
yourself. I'd still follow the wiki page's "first response" advice,
ie take a physical backup ASAP.
regards, tom lane
t; archive_mode = on
> archive_command = '/pgsql/pg-archive-wal-to-slaves.sh "%p"'
You have archive_mode on, so WAL files will not be removed until
your archive_command reports success. Poke around in what that's
doing.
regards, tom lane
estamptz;
timezone
2021-12-29 05:00:00-05
(1 row)
I have no idea what you were hoping to accomplish there, so
I have no suggestion what to do instead.
regards, tom lane
-input, but you'll have to do it with explicit logic.
regards, tom lane
nc(param1 => 42, param3 => 99);
regards, tom lane
epared-and-never-committed transactions).
That's just a workaround of course. It's not very clear whether
there's any actual data corruption here, but if you're not having
SELECT problems, it seems like whatever it is isn't critical.
regards, tom lane
x27;d
have to slice it up with an editor.
regards, tom lane
that the message
could look more like "MD5 is disallowed in FIPS mode".
regards, tom lane
/usr/lib[64])
unless you mess with the dynamic loader's configuration.
Try "ldd /path/to/psql" and see what it says about which libpq
is getting used.
regards, tom lane
efault PG would link psql using an rpath switch pointing at
/usr/local/pgsql/lib, which I assume is where your manual build
put its libpq.so. That's evidently not having success getting that
libpq.so to be used. Did you tell configure to --disable-rpath?
Or maybe move the installation after building it?
regards, tom lane
Michael Paquier writes:
> On Tue, Jan 04, 2022 at 12:54:35PM -0500, Tom Lane wrote:
>> I reproduced this on Fedora 35 with FIPS mode enabled. The problem
>> is that OpenSSL treats MD5 as a disallowed cipher type under FIPS
>> mode, so this call in pg_cryptohash_init fails
he ability to store sets of key/value pairs.
https://www.postgresql.org/docs/current/datatype-json.html
https://www.postgresql.org/docs/current/hstore.html
regards, tom lane
tter ways to do it by now.
regards, tom lane
you did this as some other role.
But actually capturing the DB's privileges at the point where the
DROP ROLE is failing would help you debug.
regards, tom lane
[ please keep the list cc'd ]
Dominique Devienne writes:
> On Wed, Jan 5, 2022 at 7:26 PM Tom Lane wrote:
>> That will only revoke privileges that were granted by the role
>> doing the REVOKE, so I surmise that you did this as some other role.
> Hmmm, that's int
ditional field in pg_cryptohash_ctx.
Also, I wonder if this shouldn't be unified with the SSLerrmessage()
support found in be-secure-openssl.c and fe-secure-openssl.c.
regards, tom lane
diff -u cryptohash_openssl.c.orig cryptohash_openssl.c
--- cryptohash_openssl.c.orig 20
Michael Paquier writes:
> On Thu, Jan 06, 2022 at 11:40:04AM -0500, Tom Lane wrote:
>> Also, I wonder if this shouldn't be unified with the SSLerrmessage()
>> support found in be-secure-openssl.c and fe-secure-openssl.c.
> Guess so. HEAD could be poked at for this par
Ali Koca writes:
> I'm seeing \dt used for "show tables", \l used for "show databases". Why
> not standart SQL syntax words? Why specified PostgreSQL commands?
> I can't figure out that.
"show tables" isn't standard either.
regards, tom lane
x27;re used to mysql's
extensions ... you'll need to learn about postgres's.
regards, tom lane
#x27;s some risk there,
but I think it's minimal because of the fact that we preallocate
some space in ErrorContext.)
Other than those things, I think v3 is good to go.
regards, tom lane
2+2 it fails with here.
There's not a lot of penalty to increasing max_locks_per_transaction,
but no you can't make it "unbounded".
regards, tom lane
deleting *any* cataloged database object. So you'd also need a lock
for each schema, function, etc that was due to get dropped. This is
basically to avoid problems in case of concurrent drop commands.
It's still true that the size of a relation in columns or rows is not
relevant here.
regards, tom lane
Dominique Devienne writes:
> OK :). But it does matter. those locks. Especially if DROP'ing a DB (as you
> suggest) requires just the same.
But it doesn't.
regards, tom lane
If you must do it, DISCARD PLANS might help you
with keeping plpgsql functions in line.
regards, tom lane
[1]
https://www.postgresql.org/docs/current/plpgsql-implementation.html#PLPGSQL-PLAN-CACHING
fore Unicode became widespread, but I'd be hesitant
to change it now.
regards, tom lane
e(anyelement)
aggregate. Say DROP AGGREGATE public.mode("anyelement")
(I'd be pretty cautious about using CASCADE, too, at least till
you've seen what would get dropped.)
regards, tom lane
running and observe values as high as
> 21758, so if this is the issue it seems like I might not be estimating the
> max size of the lock table correctly or only specific locks contribute to
> that.
I don't recall for sure, but I think that the lock table has one entry per
lockable object, while the pg_locks view shows separate entries for
different lock modes on the same object.
regards, tom lane
Mladen Gogala writes:
> On 1/13/22 18:35, Tom Lane wrote:
>> .. or else reduce the number of partitions you're using. (People
>> frequently seem to think that more partitions are free. That is
>> extremely not true. I generally think that if you're using more
>
vidence of the primary cause.
regards, tom lane
ent ---
inconsistency is worse than a confusing error message.
Personally I'm satisfied to leave it as-is, since this issue apparently
occurs only in a minority of OpenSSL versions, and not the newest.
regards, tom lane
Michael Paquier writes:
> Leaving things in their current state is fine by me. Would it be
> better to add a note about the business with 3.0 though?
What do you envision saying? "We don't need to do anything here
for 3.0" doesn't seem helpful.
regards, tom lane
ttach "SET search_path = public"
to that function, but I believe that destroys the ability to
inline it, which might be a performance problem for you.
Alternatively you could schema-qualify the operator name,
that is "foo OPERATOR(public.->) bar".
regards, tom lane
going to be helpful for that.
regards, tom lane
I'd first try enabling log_statement on the server to see if the
query is really being presented exactly the same way. Another
thing worth trying is auto_explain, to capture the plans actually
being used.
regards, tom lane
to send to the client, and there's no table involved.
regards, tom lane
that's effectively the same thing as our
custom plans.
regards, tom lane
is composed, the mapping of
> 'newname' to the 'name' in the base table does not take effect.
Huh? The CONTEXT line shows what was issued to the remote server,
and it's very obvious that we *are* asking for "newname", as indeed
is also implied by the error
Dominique Devienne writes:
> On Fri, Jan 21, 2022 at 5:47 PM Tom Lane wrote:
>> There is a notion of "custom plans" in which parameter values are
>> inserted as constants, precisely to allow simplifications based on
>> known constant values. But this particular c
future problems.)
regards, tom lane
current
behavior in other ways. It's hard to be sure, but it is worth
noting that it's been a long time since \connect arguments were
only identifiers. We'd have to consider the impact on the
connstring case, too.
regards, tom lane
ty.
> Are these the only 2 solutions possible?
As of v14 you could use SQL-style function definitions, so that the
operator is parsed at function definition time instead of runtime.
regards, tom lane
ly 25-40 processes being connected.
Hmm ... if you're sitting on a VM rather than directly on the iron,
then there's a whole bunch of other potential reasons for irregular
performance, most of which you probably can't see from inside the VM.
regards, tom lane
ollation should also work,
and might be preferable to using the pattern_ops opclass.
C collation has at least some chance of being used explicitly
in queries, whereas a pattern_ops index is basically never going
to match anything but LIKE/regex searches.
regards, tom lane
w
it wants to lock. This command won't reach the pg_try_advisory_lock
call until that row lock comes free.
regards, tom lane
nership of the extension's objects. I don't know
of anyone working on it at the moment.
regards, tom lane
\s])',
'g');
count
---
2
(1 row)
(Note that 2 is the correct answer given that there's no space
after the third word; I trust Oracle agrees.)
regards, tom lane
'((?:[A-Z][a-z]+[\s]*)+)',
'g');
regexp_matches
{"My High Street"}
(1 row)
In any case, there's no substitute for reading the manual.
regards, tom lane
[1]
https://www.postgresql.org/docs/current/functions-matching.html#FUNCTIONS-POSIX-REGEXP
gt; configuration is appropriate. It also won't help if you want to modify the
> settings on your primary and make sure that you won't have an incident on your
> HA setup.
I don't recall any field complaints, ever, about this behavior.
So I'm skeptical that it's a place to expend effort.
regards, tom lane
this has anything to do with Postgres as such;
there are lots of inter-system and inter-release discrepancies in
collation behavior.
regards, tom lane
usecs = 1;
}
Now admittedly we don't have a good way to test this stanza, but
it should result in re-establishing the timer interrupt the next
time any timeout.c API is invoked after a missed interrupt.
I don't see anything more that we could or should do. We're
not going to issue setitimer() after every user-defined function
call.
regards, tom lane
nt
pg_database fields. The remaining LC environment variables
shouldn't affect this (and I think we force them to "C"
anyway).
regards, tom lane
pected, are
> there any other negative consequences? Are any of the timeouts
> time-critical such that being delayed by a few seconds would cause a
> problem?
They're certainly not supposed to be that time-critical; any code that
is expecting such a thing is going to have lots of prob
k strength is involved in CREATE
TRIGGER. I don't recall offhand what we use, but it would at least need
to block operations that might fire such a trigger.
regards, tom lane
2501 - 2600 of 2962 matches
Mail list logo
