long as you make no DDL changes in the database, but
as soon as you do, all bets are off.
regards, tom lane
smallint = text"
error, but I bet your database tries to execute it.
regards, tom lane
t; LEFTARG = public.i32,
> RIGHTARG = text
> );
... so, what do those functions look like? And, since there's evidently a
custom type or domain involved, what is i32 exactly?
In short: you have completely failed to provide a self-contained test
case.
regards, tom lane
een like this for years.
regards, tom lane
bit weird perhaps, since \d seems like a "do-something"
command rather than a query buffer editing command. But
psql uses the same rules for both cases.
regards, tom lane
g,
although it's possible the delay is before the new session has made
any entries there.
Also, obtaining stack traces from a few of the stuck processes would
likely be quite informative.
regards, tom lane
arent is why there is so much activity as to block them
from doing so for a significant amount of time. We can guess that
the "worker processes" you mentioned are ganging up on that lock
because they need to compute query snapshots, but that still doesn't
seem like enough of an explanation.
Can you show us exactly what the "worker processes" are doing while
this is going on?
regards, tom lane
re but I think we support cascaded replication,
so that you could reduce the replication load on the primary just
by reconfiguring some of the standbys to pull from other ones
not directly from the primary.
regards, tom lane
> the join resulting in this bogus id = id condition, but I still curious
> about where this estimate change comes from.
It's an intentional v11 change, cf
https://git.postgresql.org/gitweb/?p=postgresql.git&a=commitdiff&h=8ec5429e2
regards, tom lane
need another provider. But on most systems I'd think you could use ulimit
or the like even if you don't have root privileges.
regards, tom lane
the toast table, but there's
a nontrivial risk of permanently hosing your database by messing that
up.
regards, tom lane
t by changing a GUC, though. It'd be better for the policy
to check something like role membership.
regards, tom lane
lean) | I/O
pg_proc | function byteain(cstring) | I/O
(5 rows)
Alternately, locutions like "where classoid = 'pg_proc'::regclass"
might be helpful.
regards, tom lane
have good
checks for, is that unless these are different builds of the same
version of the same operating system, the two platforms may not sort
strings the same way; resulting in all your text indexes being
corrupt. You can recover from that by reindexing, but it's hardly
a painless transition.
regards, tom lane
line gets it.
> This is the same for all heavyweight locks in PostgreSQL.
There is an exception: the queue order will be rearranged if we find
that doing so is necessary to avoid a deadlock failure. See
src/backend/storage/lmgr/README
regards, tom lane
ssue.
It looks like send() itself is returning EACCES, which seems just
weird. The send(2) man page does cite some possible causes of
EACCES, but none of them seem relevant here. I think you might
need a kernel guru.
regards, tom lane
would be
quite a bit less: in this query, we are re-descending pk_oms_rec
from the root, 1003394 times, which is a lot of cycles that wouldn't
be needed with a single scan on a timestamp index.
regards, tom lane
that you can capture
the actual query plan used when the application executes this query.
regards, tom lane
ure about exactly when the snapshot
is taken for a deferred trigger.
regards, tom lane
ately after
insertion, but if the idea is to sanitize every so often, it'd help.
> Is there a way to access these values by connecting to a PostgreSQL
> server instead of analyzing in-memory or on-disk data ?
SELECT xmin, ... FROM votes;
regards, tom lane
Alvaro Herrera writes:
> On 2020-Sep-02, Tom Lane wrote:
>> See VACUUM FREEZE. You couldn't hide connections immediately after
>> insertion, but if the idea is to sanitize every so often, it'd help.
> Starting with 9.4 which introduced the use of HEAP_XMIN_FROZEN
7;t do it with a window function over the "run" window because
no window function ever looks outside the current partition. But
that's easy to fix by using a different window definition. The
planner is smart enough to see that these windows are compatible
and only need one sort to be p
ths_to_append_rel
entirely when there's exactly one surviving child rel, and make it
just use all the surviving paths for that child.
regards, tom lane
row could be removed. But we haven't seen any
evidence of that so far. The basic fact that A's snapshot is limiting
removal of rows from a table it has not touched is not a bug.
regards, tom lane
Magnus Hagander writes:
> On Tue, Sep 8, 2020 at 4:38 PM Tom Lane wrote:
>> The reason that's not so is that whether or not transaction A *has*
>> touched table B is irrelevant. It *could* read table B at any moment,
>> for all autovacuum knows. Therefore we cann
ng set that doesn't
include the "path" item.
I haven't gone through the results one-by-one, but just by eyeball
I think this is sufficient to explain the discrepancies.
(I note that the SQL standard only allows GROUP BY items to be
simple column references. Maybe that's not an arbitrary restriction
but is meant to forestall this sort of ambiguity? Hard to be sure.)
regards, tom lane
(level1),
> ()
> )
> ORDER BY 1, 2, 3, 4;
Yeah, that one looks a lot safer from here. There's no question about
which expressions are supposed to match what. It should end up with
the same plan, too.
regards, tom lane
e casts.
> QUERY: SELECT JSONB_INSERT(_user, '{uid}', _uid)
> CONTEXT: PL/pgSQL function words_get_user(jsonb) line 44 at assignment
I think it'd work to do
JSONB_INSERT(_user, '{uid}', to_jsonb(_uid));
The third argument has to be jsonb, not something else.
regards, tom lane
across platforms or PG versions, and there's a
fair amount of just plain different opinions. But I think you may be
overcomplicating it. IMO there's not that much you have to adjust to
start with --- maybe just increase shared_buffers and possibly work_mem
--- and then tweak other settings only when you find yourself running into
that limit. If you can figure out our logging settings then you can
figure out the rest of this, too.
regards, tom lane
raf writes:
> On Mon, Sep 14, 2020 at 05:39:57PM -0400, Tom Lane wrote:
>> On the other hand, the very same thing could be said of database names
>> and role names, yet we have never worried much about whether those were
>> encoding-safe when viewed from databases with dif
reak over time is
"start the server with the parameters you want, and look to
see how big the shmem segment is".
We used to have an approximate formula in the documentation,
but we took it out years ago because it was constantly out of date.
regards, tom lane
application.
In some cases it might help to restart your sessions when they get too
big, but that seems like at best a band-aid.
regards, tom lane
ould be sufficient to explain the inconsistency.
If I had to bet I'd suspect that the extra cast is blocking use of an
index on wsft.
regards, tom lane
Bruce Momjian writes:
> On Mon, Sep 14, 2020 at 05:39:57PM -0400, Tom Lane wrote:
>> On the other hand, the very same thing could be said of database names
>> and role names, yet we have never worried much about whether those were
>> encoding-safe when viewed from dat
ed.
The short answer to all these concerns is "after a SIGHUP, look in the
postmaster log to see if there were any complaints".
regards, tom lane
. If the user is a member of two groups, each of which
has a mapping for that server, how could the server choose one?
regards, tom lane
owever, I don't understand how "drop extension plpythonu"
worked for you, given your previous query showing that
that extension wasn't installed.
regards, tom lane
regards, tom lane
=?utf-8?Q?Paul_F=C3=B6rster?= writes:
> On 26. Sep, 2020, at 16:07, Tom Lane wrote:
>> However, I don't understand how "drop extension plpythonu"
>> worked for you, given your previous query showing that
>> that extension wasn't installed.
> j
0 | 2020-09-27 18:32:19.321202
US/Central
US/Central | 2020-09-27 23:32:19.321202+00 | 2020-09-27 18:32:19.321202
US/Central
(4 rows)
The key thing to understand here is that AT TIME ZONE either
rotates from local time to UTC, or vice versa, depending on
whether its input is timestamp or timestamptz.
regards, tom lane
t is, is there a
> particular pg_internal.init file that needs to be removed, or just
> remove all pg_internal.init that can be found?
I'm a bit dubious that that'd actually help, but it's perfectly safe
if you want to try it. pg_internal.init is just a cache file that
will be rebuilt if it's missing.
regards, tom lane
Reid Thompson writes:
> On Mon, 2020-09-28 at 12:15 -0400, Tom Lane wrote:
>> I'm a bit dubious that that'd actually help, but it's perfectly safe
>> if you want to try it. pg_internal.init is just a cache file that
>> will be rebuilt if it's missing.
estaurant business
would surely find the above pretty laughable.)
regards, tom lane
situation when, say, a column of that type is on the nullable
side of an outer join. We allow such constraints, but they will be
nominally violated in cases like that.
regards, tom lane
Joe Abbate writes:
> On 28/9/20 17:25, Tom Lane wrote:
>> Domain-over-composite might be a slightly simpler answer than your first
>> one. It's only available in relatively late-model PG, and I'm not sure
>> about its performance relative to your other design,
ol around with the
dynamic linker's configuration files. "man ld.so" will get you started.
regards, tom lane
ce is that the dynamic linker has its own idea of how to resolve
the library references at runtime. (ldd just reports on what the
dynamic linker would do; there's no trace in the executable file of
exactly which copy of a shlib was linked against.)
regards, tom lane
shadow a real table is not one.)
If you really really need to do this, I'd counsel using EXECUTE to
ensure no caching happens. But I concur with Michael that it's
fundamentally a bad idea.
regards, tom lane
esn't know how to interpret those bits
anymore.
So the short answer is you can't have that. Find another way to design
your application.
regards, tom lane
u could also get this if the "public" schema is not readable
by Idempiere's userid, but that doesn't seem terribly likely.
regards, tom lane
"James B. Byrne" writes:
> On Fri, October 2, 2020 18:46, Tom Lane wrote:
>> The two likely possibilities are that Idempiere isn't connecting to the
>> same database as you are doing manually, or that it is using a search_path
>> setting that doesn't in
ng error:
> ERROR: current transaction is aborted, commands ignored until end of
> transaction block
This has nothing to do with the current command, but with failure
of some previous command in the transaction.
regards, tom lane
rror.
However, that logic hasn't changed in decades, and we've not heard
complaints about it before. Are you starting the server in some
unusual way?
regards, tom lane
ruser. I sure
hope you are not letting your application do that.
regards, tom lane
curity practice.
(If the tutorial actually told you to do that, the tutorial's author
is utterly clueless.)
regards, tom lane
"James B. Byrne" writes:
> On Mon, October 5, 2020 10:53, Tom Lane wrote:
>> I continue to suspect that you are somehow
>> confusing yourself by testing in different databases and/or
>> with different user accounts.
> Possibly. I do not make any definitive c
ing catalog,
which is the most likely source of a different search_path for
different connections.
Another line of thought is maybe you have a ~/.psqlrc that's
altering the search_path setting.
regards, tom lane
ity standpoint.
BTW, you might also be well advised to include "IN DATABASE",
to restrict the effects to databases in which
the adempiere schema actually exists.
regards, tom lane
t
the OP's argument. It looks to me like the second-byte code space is
already pretty full in both encodings.
regards, tom lane
"systemctl disable".
regards, tom lane
cs, it seems like the thing to do would be
to add something to the head text in 9.23. Subquery Expressions, and then
remove any duplicative statements from the individual 9.23.x subsections.
regards, tom lane
ces entirely.
(I'm being fairly brief here, but this has all been litigated multiple
times before. See the archives.)
regards, tom lane
gs where
name = 'shared_buffers';
ERROR: invalid size: "16384 8kB"
DETAIL: Invalid size unit: "8kB".
HINT: Valid units are "bytes", "kB", "MB", "GB", and "TB".
Maybe we should teach pg_size_bytes to cope with that.
regards, tom lane
Magnus Hagander writes:
> On Wed, Oct 14, 2020 at 5:10 PM Tom Lane wrote:
>> It's fairly annoying that this doesn't work:
>> regression=# select pg_size_bytes(setting||' '||unit) from pg_settings
>> where name = 'shared_buffers';
> Actually
Igor Korot writes:
> Configure succeeded, but running "make" failed with
> [quote]
> make: Fatal error in reader ../../../src/Makefile.global, line 45:
> Unexpected end of line seen
> [/quote]
Kinda looks like you're using some non-GNU make.
regards, tom lane
Igor Korot writes:
> On Thu, Oct 15, 2020 at 12:01 AM Tom Lane wrote:
>> Kinda looks like you're using some non-GNU make.
> Correct.
> It is from Solaris Studio compiler.
> What should I do?
Try "gmake". If it's not already on
explicit cast,
which the latter lacks, but the end result will be the same
because the parser will coerce the DEFAULT expression to the
column's type anyway.
(It helps to know that for reasons lost in the depths of time,
Postgres' internal name for the char(N) type is "bpchar".)
regards, tom lane
snprintf.
The way to get this to work as Celso wishes would be to count
characters and then do his own arithmetic about how much padding
to add.
regards, tom lane
in. I do not
think you're going to get any exciting results that way though ...
as create_plan() notes, the exact spot where an initplan is attached
to the tree isn't terribly relevant.
regards, tom lane
ng minor useful functions such as these.
Part of the reason for that bias is that these one-off functions tend
not to be very well thought out or complete :-(. The point that
could be raised here is why we have split_part but not any corresponding
regex-based splitter.
regards, tom lane
ferences > Paths > Binary Paths for "PostgreSQL
> Binary Path" but that doesn't fix the issue, even after a pgadmin4 restart.
AFAIK that's only likely to help when pgadmin invokes pg_dump or
some other tool, not for its own connections to the server.
regards, tom lane
Neil writes:
> On Oct 27, 2020, at 12:23 PM, Tom Lane wrote:
>> A quick look through our source code finds that error string only in
>> libpq; it indicates that libpq was built without GSSAPI support.
> On my Mac pgadmin4 seems to use its own libpq.
> You can find it at:
=?UTF-8?Q?Eudald_Valc=C3=A0rcel_Lacasa?= writes:
> I've run the automated script several times, and the duration of the
> query is widely variable.
Interesting. You might try using auto_explain to log the query plans
and see if the plan is changing.
regards, tom lane
S version of pgadmin4 support GSSAPI?
You'd have to pester the pgadmin folk about that.
regards, tom lane
k that you're telling us the whole truth about
how your colleague is running pg_dump and/or pg_restore. There
shouldn't be any "CREATE SCHEMA public" issued if you didn't say -c.
regards, tom lane
> and I don't know where else to look for the reason. What am I missing
> seeing?
First thought is that you might need another right parenthesis there.
regards, tom lane
null constraint.
> Does this happen in newer versions than the 12.2 installed here?
That seems a bit odd. You're doing this in psql? Can you show
an exact example where the error report goes missing?
regards, tom lane
David Gauthier writes:
> Next question, how does one actually replace the thing ?
> replace(thestring,0x2026,'...')
> ... isn't going to fly.
If you don't want to write the actual UTF8 character, maybe the chr()
function would suit you better [1].
if any of those are showing up in
the postmaster log.
Seems like maybe it wasn't a great idea for _dosmaperr's fallback
errno to be something that is also a real error code.
regards, tom lane
would break
any easy solution.
regards, tom lane
out to be broken, you could waste
many hours figuring that out.
regards, tom lane
Igor Korot writes:
> ld: fatal: file ../postgresql/src/interfaces/libpq/libpq.so: wrong ELF
> class: ELFCLASS32
That path doesn't seem to quite agree with this one:
> igor@solaris:~/dbhandlerSol/libpq/src/interfaces/libpq$ file libpq.so
regards, tom lane
g of the query seems to be non-parallelizable, but the
row_number() result is still pretty indeterminate; it just doesn't
happen to have changed within your test run.
What is it you are expecting to get out of including a fictional
row number in the query result, anyway?
regards, tom lane
ostnames
(that is, "-h host1,host2" or the equivalent). That should work for
any libpq-based client.
regards, tom lane
even section 9.3 (mathematical
functions) has a lot of functions that need a sentence or two. We used
to either omit important details for such functions or stick them in
footnotes, and neither of those options is very nice.
regards, tom lane
fix under the old format;
here's one:
https://www.postgresql.org/message-id/flat/158110996889.1089.4224139874633222837%40wrigleys.postgresql.org
regards, tom lane
t the time you made this backup, you would likely see
the same message at the end of its crash recovery. Some sort of
corrupt-WAL-entry report is expected at the end of WAL replay anytime
you didn't have a clean shutdown.
regards, tom lane
t; database? Seems unlikely,
but you might try confirming with "ps auxww | grep post" or the like.
I also wonder if the cluster you're trying to upgrade from has a
"template1" database. Not sure if anyone has ever tested whether
pg_upgrade can cope with the lack of one.
regards, tom lane
n, etc?
regards, tom lane
y and large, we do not use the types in Postgres, and are
unlikely to start doing so. So this omission doesn't particularly
concern me. "ll" with a cast to "long long" is indeed the recommended
practice if you want to print a 64-bit value.
regards, tom lane
eated but
then we can't access it.
Are you by any chance trying to preload any of the postgis-related
extensions? If so, try not doing that.
regards, tom lane
er"
issue. (I assume that dropping postgis from the source DB is not
an option...)
regards, tom lane
PostgreSQL 13 documentation
> page about partitioning. May be this statement is in another page?
It's in the CREATE TABLE reference page. Seems like it would be a good
idea to have it also in ddl.sgml's discussion of partitioning, though.
regards, tom lane
Morris de Oryx writes:
> And here's the error that I get back:
> ERROR: could not find tuple for statistics object 147574.
Can you give a self-contained recipe for triggering this?
regards, tom lane
y explain what I'm
> seeing?
Ah, yeah, it likely would.
If this isn't a throwaway database, what you'd have to do to clear the
errors is to find and remove the now-dangling links to the deleted objects
in pg_depend.
regards, tom lane
Dennis Jacobfeuerborn writes:
> On 11/13/20 4:02 PM, Tom Lane wrote:
>> This looks quite normal to me. If you'd pulled the power plug on the
>> primary system at the time you made this backup, you would likely see
>> the same message at the end of its crash recovery. S
essary (on modern platforms
anyway) or a good idea (if we're not using , this seems pretty
much guaranteed to break things); so I think the rest of that patch is
foolhardy.
regards, tom lane
Laurenz Albe writes:
> On Mon, 2020-11-16 at 12:30 -0500, Tom Lane wrote:
>> In this case, I see one use of the constant TRUE in collationcmds.c,
>> but I wonder how come that's there given that we deprecated upper-case
>> TRUE some time ago. I find it hard to believe
hink we should just s/TRUE/true/ and be done with it.
regards, tom lane
I wrote:
> What's wrong with s/TRUE/true/ in get_icu_language_tag?
I confirmed that that fixes the build with ICU 68.1, and pushed it.
regards, tom lane
801 - 900 of 2962 matches
Mail list logo
