cal.html#SQL-SYNTAX-CONSTANTS
regards, tom lane
in an UNLOGGED table? If so, resetting
it to empty after a crash is exactly what's supposed to happen. The
entire point of UNLOGGED is that the performance benefits come at the
cost of losing the data on crash.
regards, tom lane
id with the info you've provided. But I'd be thinking about
"how do I clean up the corruption and prevent a recurrence", not
"I need to increase memory settings".
regards, tom lane
at have you got extra_float_digits set to?
regards, tom lane
My guess is that whichever catalog it is is badly bloated.
regards, tom lane
rhaps not as severe.
regards, tom lane
l to think of varchar as being a domain over text, though
for various reasons it's not implemented quite that way.
regards, tom lane
Anand Sowmithiran writes:
> This is very helpful to know , we can likely count on temporal to be part
> of PG 15 !!
You were just told *not* to count on that. Maybe it'll happen,
but I wouldn't take bets on it.
regards, tom lane
t". Maybe it'd be
a better idea to apply default_transaction_read_only to particular
roles (and not run pg_restore under such a role).
regards, tom lane
that useful as a means of disabling writes.)
regards, tom lane
dresses so that it's
not listening on an IPv6 address at all. There's not
going to be much point in that if you don't want
to put IPv6 entries into pg_hba.conf.
regards, tom lane
at it's expensive.
My recollection is that the amount of parallelism it goes for is partly
predicated on the estimated query cost.
regards, tom lane
ber is quite *that* expensive,
but if you are expecting equivalent results from these two queries,
you're simply wrong.
regards, tom lane
e. The community's mail archives are at
https://www.postgresql.org/list/
regards, tom lane
putting it last if there are
no other relevant considerations. However, if you need a particular
column order to match query requirements, that's certainly going
to be a more important consideration.
regards, tom lane
ee with the
ORDER BY you want to use, in either case.
regards, tom lane
up and glibc
are not using the same DNS search path. Traditionally that would be
set by a "search" line in /etc/resolv.conf, but ghod knows how it's
determined under systemd-resolved.
regards, tom lane
ed to
serial-ness at all, it's just the normal behavior of regclass_out for the
OID constant that's the argument of nextval().
regards, tom lane
he server running
> on host "localhost" (127.0.0.1) and accepting TCP/IP connections on port
> 5432?"
So the step you missed is "start the Postgres server". On OSX
that's usually done by setting up a LaunchDaemon script, IIRC
(it's been awhile since I messed with that).
regards, tom lane
"Peter J. Holzer" writes:
> On 2021-06-23 20:33:33 -0400, Tom Lane wrote:
>> It's quite odd that nslookup isn't agreeing with glibc's name
>> resolution code.
> AFAIK nslookup uses only DNS. Glibc uses all methods in nsswitch.conf.
Ah, right. So lo
ntermediate functions.)
regards, tom lane
elements; let alone whether inputs sharing the
same elements should be considered "equal". For example, ARRAY[1,2]
and ARRAY[2,1] would give rise to identical sets of index entries in
a GIN array_ops index.
In short, no, this isn't something you do with a GIN index.
regards, tom lane
g_dump hasn't relied on adsrc since PG 7.2.
regards, tom lane
consider
set client_min_messages to error;
regards, tom lane
index on the
referencing column? I've not looked at how this particular case
is implemented, but typically, lack of such an index is fine
until you try to delete PK-side rows.
regards, tom lane
fractions, that
would point to something different in your VACUUM housekeeping on
the two systems.
regards, tom lane
Ron writes:
> On 6/29/21 11:42 AM, Tom Lane wrote:
>> If there's a significant difference in relallvisible fractions, that
>> would point to something different in your VACUUM housekeeping on
>> the two systems.
> Prod is brand new. Loaded on Saturday; we saw
/extern/extern PGDLLIMPORT/g has been discussed
and rejected, because we don't want to commit to supporting absolutely
every global variable as something that's okay for extensions to touch.
So if you've got specific proposals (such as "Mode"), bring them up
on pgsql-hackers.
regards, tom lane
t the EXPLAIN half a dozen times
to see if the plancache switches from a custom to a generic
plan. (In recent PG releases, changing plan_cache_mode
is another way to check what happens.)
regards, tom lane
y causing
the WHERE clause to not match your index. What's the actual type
of the igroupid column?
regards, tom lane
/git.postgresql.org/gitweb/?p=postgresql.git&a=commitdiff&h=17958972f
regards, tom lane
t it looks like a messy project
with an ugly final result :-(, so nothing's been done yet.
I don't think there's any good solution right now. You could perhaps
put the iprange extension in pg_catalog not public, so that it's always
in the search path. I don't recall right now if that has any downsides.
regards, tom lane
r to provide a restore-time
option saying "use this search_path"? It needs some thought, not
just quick-n-dirty code.
regards, tom lane
search_path;
So the problem is not lack of a server feature, it's persuading pg_dump
to emit something other than what it does now.
regards, tom lane
he former restriction was the surprising thing, and
the current behavior is simply what one would expect from assembling
those parts in that order.
regards, tom lane
d by a
failed transaction would be removed during transaction cleanup, but we
did not reach that code. So these were left behind, but the table's
original files in the original tablespace should be undamaged.
regards, tom lane
7;t think anyone's entirely
happy about the current factorization of those parts of the manual;
but it's not entirely clear how to make it better, either.
regards, tom lane
ction
> phrase and want now to learn why it's there. Probably needed to concatenate
> separate names?
AFAICS this is invoking a prefix operator named "&". There is no such
operator built into Postgres. Maybe psql's "\do+ &" would jog your
memory about where yours came from.
regards, tom lane
lp you debug that, but I think
it only works on queries that do eventually complete. You might need
to investigate by altering your application to capture "EXPLAIN ..."
output just before the troublesome query, so you can see if it gets
a different plan in the slow cases.
regards, tom lane
TE
> DATABASE over and over again?
It's not a bug. I suppose in a perfect world the stats would
automatically be up to date all the time, but in the real world
it seems like the cost of that would be exorbitant.
regards, tom lane
trings, booleans) are valid JSON values. I see though that it
says
A JSON text is a serialized value. Note that certain previous
specifications of JSON constrained a JSON text to be an object or an
array.
so apparently Oracle is following some obsolete version of the spec.
regards, tom lane
1159IN TXT "v=spf1 ip4:50.126.108.78 -all"
appl-ecosys.com.1159IN TXT "v=spf2.0/pra ?all"
Is it possible that you're sending the list request mail out of some
other IP address?
regards, tom lane
regards, tom lane
load is. But we've seen bloat problems in
indexes where, say, every tenth or hundredth value in the index ordering
would persist for a long time while the ones in between get deleted
quickly. That leads to low-density indexes that VACUUM can't do anything
about.
regards, tom lane
deal with duplicate join keys in its
outer input. There must be a heck of a lot of duplicates. The planner
would typically avoid using merge join if it knew that, so I'm wondering
if you have up-to-date statistics for the outer side of the join.
regards, tom lane
time=0.049..121.238 rows=150448 loops=1)
> Filter:
> (display_type IS NULL)
looks like it's really hurting you, and "ANALYZE account_invoice_line"
after loading that table ought to be enough to fix that.
regards, tom lane
... see
https://www.postgresql.org/docs/current/xfunc-sql.html#XFUNC-SQL-FUNCTIONS-RETURNING-SET
In particular, the NOTE at the bottom of that section explains that
the behavior changed in v10.
regards, tom lane
es not long ago:
https://wiki.postgresql.org/wiki/Locale_data_changes
At one time we thought that migrating to ICU sorting might bring
a little more stability to this, but I think what we've found so
far is that it's just different :-(
regards, tom lane
eproduce your problem and failed; the attached script
acts as I'd expect. So there must be some moving part you've not
mentioned. Can yo create a similar self-contained example that
fails?
regards, tom lane
drop table if exists pt, c1, c2;
create table pt (id int pri
---
["2021-08-02 00:00:00","2021-08-04 00:00:00"]
["2021-08-07 00:00:00","2021-08-09 00:00:00")
(2 rows)
regards, tom lane
to consult. So I'm not sure that focusing on ANALYZE's
usage in isolation is a helpful way to think about this. If you can't
afford the amount of memory needed to run ANALYZE, you won't like the
downstream behavior either.
regards, tom lane
t recent call last):
File "", line 1, in
ModuleNotFoundError: No module named 'z'
Now it's possible that the wording didn't change exactly at the 2/3
boundary, but I doubt it. So it looks to me like the alleged plpython3u
language is actually invoking python 2.something, which is unlikely
to work well at all.
regards, tom lane
uld also be useful.
regards, tom lane
function is not volatile, and you're using a moderately recent PG
version, I'd expect the planner to do that for you.
regards, tom lane
dy demonstrated in this thread.
regards, tom lane
up", which should include the dump
file's version as well as the source pg_dump's version.
regards, tom lane
you tried running the restore without the -j option?
regards, tom lane
aren't readable, so maybe the true situation is that
it's finding files by those names but they aren't the right ones.
In any case, you generally want to put absolute pathnames into these
connection parameters.
regards, tom lane
efault: "tgl")
In any case, these choices of default have stood for a very long
time and we're unlikely to consider changing them. If (some parts
of) the docs are inaccurate we should change the docs.
regards, tom lane
ts to do. Check the
system-wide OpenSSL configuration on each end, and update OpenSSL
if necessary. At least with reasonably modern OpenSSL, you should
be able to enforce a minimum TLS version in OpenSSL's config
(see MinProtocol).
regards, tom lane
. */ comments for the purpose.
regards, tom lane
ng else, like say the
machine's external IP address, that could be your issue.
regards, tom lane
acket filter (i.e.
software firewall) that is not passing traffic for 5432.
It's not very clear how it worked before if that were in place
previously, but since you've said zero about what the working
configuration looked like, that's the best I've got.
regards, tom lane
ow such traffic from localhost is less certain,
but the symptoms you're showing sure look like yours doesn't.
Saying you haven't touched that configuration doesn't excuse
you from investigating it.
regards, tom lane
too late. We'd need to count the fields
*before* trying to assign values, not after.
In the meantime, it does seem like the docs could be more explicit
about this, and perhaps give an example showing the (x).* solution.
regards, tom lane
you.
Not sure about other Linux variants.
regards, tom lane
ourdiaspora writes:
> Installed 'nftables'.
If you didn't have nftables installed already, then it's likely that
packet filtering is being controlled by some other userland API.
Can't help you much on what that is.
regards, tom lane
o multiple transactions that process fewer tables
per transaction?
regards, tom lane
asically all parameters that affect what is logged
are superuser-only, and it'd be a hard sell to weaken that. The
SECURITY DEFINER function approach is your best bet for poking local
exceptions into that policy.
regards, tom lane
ements.html
Actually, for that specific requirement, there's an easier way:
ALTER USER target_user SET log_statement = 'all';
While the target_user can't do that for himself, a superuser
can.
regards, tom lane
ike your data is a completely disorganized mess :-(.
You might be able to bring some semblance of coherence to it with
an extension like postgresql-unit [1], but it will take a lot of
effort to get the data into a representation that can sort reasonably.
There's no "easy button" here.
on-GSS connection upon receiving
this error response. But ...
3. Something --- it's not very clear what --- is seeing the error
and going into an unwarranted panic.
I'd try to figure out what's issuing the "Disabling all sessions"
message and then filing a complaint with the authors of that.
regards, tom lane
to change that, for both
performance and risk-of-circularity reasons.
Note that built-in is not the same as internal --- you could potentially
make a new internal-language pg_proc entry pointing at some existing
built-in function, and then calls using that could get hooked.
regards, tom lane
- GENERATED is supposed to be immutable, and there's about 0%
chance that anything involving a subquery or window function would
really be immutable. I think there are implementation issues too,
but they're not worth getting into given that point.
regards, tom lane
ECT.
Would we be willing to go to the trouble of adding such a clause to the
syntax? I dunno; it'd certainly enlarge the footprint of a patch for
this by a lot.
regards, tom lane
g the pg_hba.conf file.
Either that or revoke public CONNECT privilege on the database.
regards, tom lane
ry to use the max() aggregate function it throws an
> error.
The best way is usually like
select * from mytable order by contact_date desc limit 1;
If you have an index on contact_date this should work very well indeed.
regards, tom lane
ed by another column. Not both...
The reason for that restriction is that the case you propose is
ill-defined. If we combine rows with the same col_x, which row's
value of col_y is to be used to sort the merged row? I think once
you answer that question, a suitable query will suggest itself.
rid of one dup at a time, say by
str := regexp_replace(str, '([^,]+)(,\1)?($|,)', '\1\3', 'g');
and repeat till the string doesn't get any shorter.
I did come across a performance bug [1] while poking at this, but
alas fixing it doesn't move the needle
"Li EF Zhang" writes:
> Since pg13 support trusted extension, so I changed control file of bloom and
> make it trusted.
The fact that you can edit the file that way doesn't make it a supported
case.
regards, tom lane
will consume all the a's in one go.
"a*" is easy. "(a*)\1" is less easy --- if you let the a* consume the
whole string, you will not get a match, even though one is possible.
In general, backrefs create a mess in what would otherwise be a pretty
straightforward concept :-(.
regards, tom lane
"David G. Johnston" writes:
> On Fri, Aug 20, 2021 at 6:26 AM Tom Lane wrote:
>> "Li EF Zhang" writes:
>>> Since pg13 support trusted extension, so I changed control file of bloom
>>> and make it trusted.
>> The fact that you can edit
the user requesting the install to own the
individual objects within the extension.
regards, tom lane
f that it's OK today, innocent changes
to the shared infrastructure could break the leakproofness tomorrow.
regards, tom lane
ats at once, and cache them
> in pg_dump? Or at the very least reuse already received information?
Send a patch ...
regards, tom lane
hubert depesz lubaczewski writes:
> On Thu, Aug 26, 2021 at 10:02:07AM -0400, Tom Lane wrote:
>> hubert depesz lubaczewski writes:
>>> Wouldn't it be possible to get all type formats at once, and cache them
>>> in pg_dump? Or at the very least reuse already receiv
e fact that it relies
on user-controllable definitions seems to me to make it almost
certainly unsafe to be leakproof.
regards, tom lane
ess.)
> This is with pg 11 and 12 on fedora 34
Looking at the "hosts" entry in /etc/nsswitch.conf might help figure out
exactly what's going on, but I'll bet a nickel that this is some
unhelpful systemd behavior.
regards, tom lane
timestamped log entries though.
Yeah, turn on log_statement = all on the server and watch what pg_dump
is doing that way.
regards, tom lane
e detecting any net
performance change.
(This is not meant for commit as-is; notably, I didn't bother to fix
getTypes' code paths for pre-9.6 servers. It should be fine for
performance testing though.)
regards, tom lane
diff --git a/src/bin/pg_dump/pg_dump
Stephen Frost writes:
> * Tom Lane (t...@sss.pgh.pa.us) wrote:
>> I experimented with the attached, very quick-n-dirty patch to collect
>> format_type results during the initial scan of pg_type, instead. On the
>> regression database in HEAD, it reduces the number of quer
Adrian Klaver writes:
> On 8/27/21 2:23 PM, Tom Lane wrote:
>> Those queries are coming from getFormattedTypeName(), which is used
>> for function arguments and the like. I'm not quite sure why Hubert
>> is seeing 5000 such calls in a database with only ~100 functions
hubert depesz lubaczewski writes:
> On Fri, Aug 27, 2021 at 05:23:23PM -0400, Tom Lane wrote:
>> Those queries are coming from getFormattedTypeName(), which is used
>> for function arguments and the like. I'm not quite sure why Hubert
>> is seeing 5000 such calls in
In any case I doubt
this is ever going to be less efficient than the original coding.
regards, tom lane
diff --git a/src/bin/pg_dump/pg_dump.c b/src/bin/pg_dump/pg_dump.c
index 6adbd20778..befe68de1a 100644
--- a/src/bin/pg_dump/pg_dump.c
+++ b/src/bin/pg_dump/pg_dump.
here on the number-of-queries scale.
regards, tom lane
hubert depesz lubaczewski writes:
> On Fri, Aug 27, 2021 at 05:23:23PM -0400, Tom Lane wrote:
>> I experimented with the attached, very quick-n-dirty patch to collect
>> format_type results during the initial scan of pg_type, instead.
> So, I applied it to brand new HEAD from g
ride pkglibdir := $(pkglibdir)/postgresql
endif
endif
This behavior is pretty ancient; I'm quite sure it didn't change
between 12.5 and 12.8. So I speculate that you made some change
in your build process that you didn't mention.
regards, tom lane
hubert depesz lubaczewski writes:
> On Mon, Aug 30, 2021 at 10:11:22AM -0400, Tom Lane wrote:
>> I speculate that it is collecting and then not printing the info
>> about functions that are in extensions --- can you check on
>> how many there are of those?
>
ng
more than a little bit why we're allowing DUMP_COMPONENT_POLICY
to become set on objects that aren't tables.)
regards, tom lane
obably got it right.
I strongly suggest reading
https://www.postgresql.org/docs/current/storage.html
before you go messing with any files manually, so you know what
you are looking at.
regards, tom lane
2301 - 2400 of 2962 matches
Mail list logo