Re: [HACKERS] increasing the default WAL segment size

Hello, Attached is the updated patch. It fixes the issues and also updates few code comments. On Fri, Mar 10, 2017 at 1:09 PM, tushar wrote: > > > 1)at the time of initdb, we have set - "--wal-segsize 4" ,so all the WAL > file size should be 4 MB each but in the

Re: [HACKERS] Performance improvement for joins where outer side is unique

On 14 March 2017 at 11:35, David Rowley wrote: > On 14 March 2017 at 07:50, Tom Lane wrote: > >> [ getting back to this patch finally... ] >> >> David Rowley writes: >> > I've attached a patch which implements

[HACKERS] ToDo: listagg is in ANSI/SQL:2016

Hi looks like Oracle has pretty strong position in standard. ANSI SQL has new aggregate function listagg. It is supported by DB2 too. Unfortunately one supported syntax is not possible in Postgres due our design of ordered aggregates. Syntax: 1. listagg(expr) FROM ... not deterministic result

Re: [HACKERS] PATCH: pageinspect / add page_checksum and bt_page_items(bytea)

Hi, > >> 2) It seems like you have choosen wrong datatype for page_checksum. I >> am getting negative checksum value when trying to run below query. I >> think the return type for the SQL function page_checksum should be >> 'integer' instead of 'smallint'. >> >> postgres=# SELECT

Re: [HACKERS] scram and \password

On Tue, Mar 14, 2017 at 12:34 PM, Tom Lane wrote: > Michael Paquier writes: > If some other practice becomes better in v12, then we teach it about that > one. It's not like psql hasn't got many other server-version-dependent > behaviors. Okay.

Re: [HACKERS] Write Ahead Logging for Hash Indexes

On Mon, Mar 13, 2017 at 6:26 PM, Amit Kapila wrote: > On Thu, Mar 9, 2017 at 3:11 AM, Robert Haas wrote: >> On Tue, Mar 7, 2017 at 6:41 PM, Robert Haas wrote: > Great, thanks. 0001 looks good to me now, so committed.

Re: [HACKERS] [COMMITTERS] pgsql: Improve postmaster's logging of listen socket creation.

Andres Freund writes: > I don't mind the new output, but I kinda wonder whether it's a good idea > to include the '.s.PGSQL.5432' bit in the host and/or whether we > shouldn't include the port in the TCP cases as well Yeah, I've been thinking that maybe it should look like

Re: [HACKERS] [COMMITTERS] pgsql: Improve postmaster's logging of listen socket creation.

On 2017-03-13 10:12:42 -0400, Robert Haas wrote: > So now on every startup I get this: > > 2017-03-13 10:08:49.399 EDT [90059] LOG: listening on IPv6 address "::1" > 2017-03-13 10:08:49.399 EDT [90059] LOG: listening on IPv4 address > "127.0.0.1" > 2017-03-13 10:08:49.400 EDT [90059] LOG:

Re: [HACKERS] scram and \password

Michael Paquier writes: > On Tue, Mar 14, 2017 at 11:47 AM, Tom Lane wrote: >> Seems to me the intended behavior of \password is to use the best >> available practice. So my guess is that it ought to use SCRAM when >> talking to a >= 10.0 server.

Re: [HACKERS] scram and \password

On Tue, Mar 14, 2017 at 11:47 AM, Tom Lane wrote: > Robert Haas writes: >> I'm not talking about changing the default, just having it be possible >> to use \password with the new system as it was with the old, whatever >> exactly we think that means. I

[HACKERS] Unacccented Fractions

Hello Hackers, I noticed that unaccent.rules has spaces in front of the unaccented representation of fraction glyphs: ¼1/4 ½1/2 ¾3/4 Note the space after the tab. In case my client kills what I’ve pasted, those lines match ¼\t[ ]1/4 ½\t[ ]1/2 ¾\t[ ]3/4 This makes

Re: [HACKERS] scram and \password

Robert Haas writes: > I'm not talking about changing the default, just having it be possible > to use \password with the new system as it was with the old, whatever > exactly we think that means. Seems to me the intended behavior of \password is to use the best available

Re: [HACKERS] scram and \password

On Sun, Mar 12, 2017 at 11:14 PM, Michael Paquier wrote: > On Mon, Mar 13, 2017 at 9:15 AM, Robert Haas wrote: >> On Fri, Mar 10, 2017 at 5:43 PM, Michael Paquier >> wrote: >>> On Sat, Mar 11, 2017 at 2:53 AM, Jeff

Re: [HACKERS] [PATCH] Transaction traceability - txid_status(bigint)

On 14 March 2017 at 05:43, Robert Haas wrote: > For example, suppose vacuum #1 comes along, advances the limits, > truncates clog, and then gets descheduled. Now vacuum #2 comes along, > advances the limits further, and then gets descheduled. Now vacuum #1 > wakes up and

Re: [HACKERS] Patch: Write Amplification Reduction Method (WARM)

> @@ -234,6 +236,21 @@ index_beginscan(Relation heapRelation, > scan->heapRelation = heapRelation; > scan->xs_snapshot = snapshot; > > + /* > + * If the index supports recheck, make sure that index tuple is saved > + * during index scans. > + * > + * XXX

Re: [HACKERS][REVIEW] macaddr 64 bit (EUI-64) datatype support

On Mon, Mar 13, 2017 at 6:52 AM, Stephen Frost wrote: > Greetings, > > * Stephen Frost (sfr...@snowman.net) wrote: > > * Stephen Frost (sfr...@snowman.net) wrote: > > > * Haribabu Kommi (kommi.harib...@gmail.com) wrote: > > > > On Wed, Feb 1, 2017 at 6:27 AM, Vitaly Burovoy <

Re: [HACKERS] asynchronous execution

On 2017/03/14 10:08, Corey Huinker wrote: >> I don't think the plan itself will change as a result of applying this >> patch. You might however be able to observe some performance improvement. > > I could see no performance improvement, even with 16 separate queries > combined with UNION ALL.

Re: [HACKERS][REVIEW] macaddr 64 bit (EUI-64) datatype support

On Mon, Mar 13, 2017 at 6:38 AM, Stephen Frost wrote: > Greetings, > > * Stephen Frost (sfr...@snowman.net) wrote: > > * Haribabu Kommi (kommi.harib...@gmail.com) wrote: > > > On Wed, Feb 1, 2017 at 6:27 AM, Vitaly Burovoy < > vitaly.buro...@gmail.com> wrote: > > > > The new

[HACKERS] Updating the "tool sets" documentation for modern FreeBSD

Hi, For several operating systems we give handy package manager one-liners to install all the requirements for building our documentation. All current production FreeBSD releases have a friendly new package manager a bit like apt/yum, so here's a documentation patch to give the one line command.

Re: [HACKERS] tuplesort_gettuple_common() and *should_free argument

On Wed, Jan 25, 2017 at 3:11 PM, Peter Geoghegan wrote: > On Wed, Jan 25, 2017 at 3:11 PM, Tom Lane wrote: >> Please. You might want to hit the existing ones with a separate patch, >> but it doesn't much matter; I'd be just as happy with a patch that did >>

Re: [HACKERS] WIP: Faster Expression Processing v4

Hi, On 2017-03-13 01:03:51 -0700, Andres Freund wrote: > What's basically missing here is: > - pgindent run and minimizing resulting damage Running into a bit of an issue here - pgindent mangles something like EEO_SWITCH (op->opcode) { EEO_CASE(EEO_DONE): goto out;

Re: [HACKERS] asynchronous execution

> > I don't think the plan itself will change as a result of applying this > patch. You might however be able to observe some performance improvement. > > Thanks, > Amit > I could see no performance improvement, even with 16 separate queries combined with UNION ALL. Query performance was always

Re: [HACKERS] scram and \password

On Tue, Mar 14, 2017 at 9:54 AM, Joe Conway wrote: > On 03/12/2017 08:10 PM, Michael Paquier wrote: >> OK, so what about doing the following then: >> 1) Create pg_role_password_type(oid), taking a role OID in input and >> returning the type. > > That version would make sense

Re: [HACKERS] Partition-wise join for join between (declaratively) partitioned tables

On 2017/03/14 9:17, Robert Haas wrote: > On Mon, Mar 13, 2017 at 3:24 PM, Robert Haas wrote: >> Haven't looked at 0007 yet. > > Overall this one looks pretty good and straightforward. In the following code of find_partition_scheme(): + /* Did not find matching

Re: [HACKERS] scram and \password

On 03/12/2017 08:10 PM, Michael Paquier wrote: > OK, so what about doing the following then: > 1) Create pg_role_password_type(oid), taking a role OID in input and > returning the type. That version would make sense for administrative use. I still think we might want a version of this that takes

Re: [HACKERS] Should buffer of initialization fork have a BM_PERMANENT flag

On Tue, Mar 14, 2017 at 4:46 AM, Robert Haas wrote: > On Wed, Jan 25, 2017 at 7:14 PM, Michael Paquier > wrote: >> (Adding Robert in CC.) >> >> On Thu, Jan 26, 2017 at 4:34 AM, Wang Hao wrote: >>> An unlogged table has an

Re: [HACKERS] tuplesort_gettuple_common() and *should_free argument

On Wed, Jan 25, 2017 at 3:16 PM, Tom Lane wrote: > Um, I didn't find it all that self-explanatory. Why wouldn't we want > to avoid writing undefined data? For roughly the same reason we'd want to avoid it in existing cases that are next to the proposed new suppression. We

Re: [HACKERS] \h tab-completion

On 03/13/2017 03:56 PM, David Steele wrote: Do you know when you will have a new patch available for review that incorporates Peter's request? I believe I will find the time to finish it some time in a couple of days. Andreas -- Sent via pgsql-hackers mailing list

Re: [HACKERS] asynchronous execution

On 2017/03/14 6:31, Corey Huinker wrote: > On Mon, Mar 13, 2017 at 1:06 AM, Corey Huinker > wrote: > >> >>> I think it will, because Append itself has been made async-capable by one >>> of the patches and UNION ALL uses Append. But as mentioned above, only >>> the

Re: [HACKERS] Partition-wise join for join between (declaratively) partitioned tables

On Mon, Mar 13, 2017 at 3:24 PM, Robert Haas wrote: > Haven't looked at 0007 yet. + if (rel->part_scheme) + { + int cnt_parts; + + for (cnt_parts = 0; cnt_parts < nparts; cnt_parts++) +

Re: [HACKERS] Radix tree for character conversion

On Tue, Mar 14, 2017 at 4:07 AM, Heikki Linnakangas wrote: > On 03/13/2017 08:53 PM, Tom Lane wrote: >> Heikki Linnakangas writes: >>> >>> It would be nice to run the map_checker tool one more time, though, to >>> verify that the mappings match those from

Re: [HACKERS] Measuring replay lag

Hi, Please see separate replies to Simon and Craig below. On Sun, Mar 5, 2017 at 8:38 PM, Simon Riggs wrote: > On 1 March 2017 at 10:47, Thomas Munro wrote: >> I do see why a new user trying this feature for the first time might >> expect

Re: [HACKERS] Need a builtin way to run all tests faster manner

On 03/13/2017 07:21 PM, Andrew Dunstan wrote: > > On 03/13/2017 12:35 AM, Tom Lane wrote: >> Andres Freund writes: >>> On 2017-03-11 22:14:07 -0500, Tom Lane wrote: This looks generally sane to me, although I'm not very happy about folding the "$(MKDIR_P)

Re: [HACKERS] Need a builtin way to run all tests faster manner

On 03/13/2017 12:35 AM, Tom Lane wrote: > Andres Freund writes: >> On 2017-03-11 22:14:07 -0500, Tom Lane wrote: >>> This looks generally sane to me, although I'm not very happy about folding >>> the "$(MKDIR_P) output_iso" call into pg_isolation_regress_check --- that >>>

Re: [HACKERS] bytea_output vs make installcheck

Robert Haas writes: > On Thu, Mar 9, 2017 at 6:45 PM, Neha Khatri wrote: >> With this, if an installcheck is done, that might also have been done with >> the expectation that the output will be in 'escape' format. In that case, >> how much is it

Re: [HACKERS] Performance improvement for joins where outer side is unique

On 14 March 2017 at 07:50, Tom Lane wrote: > [ getting back to this patch finally... ] > > David Rowley writes: > > I've attached a patch which implements this, though only for > > MergeJoin, else I'd imagine we'd also need to ensure all proofs

Re: [HACKERS] tuplesort_gettuple_common() and *should_free argument

On Mon, Mar 13, 2017 at 8:23 AM, David Steele wrote: > It's been a while since there was a new patch or any activity on this > thread. > > If you need more time to produce a patch, please post an explanation for > the delay and a schedule for the new patch. If no patch or

Re: [HACKERS] [PATCH] Use $ parameters as replacement characters for pg_stat_statements

Robert Haas writes: > On Sat, Mar 4, 2017 at 1:52 PM, Peter Geoghegan wrote: >> I'd be in favor of a change >> that makes it easier to copy and paste a query, to run EXPLAIN and so >> on. Lukas probably realizes that there are no guarantees that the >> query

Re: [HACKERS] [PATCH] Transaction traceability - txid_status(bigint)

On Sat, Mar 11, 2017 at 1:32 AM, Craig Ringer wrote: > On 11 March 2017 at 05:09, Robert Haas wrote: >> On the other >> hand, there really are two separate notions of the "oldest" XID. >> There's the oldest XID that we can safely look up, and then

Re: [HACKERS] WIP: Faster Expression Processing v4

On 03/13/2017 09:03 AM, Andres Freund wrote: Hi, On 2017-03-12 05:40:51 +0100, Tomas Vondra wrote: I wanted to do a bit of testing and benchmarking on this, but 0004 seems to be a bit broken. Well, "broken" in the sense that it's already outdated, because other stuff that got merged. Yes,

Re: [HACKERS] asynchronous execution

On Mon, Mar 13, 2017 at 1:06 AM, Corey Huinker wrote: > >> I think it will, because Append itself has been made async-capable by one >> of the patches and UNION ALL uses Append. But as mentioned above, only >> the postgres_fdw foreign tables will be able to utilize this

Re: [HACKERS] \if, \elseif, \else, \endif (was Re: PSQL commands: \quit_if, \quit_unless)

"Daniel Verite" writes: > Tom Lane wrote: >> when we see \if is that we do nothing but absorb text >> until we see the matching \endif. At that point we could bitch and throw >> everything away if, say, there's \elif after \else, or anything else you >> want to regard as

Re: [HACKERS] \if, \elseif, \else, \endif (was Re: PSQL commands: \quit_if, \quit_unless)

Corey Huinker writes: >> Barring objection I'll push this so that Corey can rebase over it. > Seems straightforward, and I appreciate you doing it for me! Hearing no objections, pushed. regards, tom lane -- Sent via pgsql-hackers mailing list

Re: [HACKERS] [COMMITTERS] pgsql: Add amcheck extension to contrib.

Hi, On 2017-03-13 15:45:01 -0400, Tom Lane wrote: > I could be wrong, but the most obvious explanation for this failure is > that autovacuum had a lock on the table or index when we looked. > Even if that isn't why axolotl failed in this particular case, I think > it's dead certain that we will

[HACKERS] Silence perl warning in check-world

In some older versions of perl (like v5.10), I get a warning that: Use of implicit split to @_ is deprecated at src/test/recovery/t/ 006_logical_decoding.pl line 26. Splitting into a dummy variable silences that warning, as in the attached. There may be a better way to silence the warning.

Re: [HACKERS] make check-world output

On Fri, Mar 10, 2017 at 6:19 PM, Tom Lane wrote: > Alvaro Herrera writes: > > Jeff Janes wrote: > >> There was some recent discussion about making "make check-world" faster. > >> I'm all for that, but how about making it quieter? On both machines >

Re: [HACKERS] Allow pg_dumpall to work without pg_authid

Why this? + if (no_role_passwords && binary_upgrade) + { + fprintf(stderr, _("%s: options --no-role-passwords and --binary-upgrade cannot be used together\n"), + progname); + fprintf(stderr, _("Try \"%s --help\" for more

Re: [HACKERS] ANALYZE command progress checker

On Fri, Mar 10, 2017 at 2:57 PM, Jim Nasby wrote: > Oh, I wasn't suggesting a single SRF for everything. Hopefully users will > eventually figure out a good formula to drive a "progress bar" for each type > of monitor, which is what you really want anyway (at least 99% of

Re: [HACKERS] background sessions

On Sat, Mar 11, 2017 at 10:11 AM, Pavel Stehule wrote: > 2017-03-09 14:52 GMT+01:00 Peter Eisentraut > : >> >> On 3/8/17 14:22, Pavel Stehule wrote: >> > 1. will be background session process closed automatically when parent >> > process

Re: [HACKERS] Two phase commit in ECPG

> Previous 002 patch lacked to add describing PREPARE TRANSACTION. > Attached updated 002 patch. I just committed both patches and a backport of the bug fix itself. Thanks again for finding and fixing. Michael -- Michael Meskes Michael at Fam-Meskes dot De, Michael at Meskes dot

Re: [HACKERS] Should buffer of initialization fork have a BM_PERMANENT flag

On Wed, Jan 25, 2017 at 7:14 PM, Michael Paquier wrote: > (Adding Robert in CC.) > > On Thu, Jan 26, 2017 at 4:34 AM, Wang Hao wrote: >> An unlogged table has an initialization fork. The initialization fork does >> not have an BM_PERMANENT flag when

Re: [HACKERS] [COMMITTERS] pgsql: Add amcheck extension to contrib.

Andres Freund writes: > Add amcheck extension to contrib. axolotl just failed on this: https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=axolotl=2017-03-13%2017%3A49%3A24 *** *** 78,86 -- make sure we don't have any leftover locks SELECT * FROM

Re: [HACKERS] delta relations in AFTER triggers

Kevin Grittner wrote: > >> What is necessary to indicate an additional SQL feature covered? > > > > I assume you're talking about information_schema.sql_features > > I had forgotten we had that in a table. I was thinking more of the docs: > >

Re: [HACKERS] Partition-wise join for join between (declaratively) partitioned tables

On Fri, Mar 10, 2017 at 5:43 AM, Ashutosh Bapat wrote: > PFA the zip containing all the patches rebased on > 56018bf26eec1a0b4bf20303c98065a8eb1b0c5d and contain the patch to free > memory consumed by paths using a separate path context. Some very high-level

Re: [HACKERS] SQL/JSON in PostgreSQL

On 13.03.2017 07:24, Nico Williams wrote: On Thu, Mar 09, 2017 at 07:12:07PM +0100, Sven R. Kunze wrote: From my day-to-day work I can tell, the date(time) type is the only missing piece of JSON to make it perfect for business applications (besides, maybe, a "currency" type). And a binary

Re: [HACKERS] \if, \elseif, \else, \endif (was Re: PSQL commands: \quit_if, \quit_unless)

Tom Lane wrote: > when we see \if is that we do nothing but absorb text > until we see the matching \endif. At that point we could bitch and throw > everything away if, say, there's \elif after \else, or anything else you > want to regard as a "compile time error". Otherwise we start

Re: [HACKERS] SQL/JSON in PostgreSQL

On 10.03.2017 20:28, Josh Berkus wrote: On 03/09/2017 10:12 AM, Sven R. Kunze wrote: SaltStack uses YAML for their tools, too. I personally can empathize with them (as a user of configuration management) about this as writing JSON would be nightmare with all the quoting, commas, curly braces

Re: [HACKERS] Radix tree for character conversion

On 03/13/2017 08:53 PM, Tom Lane wrote: Heikki Linnakangas writes: It would be nice to run the map_checker tool one more time, though, to verify that the mappings match those from PostgreSQL 9.6. +1 Just to be sure, and after that the map checker can go to the dustbin.

Re: [HACKERS] WIP: [[Parallel] Shared] Hash

On Mon, Mar 13, 2017 at 8:40 PM, Rafia Sabih wrote: > In an attempt to test v7 of this patch on TPC-H 20 scale factor I found a > few regressions, > Q21: 52 secs on HEAD and 400 secs with this patch Thanks Rafia. Robert just pointed out off-list that there is a

Re: [HACKERS] PATCH: Configurable file mode mask

David Steele writes: > On 3/13/17 2:16 PM, Tom Lane wrote: >> I also don't especially want to have to analyze cases like "what >> happens if user initdb'd with mask X but then changes the GUC and >> restarts the postmaster?". Maybe the right thing is to not expose >> this as

Re: [HACKERS] Radix tree for character conversion

Heikki Linnakangas writes: > I did some more kibitzing here and there, and committed. Thanks everyone! 111 files changed, 147742 insertions(+), 367346 deletions(-) Nice. > It would be nice to run the map_checker tool one more time, though, to > verify that the mappings match

Re: [HACKERS] delta relations in AFTER triggers

On Sun, Mar 12, 2017 at 4:08 PM, Thomas Munro wrote: > I found a new way to break it: run the trigger function so > that the plan is cached by plpgsql, then ALTER TABLE incompatibly, > then run the trigger function again. See attached. The first part doesn't seem

Re: [HACKERS] Performance improvement for joins where outer side is unique

[ getting back to this patch finally... ] David Rowley writes: > I've attached a patch which implements this, though only for > MergeJoin, else I'd imagine we'd also need to ensure all proofs used > for testing the uniqueness were also hash-able too. I added some

Re: [HACKERS] PATCH: Configurable file mode mask

On 3/13/17 2:16 PM, Tom Lane wrote: > David Steele writes: >> On 3/13/17 1:03 PM, Tom Lane wrote: >>> TBH, the fact that we're relying on 0600 mode for considerations such >>> as these makes me tremendously afraid of this whole patch. I think that >>> the claimed advantages

Re: [HACKERS] Radix tree for character conversion

On 03/06/2017 10:16 AM, Kyotaro HORIGUCHI wrote: At Fri, 3 Mar 2017 12:53:04 +0900, Michael Paquier wrote in On Thu, Mar 2, 2017 at 2:20 PM, Kyotaro HORIGUCHI

Re: [HACKERS] PATCH: pageinspect / add page_checksum and bt_page_items(bytea)

On 03/13/2017 06:49 AM, Ashutosh Sharma wrote: Hi, I had a look into this patch and would like to share some of my review comments that requires author's attention. 1) The comment for page_checksum() needs to be corrected. It seems like it has been copied from page_header and not edited it

Re: [HACKERS] Bogus tab completion tweak for UPDATE ... SET ... =

Thomas Munro writes: > Even though the following is coincidentally meaningful, I don't think > it was intentional or is useful: > postgres=# update foo set x = DEFAULT Uh, seems perfectly sane to me. Why should we assume that can't be what the user wants?

Re: [HACKERS] PATCH: Configurable file mode mask

David Steele writes: > On 3/13/17 1:03 PM, Tom Lane wrote: >> TBH, the fact that we're relying on 0600 mode for considerations such >> as these makes me tremendously afraid of this whole patch. I think that >> the claimed advantages are not anywhere near worth the risk that

[HACKERS] Bogus tab completion tweak for UPDATE ... SET ... =

Hi, Even though the following is coincidentally meaningful, I don't think it was intentional or is useful: postgres=# update foo set x = DEFAULT Shouldn't that completion should be suppressed, like in the attached? -- Thomas Munro http://www.enterprisedb.com fix-update-set-completion.patch

Re: [HACKERS] PATCH: Configurable file mode mask

Hi Tom, On 3/13/17 1:03 PM, Tom Lane wrote: > David Steele writes: >> At miscinit.c:893: > >> /* We can treat the EPERM-error case as okay because that error implies >> that the existing process has a different userid than we do, which means >> it cannot be a competing

Re: [HACKERS] PATCH: Configurable file mode mask

Hi Tom, On 3/13/17 1:13 PM, Tom Lane wrote: > ... oh, and now that I've actually looked at the patch, I think it's > a seriously bad idea to proceed by removing the mode parameter to > PathNameOpenFile et al. That's basically doubling down on an assumption > that there are NO places in the

Re: [HACKERS] Gather Merge

On Fri, Mar 10, 2017 at 7:59 AM, Rushabh Lathia wrote: > Error coming from create_gather_merge_plan() from below condition: > > if (memcmp(sortColIdx, gm_plan->sortColIdx, >numsortkeys * sizeof(AttrNumber)) != 0) > elog(ERROR, "GatherMerge

Re: [HACKERS] PATCH: Batch/pipelining support for libpq

Vaishnavi Prabakaran wrote: > > while (QbatchQueueProcess(conn)) { > >r = PQsetSingleRowMode(conn); > >if (r!=1) { > > fprintf(stderr, "PQsetSingleRowMode() failed"); > >} > >.. > Thanks for investigating the problem, and could you kindly

Re: [HACKERS] PATCH: Configurable file mode mask

... oh, and now that I've actually looked at the patch, I think it's a seriously bad idea to proceed by removing the mode parameter to PathNameOpenFile et al. That's basically doubling down on an assumption that there are NO places in the backend, and never will be any, in which we want to create

Re: [HACKERS] PATCH: Configurable file mode mask

David Steele writes: > At miscinit.c:893: > /* We can treat the EPERM-error case as okay because that error implies > that the existing process has a different userid than we do, which means > it cannot be a competing postmaster. A postmaster cannot successfully > attach to

Re: [HACKERS] WIP: Faster Expression Processing v4

On 13.03.2017 11:03, Andres Freund wrote: Hi, On 2017-03-12 05:40:51 +0100, Tomas Vondra wrote: I wanted to do a bit of testing and benchmarking on this, but 0004 seems to be a bit broken. Well, "broken" in the sense that it's already outdated, because other stuff that got merged. The

Re: [HACKERS] scram and \password

On Fri, Mar 10, 2017 at 2:43 PM, Michael Paquier wrote: > On Sat, Mar 11, 2017 at 2:53 AM, Jeff Janes wrote: > > Should the \password tool in psql inspect password_encryption and act on > it > > being 'scram'? > > Not sure if it is wise to change

Re: [HACKERS] PATCH: Configurable file mode mask

On 3/10/17 8:34 AM, Stephen Frost wrote: > Greetings, > > * Tsunakawa, Takayuki (tsunakawa.ta...@jp.fujitsu.com) wrote: >> From: pgsql-hackers-ow...@postgresql.org >>> [mailto:pgsql-hackers-ow...@postgresql.org] On Behalf Of David Steele >>> PostgreSQL currently requires the file mode mask

Re: [HACKERS] PATCH: Configurable file mode mask

On 3/10/17 8:12 AM, Stephen Frost wrote: > Peter, > > * Peter Eisentraut (peter.eisentr...@2ndquadrant.com) wrote: >> On 2/28/17 20:58, David Steele wrote: >>> This patch introduces a new initdb param, -u/-file-mode-mask, and a new >>> GUC, file_mode_mask, to allow the default mode of files and

Re: [HACKERS] \if, \elseif, \else, \endif (was Re: PSQL commands: \quit_if, \quit_unless)

> > > Barring objection I'll push this so that Corey can rebase over it. > > regards, tom lane > Seems straightforward, and I appreciate you doing it for me!

Re: [HACKERS] PATCH: Make pg_stop_backup() archive wait optional

Hi Robert, On 3/6/17 12:48 PM, Robert Haas wrote: > On Sat, Mar 4, 2017 at 9:12 AM, David Steele wrote: >> Yes, that makes sense. Attached are two patches as requested: >> >> 01 - Just marks pg_stop_backup() variants as parallel restricted >> 02 - Add the wait_for_archive

Re: [HACKERS] [COMMITTERS] pgsql: Improve postmaster's logging of listen socket creation.

* Alvaro Herrera (alvhe...@2ndquadrant.com) wrote: > Tom Lane wrote: > > Robert Haas writes: > > > So now on every startup I get this: > > > > > 2017-03-13 10:08:49.399 EDT [90059] LOG: listening on IPv6 address "::1" > > > 2017-03-13 10:08:49.399 EDT [90059] LOG:

Re: [HACKERS] [PATCH] Suppress Clang 3.9 warnings

Hi David, Thank you for reminding about this patch! Here is a new patch. I tried to make as little changes as possible. This is no doubt not the most beautiful patch on Earth but it removes all warnings. I anyone could suggest an approach that would be significantly better please don't hesitate

Re: [HACKERS] [COMMITTERS] pgsql: Improve postmaster's logging of listen socket creation.

Alvaro Herrera writes: > I think it's good to have it, but I would argue that it should be a > single line that lists all the addresses instead. I don't think that's a terribly good idea, for the reasons I mentioned in

Re: [HACKERS] [COMMITTERS] pgsql: Improve postmaster's logging of listen socket creation.

Tom Lane wrote: > Robert Haas writes: > > So now on every startup I get this: > > > 2017-03-13 10:08:49.399 EDT [90059] LOG: listening on IPv6 address "::1" > > 2017-03-13 10:08:49.399 EDT [90059] LOG: listening on IPv4 address > > "127.0.0.1" > > 2017-03-13

Re: [HACKERS] tuplesort_gettuple_common() and *should_free argument

Hi Peter, On 3/2/17 9:43 AM, David Steele wrote: > Peter, > > On 2/1/17 12:59 AM, Michael Paquier wrote: >> On Thu, Jan 26, 2017 at 8:16 AM, Tom Lane wrote: >>> [ in the service of closing out this thread... ] >>> >>> Peter Geoghegan writes: Finally,

Re: [HACKERS] \if, \elseif, \else, \endif (was Re: PSQL commands: \quit_if, \quit_unless)

I wrote: > IIRC, I objected to putting knowledge of ConditionalStack > into the shared psqlscan.l lexer, and I still think that would be a bad > idea; but we need some way to get the lexer to shut that off. Probably > the best way is to add a passthrough "void *" argument that would let the >

Re: [HACKERS] [PATCH] ALTER DEFAULT PRIVILEGES with GRANT/REVOKE ON SCHEMAS

Hi Matheus, On 3/2/17 8:27 AM, David Steele wrote: > On 1/18/17 7:18 PM, Petr Jelinek wrote: >> >> The patch looks good, the only thing I am missing is tab completion >> support for psql. > > It looks like this patch is still waiting on an update for tab > completion in psql. > > Do you know

[HACKERS] Re: [GSOC 17] Eliminate O(N^2) scaling from rw-conflict tracking in serializable transactions

On Sat, Mar 11, 2017 at 8:39 PM, Mengxing Liu wrote: >> The worst problems have been >> seen with 32 or more cores on 4 or more sockets with a large number >> of active connections. I don't know whether you have access to a >> machine capable of putting this kind

Re: [HACKERS] \h tab-completion

Hi Andreas, On 3/1/17 8:47 AM, Peter Eisentraut wrote: > On 2/3/17 07:12, Andreas Karlsson wrote: >> On 01/25/2017 07:13 AM, Michael Paquier wrote: >>> What I think you should do is making the code path of >>> \\h smarter with some exceptions by using TailMatchesCS2() for ALTER. >>> There is as

Re: [HACKERS] IF (NOT) EXISTS in psql-completion

Hello, On 3/1/17 9:38 PM, Kyotaro HORIGUCHI wrote: > At Tue, 28 Feb 2017 10:39:01 -0500, Stephen Frost wrote > in <20170228153901.gh9...@tamriel.snowman.net> >> * David Fetter (da...@fetter.org) wrote: >>> On Mon, Feb 27, 2017 at 11:53:17PM -0500, Stephen Frost wrote:

Re: [HACKERS] WAL Consistency checking for hash indexes

Couple of review comments,, You may also need to update the documentation as now we are also going to support wal consistency check for hash index. The current documentation does not include hash index. +only records originating from those resource managers. Currently, +the

Re: [HACKERS] [PATCH] Suppress Clang 3.9 warnings

Hi Aleksander, On 2/22/17 9:43 AM, Fabien COELHO wrote: > > Hello Aleksander, > >> ``` >> xloginsert.c:742:18: warning: implicit conversion from 'int' to 'char' >> changes value from 253 to -3 [-Wconstant-conversion] >> ``` > > There is a bunch of these in "xlog.c" as well, and the same code

Re: [HACKERS] [COMMITTERS] pgsql: Improve postmaster's logging of listen socket creation.

Robert Haas writes: > So now on every startup I get this: > 2017-03-13 10:08:49.399 EDT [90059] LOG: listening on IPv6 address "::1" > 2017-03-13 10:08:49.399 EDT [90059] LOG: listening on IPv4 address > "127.0.0.1" > 2017-03-13 10:08:49.400 EDT [90059] LOG: listening

Re: [HACKERS] Parallel seq. plan is not coming against inheritance or partition table

On Wed, Mar 8, 2017 at 6:58 PM, Robert Haas wrote: > On Wed, Mar 8, 2017 at 7:04 AM, Amit Kapila wrote: >> On Wed, Mar 8, 2017 at 8:28 AM, Robert Haas wrote: >>> On Tue, Mar 7, 2017 at 9:24 PM, Amit Kapila

Re: [HACKERS] Parallel Append implementation

On Mon, Mar 13, 2017 at 7:46 AM, Robert Haas wrote: > On Mon, Mar 13, 2017 at 4:59 AM, Amit Khandekar > wrote: >> I agree that we should preferably have the non-partial plans started >> first. But I am not sure if it is really worth ordering the

Re: [HACKERS] [COMMITTERS] pgsql: Improve postmaster's logging of listen socket creation.

On Fri, Mar 10, 2017 at 4:32 PM, Tom Lane wrote: > Improve postmaster's logging of listen socket creation. > > When one of the kernel calls in the socket()/bind()/listen() sequence > fails, include the specific address we're trying to bind to in the log > message. This

Re: [HACKERS] New CORRESPONDING clause design

2017-03-13 14:13 GMT+01:00 Surafel Temesgen : > > > On Sat, Mar 11, 2017 at 9:01 AM, Pavel Stehule > wrote: > > >> I am sending minor update - cleaning formatting and white spaces, error >> messages + few more tests >> > > Thank you very much for

Re: [HACKERS] Proposal : For Auto-Prewarm.

>> - The error handling loop around load_block() suggests that you're >> expecting some reads to fail, which I guess is because you could be >> trying to read blocks from a relation that's been rewritten under a >> different relfilenode, or partially or entirely truncated. But I >> don't think

Re: [HACKERS] Proposal : For Auto-Prewarm.

Hi all, thanks for the feedback. Based on your recent comments I have implemented a new patch which is attached below, On Sun, Feb 26, 2017 at 10:16 PM, Robert Haas wrote: > This is not easy to fix. The lock has to be taken based on the > relation OID, not the

  1   2   >