Hi,
We're carrying a bunch of obsolete and in one case insecure advice on
kernel settings. Here's an attempt to clean some of that up.
Linux:
* Drop reference to ancient systems that didn't have a sysctl command.
* Drop references to Linux before 2.6.
* I was tempted to remove the reference t
Hi,
On 2020-06-03 18:41:28 -0400, Tom Lane wrote:
> Andres Freund writes:
> > When libpq is used to COPY data to the server, it doesn't properly
> > handle errors.
> > This is partially an old problem, and partially got recently
> > worse. Before the below commit we detected terminated connection
Hi,
While preparing my pgcon talk I noticed that our hash-agg performance
degraded noticeably. Looks to me like it's due to the spilling-hashagg
changes.
Sample benchmark:
config:
-c huge_pages=on -c shared_buffers=32GB -c jit=0 -c
max_parallel_workers_per_gather=0
(largely just to reduce varia
Hi,
On 2020-06-05 22:52:47 -0400, Tom Lane wrote:
> Andres Freund writes:
> > On 2020-06-05 21:01:56 -0400, Tom Lane wrote:
> >> At some point I think we'll have to give up --disable-spinlocks; it's
> >> really of pretty marginal use (how often does anyone port PG to a new
> >> CPU type?) and the
Noah Misch writes:
> On Fri, Jun 05, 2020 at 12:17:54PM -0400, Tom Lane wrote:
>> as you have it, I'd prefer to use
>> - fun:pg_comp_crc32c
>> + fun:pg_comp_crc32c_sb8
>> which precisely matches what 4f700bc did. The other way seems like
>> it's giving a free pass to problems that cou
On Fri, Jun 05, 2020 at 12:17:54PM -0400, Tom Lane wrote:
> Noah Misch writes:
> > I can reproduce this on a 2017-vintage CPU with ./configure
> > ... USE_SLICING_BY_8_CRC32C=1 and then running "make installcheck-parallel"
> > under valgrind-3.15.0 (as packaged by RHEL 7.8). valgrind.supp has a
>
Andres Freund writes:
> On 2020-06-05 21:01:56 -0400, Tom Lane wrote:
>> At some point I think we'll have to give up --disable-spinlocks; it's
>> really of pretty marginal use (how often does anyone port PG to a new
>> CPU type?) and the number of weird interactions it adds in this area
>> seems l
Hi,
On 2020-06-05 18:39:28 -0700, Jeff Davis wrote:
> On Fri, 2020-06-05 at 14:49 -0700, Andres Freund wrote:
> > FWIW, with gcc 10 and glibc 2.30 I don't see such a switch. Taking a
> > profile shows me:
>
> ...
>
> > 4.65 │ → callqmemcpy@plt
> >│ LogicalTapeWrite(
Hi,
On 2020-06-05 21:01:56 -0400, Tom Lane wrote:
> > I'm not really sure what to do about that issue. The easisest thing
> > would probably be to change the barrier generation to 32bit (which
> > doesn't have to use locks for reads in any situation).
>
> Yeah, I think we need a hard rule that you
On Fri, 2020-06-05 at 21:50 -0400, Tom Lane wrote:
> Or possibly casting the whole thing to int or unsigned int would be
> better. Point being that I bet it's int vs long that is making the
> difference.
That did it, and it's much more tolerable as a workaround. Thank you.
I haven't tested end-t
Jeff Davis writes:
> On Thu, 2020-06-04 at 16:35 -0400, Alvaro Herrera wrote:
>> If it is something worth worrying about, let's discuss what's a good
>> fix for it.
> While making a minimal test case for the GCC bug report, I found
> another surprisingly-small workaround. Patch attached.
Ugh :-(
On Thu, 2020-06-04 at 16:35 -0400, Alvaro Herrera wrote:
> If it is something worth worrying about, let's discuss what's a good
> fix for it.
While making a minimal test case for the GCC bug report, I found
another surprisingly-small workaround. Patch attached.
Regards,
Jeff Davis
diff -
On Fri, 2020-06-05 at 14:49 -0700, Andres Freund wrote:
> FWIW, with gcc 10 and glibc 2.30 I don't see such a switch. Taking a
> profile shows me:
...
> 4.65 │ → callqmemcpy@plt
>│ LogicalTapeWrite():
>
> I.e. normal memcpy is getting called.
>
> That's with -D_FOR
On Thu, 2020-06-04 at 21:41 -0400, Tom Lane wrote:
> I think what'd make more sense is to file this as a gcc bug ("why
> doesn't
> it remove the useless object size check?")
Filed:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95556
Regards,
Jeff Davis
Andres Freund writes:
> I wrote a patch for this, and when I got around to to testing it, I
> found that our tests currently don't pass when using both
> --disable-spinlocks and --disable-atomics. Turns out to not be related
> to the issue above, but the global barrier support added in 13.
> That
Greetings,
* Tomas Vondra (tomas.von...@2ndquadrant.com) wrote:
> I wonder if we can collect some stats to measure how effective the
> prefetching actually is. Ultimately we want something like cache hit
> ratio, but we're only preloading into page cache, so we can't easily
> measure that. Perhaps
Hi,
On 2020-06-04 19:33:02 -0700, Andres Freund wrote:
> But it looks like that code is currently buggy (and looks like it always
> has been), because we don't look at the nested argument when
> initializing the semaphore. So we currently allocate too many
> semaphores, without benefiting from th
On Fri, Jun 05, 2020 at 06:51:34PM -0400, Alvaro Herrera wrote:
On 2020-Jun-06, Tomas Vondra wrote:
On Fri, Jun 05, 2020 at 05:19:43PM -0400, Alvaro Herrera wrote:
> Is this patch the only thing missing before this open item can be
> considered closed?
I've already pushed this as 4cad2534da6d
On 2020-Jun-06, Tomas Vondra wrote:
> On Fri, Jun 05, 2020 at 05:19:43PM -0400, Alvaro Herrera wrote:
>
> > Is this patch the only thing missing before this open item can be
> > considered closed?
>
> I've already pushed this as 4cad2534da6d17067d98cf04be2dfc1bda8f2cd0,
> sorry for not mentioning
Hi,
I wonder if we can collect some stats to measure how effective the
prefetching actually is. Ultimately we want something like cache hit
ratio, but we're only preloading into page cache, so we can't easily
measure that. Perhaps we could measure I/O timings in redo, though?
regards
--
Tomas
On Fri, Jun 05, 2020 at 05:19:43PM -0400, Alvaro Herrera wrote:
Hello
Is this patch the only thing missing before this open item can be
considered closed?
I've already pushed this as 4cad2534da6d17067d98cf04be2dfc1bda8f2cd0,
sorry for not mentioning it in this thread explicitly.
regards
--
Hi,
On 2020-04-19 15:07:22 -0700, Jeff Davis wrote:
> I brought up an issue where GCC in combination with FORTIFY_SOURCE[2]
> causes a perf regression for logical tapes after introducing
> LogicalTapeSetExtend()[3]. Unfortunately, FORTIFY_SOURCE is used by
> default on ubuntu. I have not observed
Hello
Is this patch the only thing missing before this open item can be
considered closed?
Thanks
--
Álvaro Herrerahttps://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
On Sat, Jun 6, 2020 at 8:41 AM Tomas Vondra
wrote:
> BTW in all three cases it happens right after the first restart point in
> the WAL stream:
>
> LOG: restored log file "0001010800FD" from archive
> LOG: restartpoint starting: time
> LOG: restored log file "0001000
On 6/4/20 5:20 PM, Alvaro Herrera wrote:
> On 2020-May-28, Joe Conway wrote:
>
>> I backpatched and pushed the changes to the repeat() function. Any other
>> opinions regarding backpatch of the unlikely() addition to
>> CHECK_FOR_INTERRUPTS()?
>
> We don't use unlikely() in 9.6 at all, so I woul
On Fri, Jun 05, 2020 at 10:04:14PM +0200, Tomas Vondra wrote:
On Fri, Jun 05, 2020 at 05:20:52PM +0200, Tomas Vondra wrote:
...
which is not particularly great, I guess. There however seems to be
something wrong, because with the prefetching I see this in the log:
prefetch:
2020-06-05 02:47:2
On Fri, Jun 05, 2020 at 05:20:52PM +0200, Tomas Vondra wrote:
...
which is not particularly great, I guess. There however seems to be
something wrong, because with the prefetching I see this in the log:
prefetch:
2020-06-05 02:47:25.970 CEST 1591318045.970 [22961] LOG: recovery no
longer pref
Hi,
On 2020-06-05 15:25:26 +0200, Tomas Vondra wrote:
> I think you're right. I think I was worried about having to resize the
> hash table in case of an under-estimate, and it seemed fine to waste a
> tiny bit more memory to prevent that.
It's pretty cheap to resize a hashtable with a handful of
"David G. Johnston" writes:
>> On Fri, Jun 05, 2020 at 09:56:54AM -0400, Tom Lane wrote:
>>> That's not "garbage", I put it there intentionally.
> I don't see where having the row counts in the output adds clarity and it
> just more text for the reader to mentally filter out.
Seems like I'm gett
Noah Misch writes:
> I can reproduce this on a 2017-vintage CPU with ./configure
> ... USE_SLICING_BY_8_CRC32C=1 and then running "make installcheck-parallel"
> under valgrind-3.15.0 (as packaged by RHEL 7.8). valgrind.supp has a
> suppression for CRC calculations, but it didn't get the memo when
Hello,
Currently, in case of alternative subplans that do hashed vs per-row
lookups,
the per-row estimate is used when planning the rest of the query.
It's also coded in not quite an explicit way.
In [1] we found a situation where it leads to a suboptimal plan,
as it bloats the overall cost in
Peter Eisentraut writes:
> This is a patch to make use of RELKIND_HAS_STORAGE() where appropriate,
> instead of listing out the relkinds individually. No behavior change is
> intended.
> This was originally part of the patch from [0], but it seems worth
> moving forward independently.
Passes
On 2020-Jun-05, Dave Cramer wrote:
> On Thu, 4 Jun 2020 at 19:46, Alvaro Herrera
> wrote:
> > Ouch ... so they made IDENT in the replication grammar be a trigger to
> > enter the regular grammar. Crazy. No way to put those worms back in
> > the tin now, I guess.
>
> Is that documented ?
I do
On Fri, Jun 5, 2020 at 8:38 AM Tomas Vondra
wrote:
> On Fri, Jun 05, 2020 at 09:56:54AM -0400, Tom Lane wrote:
> >Pavel Stehule writes:
> >> diff --git a/doc/src/sgml/func.sgml b/doc/src/sgml/func.sgml
> >> index 7c06afd3ea..3b810c0eb4 100644
> >> --- a/doc/src/sgml/func.sgml
> >> +++ b/doc/src/
On Fri, Jun 05, 2020 at 09:56:54AM -0400, Tom Lane wrote:
Pavel Stehule writes:
diff --git a/doc/src/sgml/func.sgml b/doc/src/sgml/func.sgml
index 7c06afd3ea..3b810c0eb4 100644
--- a/doc/src/sgml/func.sgml
+++ b/doc/src/sgml/func.sgml
@@ -17821,7 +17821,6 @@ SELECT NULLIF(value, '(none)') ...
Hi,
I've spent some time testing this, mostly from the performance point of
view. I've done a very simple thing, in order to have reproducible test:
1) I've initialized pgbench with scale 8000 (so ~120GB on a machine with
only 64GB of RAM)
2) created a physical backup, enabled WAL archiving
Pavel Stehule writes:
> diff --git a/doc/src/sgml/func.sgml b/doc/src/sgml/func.sgml
> index 7c06afd3ea..3b810c0eb4 100644
> --- a/doc/src/sgml/func.sgml
> +++ b/doc/src/sgml/func.sgml
> @@ -17821,7 +17821,6 @@ SELECT NULLIF(value, '(none)') ...
> 1
> 2
>
> -(2 rows in result)
>
Hello Bruce,
Hmmm. This seels to suggest that interacting with something outside
should be an option.
Our goal is not to implement every possible security idea someone has,
because we will never finish, and the final result would be too complex
to be unable.
Sure. I'm trying to propose some
On Thu, Jun 04, 2020 at 06:57:58PM -0700, Andres Freund wrote:
Hi,
On 2020-06-04 18:22:03 -0700, Jeff Davis wrote:
On Thu, 2020-06-04 at 11:41 -0700, Andres Freund wrote:
> +/* minimum number of initial hash table buckets */
> +#define HASHAGG_MIN_BUCKETS 256
>
>
> I don't really see much expla
On 2020/06/05 15:22, Michael Paquier wrote:
On Wed, Jun 03, 2020 at 10:10:21PM +0900, Inoue, Hiroshi wrote:
On 2020/06/03 11:14, Michael Paquier wrote:
I have been looking at the ODBC driver and the need for currtid() as
well as currtid2(), and as mentioned already in [1], matching with my
lo
On Thu, 4 Jun 2020 at 19:46, Alvaro Herrera
wrote:
> On 2020-Jun-04, Andres Freund wrote:
>
> > postgres[52656][1]=# SELECT 1;
> > ┌──┐
> > │ ?column? │
> > ├──┤
> > │1 │
> > └──┘
> > (1 row)
> >
> >
> > I am very much not in love with the way that was implemented,
I've modified my previous patch because it linked the wrong document so I
fixed it. and I add a highlight to the encoding list for readability.
What do you think about this change?
Thanks,
Dong Wook
2020년 6월 4일 (목) 오후 10:20, 이동욱 님이 작성:
> To let users know what kind of character set
> can be use
Hi hackers,
> # Page storage(Plan C)
>
> Further, since the size of the compress address file is fixed, the above
> address file and data file can also be combined into one file
>
> 0 1 2 1230710 1 2
> +===+===+===+ +===+=+=
Hi
diff --git a/doc/src/sgml/func.sgml b/doc/src/sgml/func.sgml
index 7c06afd3ea..3b810c0eb4 100644
--- a/doc/src/sgml/func.sgml
+++ b/doc/src/sgml/func.sgml
@@ -17821,7 +17821,6 @@ SELECT NULLIF(value, '(none)') ...
1
2
-(2 rows in result)
Regards
Pavel
Hi
čt 4. 6. 2020 v 11:49 odesílatel movead...@highgo.ca
napsal:
> +{ oid => '2228', descr => 'split delimited text',
> + proname => 'string_to_table', prorows => '1000', proretset => 't',
> + prorettype => 'text', proargtypes => 'text text',
> + prosrc => 'text_to_table' },
> +{ oid => '2282'
On 2020-05-30 11:29, Peter Eisentraut wrote:
I suggest to update the test data in PG13+, since we require OpenSSL
1.0.1 there. For the older branches, I would look into changing the
test driver setup so that it loads a custom openssl.cnf that loads the
legacy providers.
I have pushed your 0002
This is a patch to make use of RELKIND_HAS_STORAGE() where appropriate,
instead of listing out the relkinds individually. No behavior change is
intended.
This was originally part of the patch from [0], but it seems worth
moving forward independently.
[0]:
https://www.postgresql.org/messag
On Fri, Jun 05, 2020 at 06:03:59PM +1200, Thomas Munro wrote:
> I didn't change BufFileWrite() to be void, to be friendly to existing
> callers outside the tree (if there are any), though I removed all the
> code that checks the return code. We can make it void later.
Missing one entry in AppendS
On Sun, May 10, 2020 at 09:29:05AM -0400, Andrew Dunstan wrote:
> On 4/18/20 9:15 AM, Andrew Dunstan wrote:
> > I was just trying to revive lousyjack, my valgrind buildfarm animal
> > which has been offline for 12 days, after having upgraded the machine
> > (fedora 31, gcc 9.3.1, valgrind 3.15) and
On Mon, Jun 01, 2020 at 10:44:17AM +0200, Peter Eisentraut wrote:
> Then we can stick a OPENSSL_API_COMPAT=908 into at least PG10, 11, and 12,
> and probably also into PG9.5 and 9.6 without harm.
FWIW, I am fine that for PG >= 10, and I don't think that it is worth
bothering with PG <= 9.6.
--
Mic
50 matches
Mail list logo
