Make assorted performance improvements in snprintf.c.
In combination, these changes make our version of snprintf as fast
or faster than most platforms' native snprintf, except for cases
involving floating-point conversion (which we still delegate to
the native sprintf). The speed penalty for a fl
Provide fast path in snprintf.c for conversion specs that are just "%s".
This case occurs often enough (around 45% of conversion specs executed
in our regression tests are just "%s") that it's worth an extra test
per conversion spec to allow skipping all the logic associated with
field widths and
Rationalize snprintf.c's handling of "ll" formats.
Although all known platforms define "long long" as 64 bits, it still feels
a bit shaky to be using "va_arg(args, int64)" to pull out an argument that
the caller thought was declared "long long". The reason it was coded like
this, way back in comm
Fix issues around EXPLAIN with JIT.
I (Andres) was more than a bit hasty in committing 33001fd7a7072d48327
after last minute changes, leading to a number of problems (jit output
was only shown for JIT in parallel workers, and just EXPLAIN without
ANALYZE didn't work). Lukas luckily found these is
Change executor to just Assert that table locks were already obtained.
Instead of locking tables during executor startup, just Assert that
suitable locks were obtained already during the parse/plan pipeline
(or re-obtained by the plan cache). This must be so, else we have a
hazard that concurrent
Fix issues around EXPLAIN with JIT.
I (Andres) was more than a bit hasty in committing 33001fd7a7072d48327
after last minute changes, leading to a number of problems (jit output
was only shown for JIT in parallel workers, and just EXPLAIN without
ANALYZE didn't work). Lukas luckily found these is
Ensure that snprintf.c's fmtint() doesn't overflow when printing INT64_MIN.
This isn't actually a live bug, as the output happens to be the
same. But it upsets tools like UBSan, which makes it worthwhile to
fix.
As it's an issue without practical consequences, don't backpatch.
Author: Andres Fr
Andres Freund writes:
> Ensure that snprintf.c's fmtint() doesn't overflow when printing INT64_MIN.
Hm, I think you should s/uint64/unsigned long long/ to be consistent
with 595a0eab7.
regards, tom lane
Hi,
On 2018-10-03 16:24:23 -0400, Tom Lane wrote:
> Andres Freund writes:
> > Ensure that snprintf.c's fmtint() doesn't overflow when printing INT64_MIN.
>
> Hm, I think you should s/uint64/unsigned long long/ to be consistent
> with 595a0eab7.
Fair point. Will push once tests finish.
Greeting
Replace uint64 use introduced in 4868e446859 in light of 595a0eab7f42.
Reported-By: Tom Lane
Discussion: https://postgr.es/m/[email protected]
Branch
--
master
Details
---
https://git.postgresql.org/pg/commitdiff/d173652797cf0cf456ac2c38eca898159a7c19fc
Modified Files
---
Add option SKIP_LOCKED to VACUUM and ANALYZE
When specified, this option allows VACUUM to skip the work on a relation
if there is a conflicting lock on it when trying to open it at the
beginning of its processing.
Similarly to autovacuum, this comes with a couple of limitations while
the relation
11 matches
Mail list logo
