Re: [HACKERS] sketchy partcollation handling
On 6 June 2017 at 09:19, Robert Haaswrote: > > Thanks. Committed. > The changes to catalogs.sgml has introduced a double "the" in this part of the sentence "this contains the OID of the the collation". The other section already had the double "the".
Re: [HACKERS] proposal: Set effective_cache_size to greater of .conf value, shared_buffers
The patch contains a small typo in config.sgml. Probably just drop the is from is can. +results if this database cluster is can utilize most of the memory Kevin. On 8 October 2013 10:13, Bruce Momjian br...@momjian.us wrote: On Thu, Sep 5, 2013 at 05:14:37PM -0400, Bruce Momjian wrote: On Thu, Sep 5, 2013 at 06:14:33PM +0200, Magnus Hagander wrote: I have developed the attached patch which implements an auto-tuned effective_cache_size which is 4x the size of shared buffers. I had to set effective_cache_size to its old 128MB default so the EXPLAIN regression tests would pass unchanged. That's not really autotuning though. ISTM that making the *default* 4 x shared_buffers might make perfect sense, but do we really need to hijack the value of -1 for that? That might be useful for some time when we have actual autotuning, that somehow inspects the system and tunes it from there. I also don't think it should be called autotuning, when it's just a smarter default value. I like the feature, though, just not the packaging. That auto-tuning text came from the wal_buffer documentation, which does exactly this based on shared_buffers: The contents of the WAL buffers are written out to disk at every transaction commit, so extremely large values are unlikely to provide a significant benefit. However, setting this value to at least a few megabytes can improve write performance on a busy -- server where many clients are committing at once. The auto-tuning --- selected by the default setting of -1 should give reasonable results in most cases. I am fine with rewording and not using -1, but we should change the wal_buffer default and documentation too then. I am not sure what other value than -1 to use? 0? I figure if we ever get better auto-tuning, we would just remove this functionality and make it better. Patch applied with a default of 4x shared buffers. I have added a 9.4 TODO that we might want to revisit this. -- Bruce Momjian br...@momjian.ushttp://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to be true. + -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] [COMMITTERS] pgsql: Add DISCARD SEQUENCES command.
My C is very rusty but the traversal of SeqTableData doesn't seem correct. It saves the seqtab-next pointer into next, frees seqtab and then dereferences it. Shouldn't that last line be: seqtab = next? Kevin. +/* + * Flush cached sequence information. + */ +void +ResetSequenceCaches(void) +{ + SeqTableData *next; + + while (seqtab != NULL) + { + next = seqtab-next; + free(seqtab); + seqtab = seqtab-next; + } On 3 October 2013 14:23, Robert Haas rh...@postgresql.org wrote: Add DISCARD SEQUENCES command. DISCARD ALL will now discard cached sequence information, as well. Fabrízio de Royes Mello, reviewed by Zoltán Böszörményi, with some further tweaks by me. Branch -- master Details --- http://git.postgresql.org/pg/commitdiff/d90ced8bb22194cbb45f58beb0961251103aeff5 Modified Files -- doc/src/sgml/ref/discard.sgml | 12 +++- src/backend/commands/discard.c |8 +++- src/backend/commands/sequence.c| 16 src/backend/parser/gram.y |9 - src/backend/tcop/utility.c |3 +++ src/bin/psql/tab-complete.c|2 +- src/include/commands/sequence.h|1 + src/include/nodes/parsenodes.h |1 + src/test/regress/expected/sequence.out |3 +++ src/test/regress/sql/sequence.sql |2 ++ 10 files changed, 53 insertions(+), 4 deletions(-) -- Sent via pgsql-committers mailing list (pgsql-committ...@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-committers
[HACKERS] [COMMITTERS] pgsql: Add new GUC, max_worker_processes, limiting number of bgworkers.
The change to config.sgml contains a small typo with the double r in the xreflabel. + varlistentry id=guc-max-worker-processes xreflabel=max_worrker_processes
Re: [HACKERS] [DOCS] Contrib module xml2 status
On 24 February 2013 13:46, Peter Eisentraut pete...@gmx.net wrote: done The patch included the word 'so' in the email address by accident.