sually type?
Sadly, the visible evidence here doesn't tell us much of anything
about what provoked the crash :-(
FWIW, there's a pretty good chance that this isn't psql's fault
per se, but a libreadline bug. You might check to see if you can
get a newer readline version inst
enly wondering if it could be
explained by misinterpreting the date field order (month-day vs
day-month). Check the datestyle settings on both machines.
regards, tom lane
Andres Freund writes:
> On 2020-03-16 12:44:53 -0700, Andres Freund wrote:
>> On 2020-03-15 20:11:18 -0400, Tom Lane wrote:
>>> I wonder if we should change it to allow that when
>>> allow_system_table_mods is true? This isn't the first time we've
>>>
Don Seiler writes:
> On Mon, Mar 16, 2020 at 10:28 AM Tom Lane wrote:
>> I don't think you should use pg_upgrade here at all. A dump/restore
>> is really the only way to make sure that you have validly encoded data.
> That is what I thought, and probably not what the
psql's FETCH_COUNT option
active in one configuration and not the other, and if so whether that
could explain anything.
regards, tom lane
Don Seiler writes:
> On Tue, Mar 17, 2020 at 8:56 AM Tom Lane wrote:
>> Yikes. Well, if there aren't obvious operational problems, it might be
>> that the data is actually UTF8-clean, or almost entirely so. Maybe you
>> could look at the problem as being one of va
wiped.
People have asked about this before, so maybe it'd be an idea to make
an explicit concept of a temp tablespace that only accepts temp tables,
and do whatever is needful to make that robust. But I've not heard of
any work towards that.
regards, tom lane
g reboot, but it's not an officially supported or tested scenario.
regards, tom lane
*is* meant for user variables:
https://www.postgresql.org/message-id/flat/cafj8prdy+m9ooxfo10r7j0pakccaum-tweatrdsrslgmb1v...@mail.gmail.com
I haven't checked on the state of that lately, but you might read up
on it and help review/test it, or try to push the definition in the
direction you need if it doesn't seem like quite the right thing.
regards, tom lane
nd to.
(I seem to recall some recent discussion about deprecating/removing
passwordcheck altogether, but I can't find it right now.)
regards, tom lane
rkload were actively hitting a lot
of them concurrently. It would work, for some value of "work",
but it wouldn't perform very well.
Also, as multiple people mentioned already, this still wouldn't
guarantee gap-free sequences of ID values.
regards, tom lane
but it's not something we'd be
likely to back-patch into existing releases.
regards, tom lane
[1] https://www.postgresql.org/message-id/1741.1584847383%40sss.pgh.pa.us
accident.)
Even if we did that, it would not automatically translate to downstream
packagers enabling the feature; they might not want the additional
dependencies.
So the right thing for you to do is to lobby Heroku to include PLV8
in their offering. You'd have to convince them to support it
ting your PG server start script to make sure the
mounted file system is present before you allow the server to start.
regards, tom lane
data is in,
you could use SQL_ASCII as the database "encoding" and thereby
disable all UTF8-specific behavior. Otherwise, maybe this conversion
is a good time to clean up the mess?
regards, tom lane
he closest Windows locale match, and then restore its contents
without using --create.
(I do agree that that message isn't the most helpful thing. It looks
like chklocale.c is overoptimistically assuming that what it's handed
is valid, even if GetLocaleInfoEx says it isn't.)
regards, tom lane
ale() take the same set of strings ...
regards, tom lane
ding. It's columns containing non-ASCII characters
that you'd want to worry about reindexing.
regards, tom lane
t; or "exit" won't get you out of the session.
Actually, since v11 that does work ... a concession we've made
to MySQL converts ;-)
regards, tom lane
t impossible when
RLS is active.
Perhaps arrayoverlap() itself could be proven leakproof, but the
underlying type-specific equality operator might or might not be.
We don't have enough infrastructure to handle indirect leakproofness
requirements like that, so you lose :-(
regards, tom lane
ish connecting. The "ps"
suggestion Adrian gave you would not show them either, because they're
not going to say "idle".
Enabling log_connections and watching the postmaster log would help
prove or disprove that theory.
regards, tom lane
st a single query, at least not when
there are many such queries per second.
I think pgbouncer and pgpool are the most widely used options,
but this is a bit outside my expertise.
regards, tom lane
he GUC (server
parameter) mechanism; what I just said about GUCs doesn't apply
to them.
regards, tom lane
pretty
unintelligible and inconsistent :-(. In your example, I think
the first-pass sort is on just the letters, and only if those are
the same will it consider the punctuation.
regards, tom lane
rt,
but there is nothing compelling the calling query to preserve
the ordering.
EXPLAIN would give you more info, but I'm betting that the IN is being
converted to a semijoin and then done with a non-order-preserving join
method.
regards, tom lane
g the constraint.
which, at least to my eyes, isn't very clear that SHARE ROW EXCLUSIVE
is the lock level used for *both* tables.
regards, tom lane
rely possible that some temp table took up too much disk
space, but ~250 rows in pg_namespace is not the cause of that problem.
regards, tom lane
catching problems at all?
Let alone in sufficient number to make them be on-by-default?
regards, tom lane
e these.
regression=> select to_regrole(quote_ident(session_user));
to_regrole
"dot.net"
(1 row)
> Is there other way (without extra type conversions) for getting oid of
> session_user?
select oid from pg_roles where rolname = session_user
regards, tom lane
rest row values and FACTOR is
NVE*(N–1) – floor(NVE*(N–1))
where NVE is the argument of percentile_cont and N is the number of rows.
(In SQL:2003, see 10.9 general rule 7)h)i).)
regards, tom lane
if the SIGTERM is coming from the
> "postgres: startup" process.
The startup process intentionally SIGTERMs the walreceiver under
various circumstances, so I'm not sure that there's any surprise
here. Have you checked the postmaster log?
regards, tom lane
x27;d suspect that the latter is happening.
regards, tom lane
uable state for us:
AFAICS, psql is behaving as documented. Why are you trying to override
HOST like that, instead of just using some other variable?
regards, tom lane
Radu Radutiu writes:
> Can you guide me how to debug postgresql crash?
A stack trace would be pretty useful.
https://wiki.postgresql.org/wiki/Generating_a_stack_trace_of_a_PostgreSQL_backend
regards, tom lane
;s doing according to pg_stat_activity? (If it's a reasonably
modern server, the wait-condition fields would be interesting.)
regards, tom lane
=?utf-8?Q?Paul_F=C3=B6rster?= writes:
>> On 27. Apr, 2020, at 14:20, Tom Lane wrote:
>> AFAICS, psql is behaving as documented. Why are you trying to override
>> HOST like that, instead of just using some other variable?
> I could but
> a) HOST is HOST and shou
Matthias Apitz writes:
> El día Montag, April 27, 2020 a las 08:40:04 -0400, Tom Lane escribió:
>> Can you get a stack trace from the connected backend?
> (gdb) bt
> #0 0x7fd567776000 in epoll_pwait () from /lib64/libc.so.6
> #1 0x0084476c in WaitEventSe
nges wouldn't
be a bad idea.
regards, tom lane
stem-dependent way. ..."
The "system-dependent way" is "adopt whatever the LANG/LC_foo environment
variables say at server startup", at least on non-Windows machines.
I think that C is the fallback if none of those variables are set, though.
Short answer is you shouldn't need to mess with these.
regards, tom lane
legrand legrand writes:
> Tom Lane-2 wrote
>> The hard part here is that you have to be really careful what you do in
>> a PG_CATCH block, because the only thing you know for sure about the
>> backend's state is that it's not good. Catalog fetches are right out,
&g
X is a good idea now, too.
(Likely the core setting is the same, but if it were pointing at a
different compiler that could cause trouble.)
regards, tom lane
party library then maybe I
> should post the errors output there and see what they have to say about
> it...
Yeah, the ultimate solution is clearly over on that side. These
last errors you've posted don't seem particularly Postgres-related.
regards, tom lane
mptoms like
that last fall [1].
regards, tom lane
[1] https://git.postgresql.org/gitweb/?p=postgresql.git&a=commitdiff&h=3887e9455
ht we'd fixed that hazard quite some
while back.
regards, tom lane
ow concerning the memory leak:
> That one was introduced with the work done on the GSSAPI encryption;
> it goes away when setting 'hostnogssenc' in pg_hba.
Oooh ... it looks like some of the encryption code paths have neglected
to call gss_release_buffer. Will fix, thanks for the report!
regards, tom lane
ve servers, and even a single server would
have issues executing a transaction from a not-logged-in session ---
but then where *do* we keep it, and how would an admin see or adjust the
state? It's a can of worms we don't really care to open, especially
when there are perfectly good solution
Matthias Apitz writes:
> El día lunes, abril 27, 2020 a las 09:40:39a. m. -0400, Tom Lane escribió:
>> If you're in a position to run a modified server, you could try
>> inserting a debug log message:
> I've added the printout of the length in this case and anothe
s. Problem is that it's quite difficult to get
the system to actually *use* a non-default conversion for anything really
significant, like say client I/O. I don't know that anyone's thought
hard about how to improve that.
regards, tom lane
there would be more people unhappy than
happy.
regards, tom lane
eaking consistently.
Without a concrete example it's hard to say, but maybe the issue is that
v12 is more aggressive about parallelizing restores --- see 548e50976.
regards, tom lane
xecutor improvements that have
been made since it went in. But it was clearly a win at the time.)
regards, tom lane
from the
socket and dump that --- probably a hex dump would be advisable,
because it'll contain \0 bytes. Seems like a good idea.
regards, tom lane
bit.
> Interestingly, the other side of this connection of the port 5432 is not
> visible, i.e. a 'lsof -P | grep 5432' does not show it in this moment.
Permissions problem maybe? I'm not sure that lsof will tell you much
about non-postgres-owned processes, unless you run it as root.
regards, tom lane
[ squint... ] That looks nothing like a Postgres-protocol exchange
to me. If it weren't for the runs of zeroes, I'd wonder if the
connection had SSL encryption turned on. Perhaps you captured the
wrong session?
regards, tom lane
ing 9.5 and 142.1MB
using 12. So there's half a meg or so of additional data in v12, but
certainly not gigabytes worth.
Are you trying to start both postmasters concurrently? Maybe you're
hitting some kernel limit on the total amount of shared memory in the
system.
regards, tom lane
g if you
set shared_memory_type = sysv?
regards, tom lane
Tory M Blue writes:
> That may be the next step in the lab, but was hoping someone knew of a
> significant difference.
I think we've made it perfectly clear that we don't. There's something
odd about your situation.
regards, tom lane
;s striking that this log shows a server ack of the INSERT, but no server
ack of the COMMIT. Maybe that's just an oversight in the ESQL/C logging
logic, but I wonder what's actually getting to the server. You might try
enabling log_statement = all so you can get a trace of what the server
thinks is happening.
regards, tom lane
RT 0 1
> i.e. have added the file name to the line number as "on line 1744 of
> swd_daten.pgc" to not always have to think, hey in which table we're
> with this at the moment.
Not an unreasonable suggestion, but it'd be more likely to happen if
you send in a patch ;-).
regards, tom lane
Matthias Apitz writes:
> El día Dienstag, Mai 12, 2020 a las 08:01:15 -0400, Tom Lane escribió:
>> Not an unreasonable suggestion, but it'd be more likely to happen if
>> you send in a patch ;-).
> as the first argument to ECPGdo() is of type int we can not do a hack
>
user mapping for a role. But I think you'll
find that sally et al have to do "SET ROLE foreignusers" to use it.
It's difficult to see a way to avoid that --- after all, if sally is
also a member of foreignuserstoo that also has a mapping, which one
should the system use?
tics this is asking for", so I'd be hesitant to let a tool think
that it can rearrange things like this.
regards, tom lane
Dmitry Igrishin writes:
> As you know, PostgreSQL has a large objects facility [1]. I'm curious
> are there real systems which are use this feature?
We get questions about it regularly, so yeah people use it.
regards, tom lane
ing here would only work if the header file's full path
is
/usr/local/opt/openssl/include/openssl/openssl/ssl.h
which doesn't seem likely.
regards, tom lane
o work.
regards, tom lane
regards, tom lane
n is that you'd get stale data, since
a matview is not going to be entirely up to date. It's no business of
the rewriter (or the query planner) to decide that such a tradeoff is OK.
I do recall some discussion of extensions attempting to do such things,
but I doubt we'd ever put it in core Postgres.
regards, tom lane
"Gavan Schneider" writes:
> HDRS=${HDRS}:"/usr/local/Cellar/openssl@1.1/1.1.1g/include"
> ...
> --with-includes=${HRDS}
If that's an accurate copy of your script, spelling HDRS correctly
would help.
regards, tom lane
-+---
2020-04-02T18:26:50.941531-03:00 | 2020-04-02 17:26:50.941531-04
(1 row)
Use of to_timestamp() to parse a bog-standard time format is a
classic antipattern IMO. It is inflexible, it doesn't detect
the errors you'd actually like it to detect, and it is harder
to type --- so why do people insist on doing it like that?
regards, tom lane
was to stop using to_timestamp altogether.
That would work fine on any Postgres version.
regards, tom lane
other than that, I'd expect the execution-time search path
to determine how a SQL function behaves.
Since Rob didn't provide any details, it's far from clear what's
going wrong for him.
regards, tom lane
;s only related to what
happens at execution if the search path is the same.
regards, tom lane
autovacuum kicks in.
You should *not* have had to do anything manual about this, unless you
have frobbed your autovac settings to the point of brokenness.
regards, tom lane
4-21') t2
USING (date)
WHERE t1.date >= '2019-04-21';
but of course that's even less easy :-(
regards, tom lane
nge that would prevent any one database from
completely consuming autovacuum's attention, even in wraparound-hazard
situations. Don't recall when.
Do you have an idea why autovac was failing to clear the issue on that one
problem table, though?
regards, tom lane
hackish way, and so there's no way to get rid of them without a table
rewrite.
regards, tom lane
Rob Sargent writes:
> Am I (again) alone in finding this a bit hokey? That a user name just
> happens to be a schema name ...
That's actually strongly encouraged by the SQL spec, if memory serves.
regards, tom lane
annot changed.
Then you might as well just rm -rf it (or whatever the equivalent Windows
incantation is). On Windows, that database is broken and useless.
regards, tom lane
ailable. LIKE, however, sees the "_" as a wildcard so it cannot
use an index and resorts to a seqscan --- which will work fine.
It's just index searches (and index-based sorts) that are broken.
Of course, if there isn't an index on the column in question
then this theory falls to the ground.
regards, tom lane
I think they are less alike than you hoped, because if they were alike,
you wouldn't be seeing this problem.
Possibly you could try running contrib/amcheck on the index in question
and see if it reports any issues.
regards, tom lane
he indexes that depend on it, so
it seems like a big overreaction.
regards, tom lane
nt platforms have
different ideas on fine points like how to sort a leading underscore.
Those things just aren't that well standardized.
regards, tom lane
m.
A good way to learn what to do is to see what psql does for its
various \d commands --- if you start it with the -E option you'll
see the underlying SQL it issues. It'll likely be more complicated
than you want, but you can strip away what's not useful for you.
regards, tom lane
yes; see thread.
The short answer here is that we aren't going to support such cases.
If you try to replicate across platforms, and it works, you're in luck.
If it doesn't work, you get to keep both pieces; we will not accept
that as a bug.
regards, tom lane
the composite type as
firstname citext, lastname citext, other-fields-here
and then the regular composite-type comparison rule would give you
approximately what you said you wanted ... but only approximately.
regards, tom lane
This'd be a bug in jdbc_fdw, and a
pretty bad one :-(. But you'd have to report it to the jdbc_fdw
author(s) --- the core Postgres project doesn't maintain that.
regards, tom lane
Gabriele Bulfon writes:
> Amazing! Rebuilt without -O and it worked like a charm!
Yeah, modern compilers tend to apply optimizations that break old versions
of Postgres. -O0 usually takes care of it.
regards, tom lane
he postmaster can deal with other approaches to
setting up an external config file.)
regards, tom lane
local user create/delete his
own foreign tables, then what you could do is make sure the remote user
ID's password is useless for any purpose except connecting from the
source database. One way to do that is to adjust the remote DB's
pg_hba.conf to disallow the remote user ID from connecting from
anyplace except the local database server.
regards, tom lane
d them in the newest released branch. (So for
example the above is from the v10 branch; v11 was not yet released
so it had no release note for this.)
As Adrian mentions, grepping the result of "git log" is also a
good way to find relevant commits.
regards, tom lane
Guyren Howe writes:
> Is it practical to provide the SQL Server-like feature in Postgres?
No.
regards, tom lane
t;-' isn't
one. (The rules there probably look a bit bizarre, but the intention
is to ensure that operators found in the SQL spec can be parsed without
requiring spaces between them.)
regards, tom lane
Did you make a note of the
cost estimates for the different plans?
regards, tom lane
Adrian Klaver writes:
> On 6/4/20 9:43 AM, Tom Lane wrote:
>> It's possible that the index had bloated to the point where the planner
>> thought it was cheaper to use a seqscan. Did you make a note of the
>> cost estimates for the different plans?
> I missed the p
libraries I need to include in my download for
> this to work on a non-networked server?
Are you using the right install tool? "rpm -i" shouldn't result in any
nonlocal accesses. Tools like yum or dnf will, because they're meant to
fetch from nonlocal repositories.
regards, tom lane
addition to an rpm named just postgresql-NNN you need
postgresql-server-NNN, and maybe some other bits.
regards, tom lane
es because that's
what they think the RHEL distribution ought to be. The main problem
from your perspective is the risk of confusion with the libraries that
community PG11 RPMs will bring in. You might try a test deinstallation
of that RPM first, and see if it cascades to removing anything you can't
live without.
regards, tom lane
Indeed it does not, just as the on-disk format for it does not. The
representation is effectively always in UTC. If you have some other
timezone setting selected, timestamptz_out rotates to that zone for
display purposes ... but the binary format doesn't.
regards, tom lane
eval_const_expressions(), which is
applied to all expressions. Possibly prepqual.c's canonicalize_qual()
would be a better place.
The real problem here is going to be objection #2. The rules under
which any optimization could be applied are nontrivial, so that we'd
spend quite a bit of time trying to figure out whether the optimization
applies ... and I'm afraid that most of the time it would not.
regards, tom lane
sting
database that pg_restore can connect to for long enough to issue the
CREATE DATABASE.
You can't mix-and-match these approaches.
regards, tom lane
601 - 700 of 2935 matches
Mail list logo
