ic test function
that takes a value, runs it through the type's send and then receive
functions, and returns the result (or just complains if it gets different
bits out ...)
regards, tom lane
Paul A Jungwirth writes:
> On Sun, Sep 22, 2019 at 11:53 AM Tom Lane wrote:
>> I thought of an easier-to-maintain approach to that part than having
>> a reference file.
> I just finished my multirange patch (well, "finished" :-), so I might
> be willing to sign
query is running, to see if it seems to be eating CPU or
is blocked on some condition. (I forget how thorough the
wait_event coverage is in 9.6, but it does at least have those
columns.)
Can you create a self-contained test case that acts like this?
regards, tom lane
mpty pg_statistic, run "ANALYZE;" (as superuser)
to rebuild all the stats.
Hard to tell what the underlying issue is here --- perhaps pg_upgrade
messed up, but it would take some detailed investigation to find out.
regards, tom lane
ve any way to decide whether it
should use "numeric + numeric" or "bigint + bigint" here.
regards, tom lane
; if you try you'll find yourself maintaining
a lot of messy code that we *will* break on a regular basis.
It would be less hard in a backend extension, but I suspect
you don't want to go there :-(
regards, tom lane
erialization format.)
regards, tom lane
hand, try using that.
7.4 to 11 is a big jump to be doing in one step. There's definitely
something to be said for porting to an intermediate release, just to
break down the work into smaller chunks. But I'd go for halfway between,
which if I counted releases correctly would be about 9.1, not 8.4.
regards, tom lane
ub-select return a rowset result rather than an array
result might be the best way to resolve things. It's more SQL-y,
for sure.
regards, tom lane
ly functions that do pay attention to LC_NUMERIC are
to_char() and friends.
regards, tom lane
nt search_path. So you could get what
you want by setting a restrictive search_path beforehand, maybe just ''.
regards, tom lane
r to split out those modules as a separate
package. OTOH that would add confusion, and we have a lot of
subpackages already.
Another idea might be to bundle them into the plpython package
instead of contrib (and similarly for the plperl transforms).
regards, tom lane
rate row count, COUNT(*) or pgstattuples will give you a more
reliable estimate ... at much higher cost, of course.
regards, tom lane
Luca Ferrari writes:
> On Fri, Sep 27, 2019 at 3:52 PM Tom Lane wrote:
>> n_live_tup/n_dead_tup should not be thought to be better than
>> approximations. Most operations adjust them only incrementally,
>> and messages to the stats collector can get dropped entirely
>>
n 500ms. But on that day something
> happened, what was that, PARSE time of 10 minutes ?
Something else sitting on an exclusive table lock, perhaps?
regards, tom lane
'd evidently match to numeric + anything.
regards, tom lane
owMarks; /* a list of RowMarkClause's */
Now probably this is never called on utility statements, and maybe
there is never a reason for anyone to examine or mutate SortGroupClauses,
GroupingSets, or RowMarkClauses, but I'm not sure it's any business of
this module to assume that.
regards, tom lane
Andrew Gierth writes:
> "Tom" == Tom Lane writes:
> Tom> Now probably this is never called on utility statements, and maybe
> Tom> there is never a reason for anyone to examine or mutate
> Tom> SortGroupClauses, GroupingSets, or RowMarkClauses, but I'm n
nd rowMarks?
Also, in HEAD I'd be inclined to add assertions about utilityStmt
being NULL.
regards, tom lane
his will capture numeric plus *anything*, so it was not a
good idea. I'd recommend dropping the use of anyelement and just
making three non-polymorphic operators.
regards, tom lane
Andrew Gierth writes:
> "Tom" == Tom Lane writes:
> Tom> Hmm. I think this is a reasonable direction to go in, but
> Tom> what about groupingSets and rowMarks?
> groupingSets ultimately contains nothing but numbers which are
> meaningless without reference t
a
> conscious design choice?
We read the SQL spec as requiring this behavior.
regards, tom lane
reasoning is lost in the mists of time :-(
Another thing that is not very nice is that pg_restore lacks the
ability to use patterns (wildcards) here. Someday maybe somebody
will get around to fixing that. I could see changing the definition
of -n to include the schema itself at the same time.
regards, tom lane
isting info
into DETAIL and make the primary message be something like "reached
apparent end of WAL stream".
regards, tom lane
tions +|
> | Password valid until infinity |
Hm, what's the overall max_connections limit? (I'm wondering
in particular if it's more or less than 100.)
regards, tom lane
processes; it needs to be less, by the number of background
processes we want to support. But it seems like a darn hard-to-hit bug,
so I'm not quite sure that that explains your observation.
regards, tom lane
ats on the column combination might allow
the planner to figure out that the second IN condition adds little
selectivity. But I'm not sure how hard it would be, and I am sure
that the extended-stats logic hasn't been built out in that direction
yet.
regards, tom lane
e is to get a stack trace from the crash, if you can.
regards, tom lane
indexes that could benefit from the other changes.
regards, tom lane
Thomas Kellerer writes:
> Tom Lane schrieb am 04.10.2019 um 16:52:
>> No, this thread is a sufficient report. What *would* be a good use
>> of time is to get a stack trace from the crash, if you can.
> I don't know if I did everything correctly, but here it is. I hope i
ard.
PostgreSQL allows it to be consistent with
allowing zero-column tables.
However, an empty list is not allowed when DISTINCT is
used.
regards, tom lane
e it never touches any
relation files directly.
regards, tom lane
r looking into pg_locks to see
what's going on in cases like this ...
regards, tom lane
trace (or back-trace in C-land?) on sig11?
You should be able to get a core file from which you can extract a
stack trace (and other info) after the fact.
https://wiki.postgresql.org/wiki/Generating_a_stack_trace_of_a_PostgreSQL_backend
regards, tom lane
ivery?
This doesn't seem to correlate with your original report, btw,
as that claimed the crash was during COMMIT.
regards, tom lane
Andreas Joseph Krogh writes:
> Is it OK if I send you the table/trigger-definitions off-list?
Sure, but please share with Andres [cc'ed] as well.
regards, tom lane
which that's legal data.
The typical rule is that double quotes that are data must be doubled;
at least, that's what COPY expects by default. You can also get COPY
to handle variants like backslash-quote.
regards, tom lane
entation that suggests it should
treat "'" specially. If it didn't, you'd get
# select websearch_to_tsquery('"peter o toole"');
websearch_to_tsquery
'peter' <-> 'o' <-> 'tool'
(1 row)
which would match this tsvector.
regards, tom lane
pfree( cols.data );
cols.data = NULL;
} /*IF col.len>0*/
Don't do that, use resetStringInfo() instead.
regards, tom lane
Andres Freund writes:
> On 2019-10-09 10:16:37 -0400, Tom Lane wrote:
>> Well, it shows that the failure is occurring while trying to evaluate
>> a variable in a trigger's WHEN clause during
>> "UPDATE origo_email_delivery SET folder_id=$1, created=$2\nWHERE e
res
seems excessively chatty. More-commonly-used auth methods aren't
that noisy.
regards, tom lane
er's DB it is '273 days';
> Then you need to establish why that is.
I recall having heard that EDB installs some non-PG datetime operators
to make things act more similar to Oracle.
regards, tom lane
"Lu, Dan" writes:
> Is there a catalog view that I can query to see what options were used
> to configure the PG instance?
No, but pg_config should tell you.
regards, tom lane
e
beating up RDS for not letting you configure your DB the way you want.
regards, tom lane
for treating CTEs as parallel restricted is simply to
guarantee single evaluation of the CTE. Within a function, that would
only matter per-function-execution, so I can't see why a function
containing such a query couldn't be pushed down to workers for execution.
regards, tom lane
tall your own C functions either :-(
regards, tom lane
e it feasible to have
more, but only in limited use-cases.
regards, tom lane
rently depending on whether they
think the function is volatile or not, but that's independent of whether
the function is a trigger.
regards, tom lane
ign table on the local server.
Yeah. Or if you really want to call a remote function by name, see
dblink. postgres_fdw actively avoids doing that sort of thing.
regards, tom lane
Matthias Apitz writes:
> When we export char columns with our Perl tools, they come out with trailing
> blanks (in Sybase they don't). Can this be suppressed?
Switch to varchar, perhaps?
regards, tom lane
the ISO standard
which uses the opposite sign. See
https://www.postgresql.org/docs/current/datatype-datetime.html#DATATYPE-TIMEZONES
regards, tom lane
g_libphonenumber.so depends on. I think you forgot to install
that one on this machine.
regards, tom lane
'20181501'::date;
ERROR: date/time field value out of range: "20181501"
LINE 1: select '20181501'::date;
^
HINT: Perhaps you need a different "datestyle" setting.
regression=# select '20181001'::date;
date
2018-10-01
(1 row)
regards, tom lane
the table rows, so 3 is the correct answer.
> No doubt: it's a bug, no matter what the Pg devs say.
Complain to the SQL standards committee, not us.
regards, tom lane
tion ID,
while local transaction IDs are just taken from a counter within
the session and have no meaning to other sessions.
regards, tom lane
ly resist
proposals to, say, make SELECT 'null'::json IS NULL return true).
Maybe it's okay to make this case work like that, but don't be too
high and mighty about it being logically clean; it isn't.
regards, tom lane
ion, so that it executes with a
known search_path regardless of the session's prevailing path.
regards, tom lane
t;foo"."col_id" IN ($1, $2, $3, $4, $5, $6, $7, $8, $9)
> It looks like increasing work_mem doesn't help. Surely 16GB is enough to
> cover all these small temp files?
You'd need to provide a lot more detail about what that query is doing
for anyone to be able to guess where the temp file usage is coming from.
regards, tom lane
a set of Perl header files that don't match the Perl library you're
linking to. Check for multiple Perl installations on your machine,
and pay attention to the include and link search paths that are being
used in your plperl build.
regards, tom lane
x27;re in a short-lived SPI context already inside that
loop; but you could save CurrentMemoryContext before starting up
SPI and then use MemoryContextStrdup.
regards, tom lane
rihad writes:
> On 10/25/2019 05:49 PM, Tom Lane wrote:
>> You'd need to provide a lot more detail about what that query is doing
>> for anyone to be able to guess where the temp file usage is coming from.
> I just checked and saw that the function "foo_xml_v2"
the doserrors[] table.
But that just deepens the mystery --- if we hit an EOF, why wasn't
that handled through more-normal channels? We still need to know
what that function was trying to do, and whether any non-core
C code was involved.
regards, tom lane
end RowDescription to
support describing composites' sub-fields, it wouldn't be in
much of a position to deal with that.
regards, tom lane
der whether the JDBC API could handle it either.
tl;dr: there are a lot more worms in this can than you might guess.
regards, tom lane
s based
on n_dead_tup and the other on n_mod_since_analyze, plus you can set
different threshold parameters to compare those to). The pg_stat_activity
report of what's happening does match the command-line syntax.
regards, tom lane
search_path (or else provide a new column that does
> that)?
Why don't you just change the search path to empty before selecting?
regards, tom lane
the original table, forcing
the projection to be done to get rid of them.
regards, tom lane
deleted in the past, but
> VACUUM FULL not run on that table, right ?
VACUUM would not change the state of the dropped columns.
regards, tom lane
um is the only persistent
identifier of a column.
(From memory, operations like VACUUM FULL and CLUSTER will rewrite
dropped columns with NULLs to reduce their storage impact. But they
don't go away.)
regards, tom lane
s,
references to built-in functions and operators, and temp table names
will not be qualified. Everything else will be.
regards, tom lane
"pkg". That's not a great default IMHO and
> should be changed.
Ugh. Who can we poke there?
regards, tom lane
and recreate it, again causing headaches for non-superuser usage. This
change likewise makes the public schema less special and more like other
built-in objects.
regards, tom lane
optimization behavior existed then.
I'm inclined to:
(1) get rid of the example's MIN() function in favor of using
LEAST(), which is standard and less confusing;
(2) change the text to just say that the planner flattens these
subqueries, so we don't pay any execution-time penalty from the
way the view replacements are handled.
regards, tom lane
system-tzdata,
I guess, so that it uses tzdata it's expecting.)
regards, tom lane
an UPDATE, I suspect it's a known problem:
if you have a BEFORE UPDATE row-level trigger, and a concurrent update
on the same row happens, 12.0 can dump core due to a slot memory
management mistake. There's a fix in 12.1, due out tomorrow.
regards, tom lane
Durumdara writes:
> I need to ask about last_autovacuum column in *pg_stat_all_tables.*
> I'm not sure is this a starting time, or when the daemon finished.
Looks like it's the time that the vacuum operation finished.
regards, tom lane
fer an ALTER VIEW spelling of that, but we don't ATM.
ALTER TABLE works though.)
regards, tom lane
Adrian Klaver writes:
> On 11/14/19 7:12 AM, Tom Lane wrote:
>> If you actually want to rename an existing view column, use
>> ALTER TABLE ... RENAME COLUMN ... for that.
> Alright, I'm missing something here:
> test=# alter table up_test rename COLUMN col1 to col_1;
Kyotaro Horiguchi writes:
> At Wed, 2 Oct 2019 19:24:02 -0400, Stephen Frost wrote
> in
>> * Tom Lane (t...@sss.pgh.pa.us) wrote:
>>> Yeah, those messages are all pretty ancient, from when WAL was new and not
>>> to be trusted much. Perhaps the thing to do is m
- but if you just
want to see what the constraints are, then this is a good way.
regards, tom lane
k
a serial sequence to its owning column. I don't have an example
right to hand, but I'm sure there is an instance in pg_dump, and
probably elsewhere.
regards, tom lane
; AND "vessels"."company_id" = '7d105acd-be5a-4225-a2db-b549105e4172';
> When I ran the same query to production I get error:
> ERROR: set-valued function called in context that cannot accept a set
IIRC, you can't nest calls of set-returning functions before about v10.
One workaround is to put the inner set-returning function call into a
sub-select.
regards, tom lane
change the default setting then.
So it seems that that change was not entirely without fallout:
https://www.postgresql.org/message-id/flat/16118-ef1e45e342c52416%40postgresql.org
I don't think this is reason to revert the change, exactly,
but it's a concern. I wonder why FreeBSD editorializes on
the set of zone names?
regards, tom lane
a non-official alias,
but I don't think it's reason to panic.
regards, tom lane
more manageable way of dealing with concurrent-update
problems.
regards, tom lane
ial names!
[ shrug... ] The installed format doesn't provide any way to
distinguish which are the "official" names. They're typically
all hardlinks to the same file.
regards, tom lane
the listen_addresses line when you edited it. As installed,
postgresql.conf is pretty much all comments.
You might get more insight from
select * from pg_settings where name = 'listen_addresses';
particularly the source, sourcefile, sourceline fields.
regards, tom lane
ld that make a
> difference?
Hm, well, *something* is overriding the setting. What did you
find in pg_settings?
regards, tom lane
The OP may well need to adjust pg_hba.conf too, but he's not got
that far yet :-(
regards, tom lane
"Jason L. Amerson" writes:
> pg_settings show localhost.
What I asked you about was the "source" columns.
regards, tom lane
e. I think that's an okay limitation
for a niche use-case. It also generalizes more easily to cases where
there's more than exactly one allowed value for a referencing column.
regards, tom lane
t say whether either of those apply to you;
but I would note that the DDoS scenario only applies if your server
is reachable from the net-at-large, which is seldom a good idea in
the first place.
regards, tom lane
ng like the above will work.
Note that you pay a fairly substantial performance penalty for deferring
the check, which is why it isn't the default, even though the SQL spec
says it ought to be.
This is documented in some obscure place [ ... looks around ... ]
ah, see "Non-Deferred Uniqueness Constraints" under Compatibility
in the CREATE TABLE reference page.
regards, tom lane
seems possible that he'll
change that policy, so I'd advise doing nothing until that discussion
settles.
regards, tom lane
[1] https://mm.icann.org/pipermail/tz/2019-November/028633.html
Jeff Janes writes:
> On Sat, Nov 23, 2019 at 4:47 PM Tom Lane wrote:
>> Note that you pay a fairly substantial performance penalty for deferring
>> the check, which is why it isn't the default, even though the SQL spec
>> says it ought to be.
> Do you know what t
CII digits using replace(), then cast.
It'd be a bit tedious, but fortunately there are only 10 cases
to consider, and you could wrap that up in a function.
regards, tom lane
an with the native <@ operator. So this isn't an all-purpose
fix --- but it might cover your needs and be nicer than maintaining a
second index on the column.
regards, tom lane
regards, tom lane
pattern, so the PITA factor is high. And I doubt it'd be faster than
the CASE solution.
regards, tom lane
ed
to be sure that your queries use the questionable indexes, and maybe
even search for some of the specific rows that seem mis-indexed.
regards, tom lane
401 - 500 of 2962 matches
Mail list logo
