hat anything in the system catalogs is
sensitive. If you don't want user A looking at user B's catalog
entries, give them separate databases, not just separate schemas.
regards, tom lane
t too late for this week's releases :-(
regards, tom lane
an is going to have a hard time beating other
alternatives.
regards, tom lane
nly query) but [1] indicates
> that only vacuum will set them ddl will clear them.
Hm, I don't recall that, but I've not been involved in the last few rounds
of hacking on that mechanism.
regards, tom lane
I can see these parse statement occurances about 400 times in a
> day and everytime taking longer than 15 secs.
That seems like a mighty long time for parse analysis. Maybe you're
having difficulties with something taking exclusive locks, thereby
blocking other queries?
regards, tom lane
:';
Depending on what you're doing, either the pattern-match way or the
substring way might be more convenient. The performance implications
are different too, though that won't matter to you unless you're dealing
with so much data that you want to create a specialized index to make
queries of this form faster.
regards, tom lane
ommand was: CREATE FOREIGN DATA WRAPPER "dblink_fdw" VALIDATOR
> "dblink_fdw_validator";
Is that really the first error, or did you "omit" some? What it
looks like is that dblink_fdw_validator had previously failed to
be created, probably because you don't have dblink.so installed
in the destination database. Or maybe it's not the right version
of dblink.so.
regards, tom lane
n the core backend, and few if any bother with a repalloc.
regards, tom lane
rtheast were without
power over the weekend due to storm damage.
regards, tom lane
his stack trace is not going anywhere near that code. The
common factor is just strcoll_l(), raising the possibility that you're
dealing with a glibc bug, or perhaps corrupted locale data on your
machine. Are you up-to-date on glibc patches?
regards, tom lane
| 22/4317099
PID 20488 is evidently waiting for PID 6471 to finish its transaction.
What's that one doing?
> Is it a bug that this isn't caught by a deadlock detector and cancelled?
We did find a bug recently with concurrent CREATE INDEX CONCURRENTLY's
all waiting for each ot
Justin Pryzby writes:
> On Thu, Mar 08, 2018 at 01:57:06PM -0500, Tom Lane wrote:
>> PID 20488 is evidently waiting for PID 6471 to finish its transaction.
>> What's that one doing?
> Um, I thought I had kept track of all two pids but looks not..
> query|
r: restore of that TOC
entry would set the object's privileges all right, but if it ever had
anything to do with setting the object's ownership, it was a really long
time ago.
regards, tom lane
extra parsing overhead per
se ... but execution of the command costs something too.
regards, tom lane
onth
or so, until that dust settles.
regards, tom lane
(which *is* a database-level
privilege). Again, this'll involve disallowing that to PUBLIC,
since that default grant is how it's getting the privilege.
regards, tom lane
,
and it might help somebody understand that the problem is exactly
that relations of different types share the same namespace.
regards, tom lane
d into a spare server. That might catch forms of data
corruption that reindexing would not, such as violated CHECK constraints.
regards, tom lane
s possible unfortunately. The trigger would have to take
care of the situation, but it doesn't have any way to know that the
calling query has an ON CONFLICT rule.
regards, tom lane
t "ttest_pkey"
DETAIL: Key (x)=(1) already exists.
regression=# INSERT INTO vtest VALUES (1) ON CONFLICT DO NOTHING;
INSERT 0 0
The query rewriter knows how to translate the ON CONFLICT to apply
to the underlying table along with the rest of the command.
regards, tom lane
ing inheritance - then tableoid may vary. That's the case
> I'm interested in.
Uh, no, not within a single table ... and indexes only cover one table.
regards, tom lane
really equality
to situations like foreign keys gets pretty interesting pretty fast.
An exclusion constraint using && might ensure that no two values in the
column are identical, but it would not be enough to ensure that a proposed
FK row can't && with more than one PK row. So what then?
regards, tom lane
uot; instead of "works with >= 9.0". But hey, it's a wiki;
if you feel more ambitious, edit away.
regards, tom lane
e continually
in order to weigh in. But 9.2 is not just released, it's EOL, so it's
really kinda late to be objecting.
regards, tom lane
mp() with a format string
that doesn't really match the data, causing the year field to be truncated
or misinterpreted.
regards, tom lane
* elements, rather than a single NULL value,
if the input isn't an array --- but that seems to me to make more sense
than your existing code anyhow. If you disagree, add "else return next
null::jsonb".
regards, tom lane
uch log messages when testing postgres_fdw here,
which is odd; why are my results different?
If these are about the FDW connections, maybe the answer is that
postgres_fdw ought to establish a backend-exit callback in which
it can shut down its connections gracefully. If it's doing that
now,
; unless
you have USAGE on schema_1. So the RI-checking query, which is run as
the owner of the table, fails at parse time.
regards, tom lane
ion of the FK no longer done as user_1?
Exactly, it's done as the owner of the referencing table. (I don't recall
whether that's uniformly true for all types of FK-enforcement queries,
but evidently it's true for this case.)
regards, tom lane
to the level of a bug, exactly, but if somebody wanted to
send in a patch it'd probably get accepted.
regards, tom lane
Michael Paquier writes:
> On Thu, Mar 22, 2018 at 06:55:12PM -0400, Tom Lane wrote:
>> Anyway, it's clearly not very nice that postgres_fdw makes no attempt
>> to do a graceful shutdown of its remote connection. I don't know that
>> this rises to the level of
want to assume that
"localhost" is safe, and we'd certainly not know what to do for
connections that use the host's name.
Note that in most scenarios, "local" connections travel over a Unix socket
not TCP, and in that case we don't encrypt.
regards, tom lane
more aggressive) TCP
keepalive settings.
regards, tom lane
at errfinish) would
probably be enough info to figure out what is trying to grab 1.6GB in one
bite. But it won't help us find out why so many empty ExprContexts are
getting created.
regards, tom lane
which might require fake data that has roughly
similar properties as to number of distinct values and so on.
regards, tom lane
isn't all-visible. Comparing
pg_class.relallvisible values might be informative.
regards, tom lane
tainly all the v10 partitioning logic is
still pretty wet behind the ears.
regards, tom lane
clearer which range specifications
are equal. For instance, it's not really clear whether
['2018-02-02','2018-03-01'] and ['2018-02-02','2018-03-02') represent
the same set of values --- they do if it's a daterange, but not if it's
a tsrange. Canonicalizing makes equal ranges look equal.
regards, tom lane
definition.
Yeah, you might be better off looking at that, particularly since it
updates on-the-fly not just after a vacuum or analyze.
regards, tom lane
on/off, but I couldn't find one.
That's because pg_regress launches psql with the -q option (as well as -a).
I think you might be able to override that within a particular test script
by fooling with QUIET, or whichever psql variable it is that that switch
sets.
regards, tom lane
at you now get a seqscan plan (you might need to turn off
enable_bitmapscan too), then do the query again and see whether the
results are the same.
regards, tom lane
s",
> "changelog_change_transaction"."xmin"
> ;
Why are you grouping on xmin?
> For sure if the GROUP BY the one that causes this OOM (when I removed it, the
> query finish ok ) , so I've change the query-plan to avoid the HashAggregate:
> But the explain still shows:
That's because type XID doesn't have sort support, only hash support,
so hash aggregation is the only way to do the query at all.
regards, tom lane
e with that OID. I'm not sure offhand how we could
get into such a state. Alvaro, does this ring any bells (remembering that
this is 9.3)?
regards, tom lane
timing of events. You could probably make it more predictable
by making deadlock_timeout either very short or very long, but
neither of those are desirable things to do.
regards, tom lane
Stephen Frost writes:
> * Tom Lane (t...@sss.pgh.pa.us) wrote:
>> Yeah, I can reproduce this. I suspect it got broken by Stephen's hacking
>> around with default ACLs. A simple example is
> Yes, it's related to the work I did with pg_dump's ACL handling, beca
t works for other people, I can't say.
regards, tom lane
; FETCH ALL IN B;
> ERROR: cursor "b" does not exist
The cursor is named "B" not "b", but B without quotes folds to the latter.
regards, tom lane
behaviors
in e.g. string comparison, because strcoll() will expect UTF8 data and
will likely not cope well with data that isn't valid in that encoding.
If you can't sanitize the encoding of your data, I'd suggest running
with lc_collate and lc_ctype set to "C".
regards, tom lane
Keith Fiske writes:
> On Mon, Apr 16, 2018 at 12:09 PM, Tom Lane wrote:
>> This is not a great idea, no. You could be getting strange misbehaviors
>> in e.g. string comparison, because strcoll() will expect UTF8 data and
>> will likely not cope well with data that isn
these file systems. I have no idea what such a fix would
look like :-(
regards, tom lane
ny WHERE clause that the optimizer had any intelligence about
at all, because it would defeat all of that. But in this case you're
not getting any wins anyhow, so burying an opaque subselect in another
layer of opacity won't hurt.
regards, tom lane
e_out() to be invoked while dumping the view
definition.
I don't remember anymore whether I'd set up the postgresql-update package
to include the contrib modules for the old server version. If I didn't,
it was an oversight :-(.
regards, tom lane
when you transfer
that text from machine A to machine B, the no-break space is getting
dropped.
regards, tom lane
triggers.sgml and/or
create_trigger.sgml, but in a quick look neither of them mentions foreign
keys.)
regards, tom lane
=?UTF-8?Q?Fabr=C3=ADzio_de_Royes_Mello?= writes:
> 2018-04-19 15:57 GMT-03:00 Tom Lane :
>> (I'm not sure that this issue is adequately documented, though.
>> I'd have expected to find something about it in triggers.sgml and/or
>> create_trigger.sgml, but in a quic
called
with a string that isn't a valid ltree representation. You haven't
shown us what you are doing on that end, but for example I can
duplicate the error message with
# select text2ltree(' ');
ERROR: syntax error at position 0
regards, tom lane
hat you expect. It's entirely possible that this is a
bug in PGAdmin's debugger. Again, you'd be best off discussing it on the
pgadmin lists rather than here.
regards, tom lane
prefix). It might
not be practical in this particular case, but it's a good tool to keep
in mind.
regards, tom lane
.proargtypes::regtype[] might be useful.
regards, tom lane
7;m not even sure you'd want to traverse the plan
tree.)
I'm not convinced that it's practical for pg_stat_statements to make a new
shared hashtable entry under those constraints. But figuring out how to
minimize the risks around that is the stumbling block, not lack of a hook.
regards, tom lane
r, at least according to
the planner's cost model.
regards, tom lane
in the initial command.
regards, tom lane
d to provide one actual-rowcount number that maybe was
enough to diagnose the issue; but if the above doesn't do the trick,
we're going to need to see EXPLAIN ANALYZE to guess what else is up.
regards, tom lane
>-> Hash (cost=118285.38..118285.38
Anudeep Gudipelli writes:
> I would like to know the known bugs for v9.5 and also v9.6, is there any
> place where I can check?
See release notes at
https://www.postgresql.org/docs/current/static/release.html
regards, tom lane
don't.)
You say you're worried about "large arrays" in dr2epochflux; but if they
are large enough to be toasted out-of-line, it's really a nonissue. Only
the toast pointers would be read during the seqscan or stored in the hash.
regards, tom lane
n as
the database server owner (which is the reason for the superuser
restriction).
regards, tom lane
ger
functions is a bit different, mostly for historical reasons.)
regards, tom lane
s than the existing kluge
to ignore a UTF BOM character at the start of the file.
The concerns about whether psql would get invoked with a desirable
set of options if you tried to do this seem more worrisome, but if
that does work out usefully, I think this is a reasonable proposal.
regards, tom lane
e same sort of
relationship with text, so there's precedent ...
regards, tom lane
he format() function (a/k/a text_format).
regards, tom lane
the default record representation (with parens
and a comma)?
regards, tom lane
[ please keep the list cc'd ]
Steven Lembark writes:
> On Thu, 10 May 2018 11:52:48 -0400
> Tom Lane wrote:
>> Maybe you should show a more concrete example of what's not working.
> The problem is with gists telling me that they cannot index
> the type. This w
Steven Lembark writes:
> On Thu, 10 May 2018 14:41:26 -0400
> Tom Lane wrote:
>> Steven Lembark writes:
>>> The problem is with gists telling me that they cannot index
>>> the type. This works for enums, just not the composite type.
>> Oh, well, they can&
t; clause
in order to get this dump to load into a pre-v10 server.
Alternatively, I believe creating the column as BIGSERIAL would result in
dump files that would reload into older servers without adjustments.
regards, tom lane
ption. Depending on what parameters you're using now,
maybe even an increase would be better.
regards, tom lane
f there's
anything to that.
In the grasping-at-straws department: are you quite sure that the extra
disk space consumption is PG's to begin with, rather than something
outside the database entirely?
regards, tom lane
t/static/release-9-6-4.html
I didn't bother with spelling it all out in full detail this time,
which maybe was a mistake, but I felt that probably most users
wouldn't need to bother with these changes at all (unlike the case
where a catalog correction is security-related).
regards, tom lane
Adrian Klaver writes:
> On 05/14/2018 02:02 PM, Tom Lane wrote:
>> I didn't bother with spelling it all out in full detail this time,
>> which maybe was a mistake, but I felt that probably most users
>> wouldn't need to bother with these changes at all (unl
bers/
pg_multixact/offsets/
pg_logical/
pg_multixact/
pg_notify/
pg_replslot/
pg_serial/
pg_snapshots/
pg_stat/
pg_stat_tmp/
pg_subtrans/
pg_tblspc/
pg_twophase/
pg_wal/
pg_xact/
regards, tom lane
are gone, they're
gone, especially if the table's been vacuumed since.
regards, tom lane
you provoke it somehow? I'm wondering how
your 9s timeout relates to the expected completion time.
I don't have any test DBs with anywhere near large enough stats to
require 9s to vacuum pg_statistic, but I'm trying this with a
much-reduced value of statement_timeout, and so far no failures ...
regards, tom lane
thing involving a temp table.
regards, tom lane
be I'm too used to doing that, but I'm not very clear on what
you gain by extracting the result of somebody else's build -- which,
almost by definition, is not exactly what you want.
regards, tom lane
Alexey Dokuchaev writes:
> On Mon, May 21, 2018 at 10:45:27AM -0400, Tom Lane wrote:
>> OP could do something like
>> select json_agg(_) as j, count(*) as c INTO r FROM (
> Thanks, I've arrived at the same solution (using local RECORD) eventually.
> It works as int
Alexey Dokuchaev writes:
> Quick reality check
> question: are count(*) vs. count(_) equivalent above?
Only if _ is guaranteed non-null ... which, as a rowtype result, it
probably is. But I'd use count(*) if you're concerned about speed.
regards, tom lane
27;t want to leave it to pg_ctl to do the waiting.
Personally, my recommendation would be to go back to "peer" auth,
at least for local connections by postgres. There is no reason
to think that passwords are a more secure approach: password
management is a hard problem, especially for automated connections
like these.
regards, tom lane
afer to figure out what's blocking automatic
cleanup so you can fix the root cause.
regards, tom lane
* from pg_prepared_xacts;
regards, tom lane
ou're showing us. So
that behavior must also be due to some non-core pretty-printing code you
haven't identified to us. No idea what rules that might have for deciding
to omit "number".
regards, tom lane
that (I'm thinking of Nabble in particular). So my initial
reaction is "thanks but no thanks, we don't need another of those".
But maybe you can do it a lot better than they have.
regards, tom lane
ertain parts
of the index.
You could maybe get around all of that by reindexing any indexes
containing the altered enum type after you're certain that all
entries of the unwanted enum value are dead and vacuumed away.
But it's not terribly safe.
regards, tom lane
really wrote
INSERT ... , 'uuid_generate_v4()', ...
not
INSERT ... , uuid_generate_v4(), ...
There might be some layers of client-side parameter mangling obscuring
what's actually happening.
regards, tom lane
ble
postgis RPM you're trying to install.
regards, tom lane
of comments, we anticipate making the CoC official as of
July 1 2018.
regards, tom lane
[1] https://www.postgresql.org/message-id/56a8516b.8000...@agliodbs.com
hese sorts of arguments at excruciating
length in 2016. It's quite clear to the core team that a majority of
the community wants a CoC. I don't think any useful purpose will be
served by re-litigating that point.
regards, tom lane
2016, I don't think you'll find any differences
that are so substantive as to require public defense. We tried to make
the wording simpler and less intimidating, but that's about it.
regards, tom lane
[1] https://wiki.postgresql.org/wiki/Coc_qa_pgcon2016
x27;m very glad today.)
regards, tom lane
kely provide a more accurate result, but it's also a lot more
complicated.
regards, tom lane
"Joshua D. Drake" writes:
> On 06/03/2018 11:29 AM, Tom Lane wrote:
>> We are now asking for a final round of community comments.
> Thanks for all the efforts on this. It is nice to see us explicitly
> moving toward modernizing our community policies and creati
butors left
because of harassment, and I'd like to ensure that doesn't happen again.
regards, tom lane
1 - 100 of 2927 matches
Mail list logo
