initdb help message about WAL segment size

I propose the attached patch, aligning the help message with the docs. Any reason not to? (yes, I confused myself by trying --wal-segsize=1MB instead of just --wal-segsize=1. I blame just stepping off an intercontinental flight and a very early morning :P) -- Magnus Hagander Me:

Re: Parallel Aggregates for string_agg and array_agg

On 11 March 2018 at 12:11, Tomas Vondra wrote: > On 03/05/2018 04:51 AM, David Rowley wrote: >> On 5 March 2018 at 04:54, Tomas Vondra wrote: >> Consider the following slightly backward-looking case; >> >> select string_agg(',',

Re: [HACKERS] MERGE SQL Statement for PG11

On Sat, Mar 10, 2018 at 9:22 PM, Pavan Deolasee wrote: > Ok. I will look at it. I think it shouldn't be too difficult and the > original restriction was mostly a fallout of expecting CHECK constraint > style expressions there. Good, thanks. > Ok. OVERRIDING is done. I

Re: Faster inserts with mostly-monotonically increasing values

On Sat, Mar 10, 2018 at 12:11 AM, Claudio Freire wrote: > On Fri, Mar 9, 2018 at 2:54 PM, Pavan Deolasee > wrote: > > > > > > > > > So yes, the benefits of the patch go down with higher number of clients, > but > > it does not entirely vanish. >

Re: [HACKERS] MERGE SQL Statement for PG11

On Sun, Mar 11, 2018 at 9:27 AM, Peter Geoghegan wrote: > > >> > >> We're talking about the scantuple here. It's not like excluded.*. > > I often care about things like system columns not because of the > user-visible functionality, but because it reassures me that the > design is

Re: [HACKERS] MERGE SQL Statement for PG11

On Fri, Mar 9, 2018 at 6:55 AM, Pavan Deolasee wrote: >> * Is this actually needed at all?: >> >> > + /* In MERGE when and condition, no system column is allowed */ >> > + if (pstate->p_expr_kind == EXPR_KIND_MERGE_WHEN_AND && >> > + attnum <

Re: disable SSL compression?

On 3/9/18 09:06, Magnus Hagander wrote: > What platform does that actually work out of the box on? I have > customers who actively want to use it (for compression, not security -- > replication across limited and metered links), and the amount of > workarounds they have to put in place OS level to

Re: VACUUM FULL vs dropped columns

On Sun, Mar 11, 2018 at 9:49 AM, Tom Lane wrote: > Andrew Dunstan writes: >> Why does VACUUM FULL cause the size of this table with a single >> dropped column (1 out of 1000) cause the table size to double? > > VACUUM FULL will rewrite the

Re: VACUUM FULL vs dropped columns

Andrew Dunstan writes: > Why does VACUUM FULL cause the size of this table with a single > dropped column (1 out of 1000) cause the table size to double? VACUUM FULL will rewrite the tuples with a null bitmap where they had none before (cf

Re: Parallel Aggregates for string_agg and array_agg

On 03/05/2018 04:51 AM, David Rowley wrote: > On 5 March 2018 at 04:54, Tomas Vondra wrote: >> 1) There seems to be forgotten declaration of initArrayResultInternal in >> arrayfuncs.c. I suppose you've renamed it to initArrayResultWithSize and >> moved it to a

Intermittent pg_ctl failures on Windows

The buildfarm's Windows members occasionally show weird pg_ctl failures, for instance this recent case: https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=bowerbird=2018-03-10%2020%3A30%3A20 ### Restarting node "master" # Running: pg_ctl -D

VACUUM FULL vs dropped columns

While doing some testing I noticed this, which seems somewhat perverse: create table t(); insert into t select from generate_series(1,1); select 'alter table t ' || string_agg(' add column c'||x::text||' int default ' ||x::text,',') from generate_series(1,1000) x \gexec create table

Re: Bogus use of canonicalize_qual

I wrote: > Whilst fooling about with predtest.c, I noticed a rather embarrassing > error. Consider the following, rather silly, CHECK constraint: > ... > So, what to do? We have a few choices, none ideal: I'd been assuming that we need to back-patch a fix for this, but after further reflection,

Re: [PROPOSAL] timestamp informations to pg_stat_statements

On 03/10/2018 04:43 PM, legrand legrand wrote: > +1 > Having the time of first occurence of a statement is very usefull > for trouble shouting, it permits for exemple to retrieve the order of > operations in some complex cases (and thoses informations aren't > taken by any third party collecting

Re: [RFC] What would be difficult to make data models pluggable for making PostgreSQL a multi-model database?

I just came across the following paper and project and thought I would share: It seems some incremental graph query extensions to SQL could add some powerful capabilities to PostgreSQL (without having to think about a complete query language replacement). The incremental change could include:

Re: All Taxi Services need Index Clustered Heap Append

Hello, Would the following custom solution: - a pre-loaded table rows being sorted by id and ts containing null values for other columns, enough free space per block to permit updates in place, - having a (btree or brin) index on (id,ts), - loaded using UPDATEs in spite of INSERTs

Re: [HACKERS] [PATCH] Incremental sort

On Sat, Mar 10, 2018 at 6:42 PM, Alexander Korotkov < a.korot...@postgrespro.ru> wrote: > On Thu, Mar 8, 2018 at 2:49 AM, Tomas Vondra > wrote: > Thank you very much for testing and benchmarking. I'll investigate > the regressions you found. > > >> Now, there's a

Re: [HACKERS] [PATCH] Incremental sort

On Thu, Mar 8, 2018 at 2:49 AM, Tomas Vondra wrote: > OK, the revised patch works fine - I've done a lot of testing and > benchmarking, and not a single segfault or any other crash. > > Regarding the benchmarks, I generally used queries of the form > > SELECT *

Re: [PROPOSAL] timestamp informations to pg_stat_statements

+1 Having the time of first occurence of a statement is very usefull for trouble shouting, it permits for exemple to retrieve the order of operations in some complex cases (and thoses informations aren't taken by any third party collecting tool, that will only be able to provide a time range of

Re: Online enabling of checksums

Hi, I had a closer look at v3 of the patch now. On Sat, Mar 03, 2018 at 07:23:31PM +0100, Magnus Hagander wrote: > Attached is a rebased patch which removes this optimization, updates the > pg_proc entry for the new format, and changes pg_verify_checksums to use -r > instead of -o for

Re: [HACKERS] GUC for cleanup indexes threshold.

On Fri, Mar 9, 2018 at 9:40 PM, Alexander Korotkov < a.korot...@postgrespro.ru> wrote: > On Fri, Mar 9, 2018 at 3:12 PM, Masahiko Sawada > wrote: > >> Attached an updated patch >> > fixed these issue. Will review the patch again. > > > Thank you! > I've fixed a bug:

Re: [WIP PATCH] Index scan offset optimisation using visibility map

Hello. Andrey, Tels - thanks for review. > It could be named "SkipTuples" (e.g. this is the number of tuples we need > to skip, not the number we have skipped), and the other one then > "iss_SkipTuplesRemaining" so they are consistent with each other. Agreed, done. > Also, I think that this

Re: [HACKERS] PATCH: multivariate histograms and MCV lists

On 03/10/2018 02:08 PM, Mark Dilger wrote: > >> On Mar 3, 2018, at 2:40 PM, Tomas Vondra >> wrote: >> >> An updated patch version, fixing the breakage caused by fd1a421fe6 >> twiddling with pg_proc. > > Hi Tomas, thanks again for this most useful patch! > >

Re: Sample values for pg_stat_statements

Hi, I've looked at this patch today. I like the idea / intent in general, as it helps with some investigation tasks. That being said, I have a couple of questions/comments based on read through the patch: 1) I see you've renamed the .sql script from 1.4 to 1.6. I thought we've abandoned that

Re: disable SSL compression?

On 9 March 2018 at 14:17, Gasper Zejn wrote: > On 09. 03. 2018 06:24, Craig Ringer wrote: > > I'm totally unconvinced by the threat posed by exploiting a client by > tricking it into requesting protocol compression - or any other protocol > change the client lib doesn't

Re: [HACKERS] PATCH: multivariate histograms and MCV lists

> On Mar 3, 2018, at 2:40 PM, Tomas Vondra wrote: > > An updated patch version, fixing the breakage caused by fd1a421fe6 > twiddling with pg_proc. Hi Tomas, thanks again for this most useful patch! Perhaps this is intentional, but there seems to be a place in

Re: Concurrency bug in UPDATE of partition-key

On Thu, Mar 8, 2018 at 4:55 PM, Amit Khandekar wrote: > (Mail subject changed; original thread : [1]) > > On 8 March 2018 at 11:57, Amit Khandekar wrote: >>> Clearly, ExecUpdate() while moving rows between partitions is missing out on >>>

Re: Online enabling of checksums

Hi, On Mon, Mar 05, 2018 at 11:09:02AM +0100, Magnus Hagander wrote: > On Mon, Mar 5, 2018 at 10:43 AM, Michael Banck > wrote: > > I still find that confusing, but maybe it's just me. I thought the one > > in the pageheader is the "expected" checksum, and we compare

Re: remove pg_class.relhaspkey

On 02/26/2018 07:23 AM, Michael Paquier wrote: > On Mon, Feb 26, 2018 at 12:45:48AM -0500, Tom Lane wrote: >> Michael Paquier writes: >>> On Sat, Feb 24, 2018 at 10:21:44PM -0500, Tom Lane wrote: We've discussed that at least twice before, and not pulled the trigger

Re: [HACKERS] Restrict concurrent update/delete with UPDATE of partition key

On Fri, Mar 9, 2018 at 3:18 PM, amul sul wrote: > On Thu, Mar 8, 2018 at 12:31 PM, Amit Kapila wrote: >> On Thu, Mar 8, 2018 at 11:04 AM, Pavan Deolasee >> >>> This is just one example. I am almost certain there are many such cases that >>> will

Re: using index or check in ALTER TABLE SET NOT NULL

Hello My patch does not apply after commit 5748f3a0aa7cf78ac6979010273bd9d50869bb8e. Here is update to current master. Not null constraint is immutable too, so here is no changes in PartConstraintImpliedByRelConstraint excepts rename and comments fix. In this patch version i also revert tests

Re: Fixes for missing schema qualifications

On Fri, Mar 09, 2018 at 04:55:38PM +0900, Michael Paquier wrote: > --- a/src/backend/catalog/information_schema.sql > +++ b/src/backend/catalog/information_schema.sql > @@ -186,7 +186,7 @@ CREATE FUNCTION _pg_interval_type(typid oid, mod int4) > RETURNS text > AS > $$SELECT >CASE WHEN

Re: Fixes for missing schema qualifications

On Fri, Mar 09, 2018 at 09:35:22AM -0500, David Steele wrote: > These look sane to me. Did you check the back branches for anything > that might not exist in HEAD? I did, but I have not spotted anything extra. Impossible to say that I did not miss one though, such scanning is tiring. -- Michael