Re: [HACKERS] Upgrading postmaster's log messages about bind/listen errors

On 11 March 2017 at 03:24, Peter Eisentraut wrote: > On 3/9/17 23:43, Tom Lane wrote: >> However, if we're measuring this on a scale of usefulness to the average >> DBA, I would argue that it's of more interest than any of these messages >> that currently appear

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

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 there's > the oldest XID that we can't reuse. These two are the same when no >

[HACKERS] Logical replication initial feedback

Hi, Thought I'd take a look at how this works (checking out current master). You guys have manged to get this to the point where it is *ridiculously* easy to set up a basic replication scenario - awesome i must say: - change a few parameters on the master

Re: [HACKERS] New CORRESPONDING clause design

Hi 2017-03-10 13:49 GMT+01:00 Pavel Stehule : > Hi > > 2017-03-10 12:55 GMT+01:00 Pavel Stehule : > >> >> >> 2017-03-10 10:13 GMT+01:00 Surafel Temesgen : >> >>> Yes, you are correct it should to work on CORRESPONDING

Re: [HACKERS] Write Ahead Logging for Hash Indexes

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. >>> >>> Committed 0002. >> >> Here are some initial review thoughts on 0003 based on

Re: [HACKERS] How to get the 'ctid' from a record type?

> > I suspect the tuple at (0,1) has been the subject of a failed update. > Yep. > Your problem here is that you're mistaking the t_ctid field of a tuple > header for the tuple's address. It is not that; it's really just garbage > normally, and is only useful to link forward to the next

Re: [HACKERS] Bizarre choice of case for RELKIND_PARTITIONED_TABLE

On Thu, Mar 9, 2017 at 11:06:56PM -0300, Alvaro Herrera wrote: > Tom Lane wrote: > > > (And no, I don't especially > > approve of RELKIND_SEQUENCE being 'S' either, but it's far too late to > > change that.) > > FWIW the reason SEQUENCE uses S instead of 's' is that the latter was > taken for

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

Hi, all My name is Mengxing Liu. I am interested in the project "Eliminate O(N^2) scaling from rw-conflict tracking in serializable transactions”. After discussing with Kevin off-list, I think it's time to post discussion here. I am afraid that there are two things that I need your help.

Re: [HACKERS] make check-world output

On 3/10/17 19:26, Jeff Janes wrote: > and there will be an exit code. > > > True. But I generally don't rely on that, unless the docs explicitly > tell me to. > > > If we show no output, then other people will complain that they can't > tell whether it's hanging. > > > Isn't

Re: [HACKERS] make check-world output

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 I've >> run it on (CentOS6.8 and Ubuntu 16.04.2), it dumps some gibberish to >>

Re: [HACKERS] SERIALIZABLE with parallel query

On Wed, Feb 22, 2017 at 2:01 PM, Robert Haas wrote: > I don't think I know enough about the serializable code to review > this, or at least not quickly, but it seems very cool if it works. > Have you checked what effect it has on shared memory consumption? I'm not sure how

Re: [HACKERS] [PATCH] Enabling atomics on ARM64

On 2017-03-10 18:14:13 -0800, Roman Shaposhnik wrote: > On Fri, Mar 10, 2017 at 11:20 AM, Andres Freund wrote: > > Hi, > > > > On 2017-03-08 19:18:04 -0800, Roman Shaposhnik wrote: > >> I'd like to offer a forward port from a change I'm contributing > >> the Greenplum code

Re: [HACKERS] make check-world output

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 I've > run it on (CentOS6.8 and Ubuntu 16.04.2), it dumps some gibberish to > stderr, example attached. I think you're complaining

Re: [HACKERS] [PATCH] Enabling atomics on ARM64

On Fri, Mar 10, 2017 at 11:20 AM, Andres Freund wrote: > Hi, > > On 2017-03-08 19:18:04 -0800, Roman Shaposhnik wrote: >> I'd like to offer a forward port from a change I'm contributing >> the Greenplum code base over here > > I think the change makes sense. Any chance we

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

Peter Eisentraut writes: make check-world -j2 seems to run fine for me. > I have been pounding it a bit, and every so often the test_decoding > tests fail in mysterious ways, but otherwise it seems to work fine. I'm > curious what you are seeing. For me,

Re: [HACKERS] Indirect assignment code for array slices is dead code?

Hi, On 2017-03-10 20:59:48 -0500, Tom Lane wrote: > Andres Freund writes: > > In the context of my expression evaluation patch, I was trying to > > increase test coverage of execQual.c. I'm a bit confused about > > $subject. ExecEvalArrayRef() has the following codepath: >

Re: [HACKERS] Indirect assignment code for array slices is dead code?

Andres Freund writes: > In the context of my expression evaluation patch, I was trying to > increase test coverage of execQual.c. I'm a bit confused about > $subject. ExecEvalArrayRef() has the following codepath: I think it may indeed be unreachable at present, because we

Re: [HACKERS] How to get the 'ctid' from a record type?

Eric Ridge writes: > What I'm seeing is that the ctid returned from this function isn't always > correct: > # select ctid, foo(table) from table limit 10; > ctid |foo > ---+--- > (0,1) | (19195,1)-- not correct! > (0,2) | (0,2) > (0,3) | (0,3) I

[HACKERS] Indirect assignment code for array slices is dead code?

Hi, In the context of my expression evaluation patch, I was trying to increase test coverage of execQual.c. I'm a bit confused about $subject. ExecEvalArrayRef() has the following codepath: if (isAssignment) { Datum sourceData; Datum save_datum; bool

[HACKERS] How to get the 'ctid' from a record type?

This is about Postgres 9.6... I have a very simple 1-arg function, in C, that I want to return the ctid of the record passed in. Example: CREATE OR REPLACE FUNCTION foo(record) RETURNS tid LANGUAGE c IMMUTABLE STRICT AS 'my_extension'; Its implementation is simply: Datum foo(PG_FUNCTION_ARGS)

Re: [HACKERS] WIP: Faster Expression Processing v4

On Fri, Mar 10, 2017 at 07:15:59PM -0500, Peter Eisentraut wrote: > On 3/10/17 14:40, Andres Freund wrote: > > I'd really like to get it in. The performance improvements on its own > > are significant, and it provides the basis for significantly larger > > improvements again (JIT) - those

Re: [HACKERS] Speed up Clog Access by increasing CLOG buffers

On Sat, Mar 11, 2017 at 2:10 AM, Robert Haas wrote: > On Fri, Mar 10, 2017 at 6:25 AM, Amit Kapila wrote: >> On Fri, Mar 10, 2017 at 11:51 AM, Tom Lane wrote: >>> Amit Kapila writes: Just to let

Re: [HACKERS] make check-world output

On Fri, Mar 10, 2017 at 4:00 PM, Peter Eisentraut < peter.eisentr...@2ndquadrant.com> wrote: > On 3/10/17 15:05, 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 I've run it

Re: [HACKERS] WIP: Faster Expression Processing v4

On 3/10/17 14:40, Andres Freund wrote: > I'd really like to get it in. The performance improvements on its own > are significant, and it provides the basis for significantly larger > improvements again (JIT) - those followup improvements are large patches > again though, so I'd rather not do all

Re: [HACKERS] make check-world output

On Fri, Mar 10, 2017 at 12:24 PM, Alvaro Herrera wrote: > Jeff Janes wrote: > > > Also, it runs in about 8 minutes, not the 20 minutes reported by others. > > My system is virtualized, and not particularly fast. I wonder if it is > > failing early somewhere without

Re: [HACKERS] WIP: Faster Expression Processing v4

On 3/10/17 14:24, Andres Freund wrote: > What problem are you thinking of exactly, and what'd be the solution? > I'd guess that people wouldn't like being unable to change columns in a > table if some function returned the type. Well, that's pretty much the problem. For example: create type t1

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

On 3/10/17 19:00, Jim Nasby wrote: > Maybe instead of having the commitfest app try and divine patches from > the list it should be able to send patches to the list from a specified > git repo/branch. Anyone that provides that info would have tests run > automagically, patches sent, etc. Anyone

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

On 3/10/17 14:43, Andres Freund wrote: > I do get regular issues, although the happen to not end up in visible > failures. All the tests output their regression.diffs into the same > place - which means there'll every now be a failure to remove the file, > and if there were an actual failure it'd

Re: [HACKERS] make check-world output

On 3/10/17 15:24, Alvaro Herrera wrote: > Jeff Janes wrote: > >> Also, it runs in about 8 minutes, not the 20 minutes reported by others. >> My system is virtualized, and not particularly fast. I wonder if it is >> failing early somewhere without running to completion? How would/should I >>

Re: [HACKERS] make check-world output

On 3/10/17 15:05, 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 I've run it on (CentOS6.8 and Ubuntu 16.04.2), it dumps some > gibberish to stderr, example attached. Which

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

On 3/10/17 5:57 PM, Peter Eisentraut wrote: On 3/10/17 14:53, Jim Nasby wrote: The biggest win we'd get from something like Travis would be if the commitfest monitored for new patch files coming in for monitored threads and it created a new branch, applied the patches, and if they applied

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

On 3/10/17 14:53, Jim Nasby wrote: > The biggest win we'd get from something like Travis would be if the > commitfest monitored for new patch files coming in for monitored threads > and it created a new branch, applied the patches, and if they applied > without error commit the branch and push

Re: [HACKERS] Upgrading postmaster's log messages about bind/listen errors

I wrote: > I think that what would actually be of some use nowadays is a LOG-level > message emitted if the wraparound *isn't* activated immediately at start. > But otherwise, we should follow the rule that silence is golden. Concretely, how about the attached? It preserves the original

Re: [HACKERS] asynchronous execution

On Thu, Feb 23, 2017 at 6:59 AM, Kyotaro HORIGUCHI < horiguchi.kyot...@lab.ntt.co.jp> wrote: > 9e43e87 Patch fails on current master, but correctly applies to 9e43e87. Thanks for including the commit id. Regression tests pass. As with my last attempt at reviewing this patch, I'm confused

Re: [HACKERS] Should we eliminate or reduce HUP from docs?

On Fri, Mar 10, 2017 at 3:51 PM, Alvaro Herrera wrote: > David G. Johnston wrote: > > On Fri, Mar 10, 2017 at 3:28 PM, Alvaro Herrera < > alvhe...@2ndquadrant.com> > > > is incomplete. > > Sure. We can just reword that along the lines of " ... and when a > reload

Re: [HACKERS] Should we eliminate or reduce HUP from docs?

David G. Johnston wrote: > On Fri, Mar 10, 2017 at 3:28 PM, Alvaro Herrera > wrote: > > > I think we could split 19.1.2 in two parts, where the first one is the > > current content minus the paragraph "The configuration file is reread". > > We'd create "19.1.3

Re: [HACKERS] scram and \password

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 the default fot this release. > I didn't see this issue discussed, but the ability to search

Re: [HACKERS] Should we eliminate or reduce HUP from docs?

On Fri, Mar 10, 2017 at 3:28 PM, Alvaro Herrera wrote: > David G. Johnston wrote: > > On Fri, Mar 10, 2017 at 1:02 PM, Alvaro Herrera < > alvhe...@2ndquadrant.com> > > wrote: > > > > There are several ways to cause a config file reload (pg_ctl reload, > > >

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

On Sat, Mar 11, 2017 at 12:03 AM, Artur Zakirov wrote: > Because BM_PERMANENT is used for init forks of unlogged indexes now. Yes, indeed. -- Michael diff --git a/contrib/bloom/blinsert.c b/contrib/bloom/blinsert.c index 913f1f8a51..3557b106d8 100644 ---

Re: [HACKERS] Should we eliminate or reduce HUP from docs?

David G. Johnston wrote: > On Fri, Mar 10, 2017 at 1:02 PM, Alvaro Herrera > wrote: > > There are several ways to cause a config file reload (pg_ctl reload, > > pg_reload_conf, direct SIGHUP). We could have a section in docs listing > > them all, and then all the other

Re: [HACKERS] Speed up Clog Access by increasing CLOG buffers

Robert Haas wrote: > The smoking gun was in 009_twophase_slave.log: > > TRAP: FailedAssertion("!(nsubxids == MyPgXact->nxids)", File: > "clog.c", Line: 288) > > ...and then the node shuts down, which is why this hangs forever. > (Also... what's up with it hanging forever instead of timing out

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

On 3/10/17 2:18 PM, Magnus Hagander wrote: But if you can put together something that picks up the individual patches out of the mail threads in the CF app and keeps branch-tips in a git repo up-to-date with those, including feeding the results back into the app, then go for it :) Seems like

Re: [HACKERS] Speed up Clog Access by increasing CLOG buffers

On Fri, Mar 10, 2017 at 3:40 PM, Robert Haas wrote: > Finally, I had an unexplained hang during the TAP tests while testing > out your fix patch. I haven't been able to reproduce that so it > might've just been an artifact of something stupid I did, or of some > unrelated

Re: [HACKERS] Should we eliminate or reduce HUP from docs?

On Fri, Mar 10, 2017 at 1:02 PM, Alvaro Herrera wrote: > Joshua D. Drake wrote: > > > I am a bad speaker, I am writing a talk three weeks before the conference > > (as opposed to on the plane). > > Hah. > > > I noticed in the docs we still reference the > > passing of

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

On Fri, Mar 10, 2017 at 2:00 AM, Craig Ringer wrote: > On 10 March 2017 at 02:55, Robert Haas wrote: >> Well, that's why I tried to advocate that their should be two separate >> XID limits in shared memory: leave what's there now the way it is, and

Re: [HACKERS] Speed up Clog Access by increasing CLOG buffers

On Fri, Mar 10, 2017 at 6:25 AM, Amit Kapila wrote: > On Fri, Mar 10, 2017 at 11:51 AM, Tom Lane wrote: >> Amit Kapila writes: >>> Just to let you know that I think I have figured out the reason of >>> failure. If we run the

Re: [HACKERS] pg_dump segfaults with publication

On 3/6/17 03:06, Amit Langote wrote: > pg_dump segfaults if there are more than one DO_PUBLICATION_REL objects to > dump. Fix committed with a test case. Thanks. -- Peter Eisentraut http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

Re: [HACKERS] Upgrading postmaster's log messages about bind/listen errors

Alvaro Herrera writes: > Tom Lane wrote: >> Uh, what's that got to do with it? I'm not proposing to downgrade this >> message in 9.3, or indeed any current release branch. But it's hard >> to believe that a 9.3 installation that had the problem would manage >> to make

Re: [HACKERS] Upgrading postmaster's log messages about bind/listen errors

Tom Lane wrote: > Euler Taveira writes: > > 2017-03-10 1:43 GMT-03:00 Tom Lane : > >> 2017-03-09 23:40:12.334 EST [19335] LOG: MultiXact member wraparound > >> protections are now enabled > > > It should be DEBUG1 as soon as 9.3 is deprecated. > > Uh,

Re: [HACKERS] make check-world output

Jeff Janes wrote: > Also, it runs in about 8 minutes, not the 20 minutes reported by others. > My system is virtualized, and not particularly fast. I wonder if it is > failing early somewhere without running to completion? How would/should I > know? Maybe you don't have --enable-tap-tests? --

Re: [HACKERS] Upgrading postmaster's log messages about bind/listen errors

Euler Taveira writes: > 2017-03-10 1:43 GMT-03:00 Tom Lane : >> 2017-03-09 23:40:12.334 EST [19335] LOG: MultiXact member wraparound >> protections are now enabled > It should be DEBUG1 as soon as 9.3 is deprecated. Uh, what's that got to do with it?

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

On Fri, Mar 10, 2017 at 3:11 PM, Jim Nasby wrote: > On 3/10/17 2:05 PM, Magnus Hagander wrote: > >> >> Travis specifically would not help us with this, due to the dependency >> on gifhub, but something that knows how to run "patch ... && configure >> && make && make check"

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

On 3/10/17 2:05 PM, Magnus Hagander wrote: Travis specifically would not help us with this, due to the dependency on gifhub, but something that knows how to run "patch ... && configure && make && make check" in a container would. Who's updating https://github.com/postgres/postgres/ right now?

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

On Fri, Mar 10, 2017 at 2:53 PM, Jim Nasby wrote: > On 3/10/17 1:09 PM, Peter Eisentraut wrote: > >> On 3/10/17 03:27, Jim Nasby wrote: >> >>> Perhaps https://travis-ci.org/ or something similar could be used for >>> this. That avoids any issues about random code. >>> >>

[HACKERS] make check-world output

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 I've run it on (CentOS6.8 and Ubuntu 16.04.2), it dumps some gibberish to stderr, example attached. Which first made me wonder whether the test passed or

Re: [HACKERS] Should we eliminate or reduce HUP from docs?

Joshua D. Drake wrote: > I am a bad speaker, I am writing a talk three weeks before the conference > (as opposed to on the plane). Hah. > I noticed in the docs we still reference the > passing of SIGHUP for reloading conf file but we now have pg_reload_conf(); > > It seems the use of

Re: [HACKERS] Should we eliminate or reduce HUP from docs?

Hi, On 2017-03-10 11:57:30 -0800, Joshua D. Drake wrote: > I am a bad speaker, I am writing a talk three weeks before the conference > (as opposed to on the plane). I noticed in the docs we still reference the > passing of SIGHUP for reloading conf file but we now have pg_reload_conf(); > > It

[HACKERS] Should we eliminate or reduce HUP from docs?

Hello, I am a bad speaker, I am writing a talk three weeks before the conference (as opposed to on the plane). I noticed in the docs we still reference the passing of SIGHUP for reloading conf file but we now have pg_reload_conf(); It seems the use of pg_reload_conf() would provide a better

Re: [HACKERS] ANALYZE command progress checker

On 3/10/17 1:06 PM, Andres Freund wrote: Hi, On 2017-03-10 02:11:18 -0600, Jim Nasby wrote: Perhaps instead of adding more clutter to \dvS we could just have a SRF for now. I don't see that as clutter, it's useful information, and keeping it discoverable is good, not bad. If we keep adding

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

On 3/10/17 1:09 PM, Peter Eisentraut wrote: On 3/10/17 03:27, Jim Nasby wrote: Perhaps https://travis-ci.org/ or something similar could be used for this. That avoids any issues about random code. That doesn't achieve any platform coverage, which is the main point here. I don't think

Re: [HACKERS] Query fails when SRFs are part of FROM clause (Commit id: 69f4b9c85f)

On 2017-03-09 13:34:22 -0500, Robert Haas wrote: > On Mon, Jan 30, 2017 at 6:54 PM, Tom Lane wrote: > > Andres Freund writes: > >> Wonder if we there's an argument to be made for implementing this > >> roughly similarly to split_pathtarget_at_srf - instead

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

On 2017-03-10 01:59:53 -0500, Peter Eisentraut wrote: > On 3/8/17 16:49, Andres Freund wrote: > >> make check-world -j2 seems to run fine for me. > > > > Hm, I at least used to get a lot of spurious failures with this. I > > e.g. don't think the free port selection is race free. > > I was also

Re: [HACKERS] WIP: Faster Expression Processing v4

On 2017-03-10 09:00:14 -0500, Peter Eisentraut wrote: > I have also looked at the 0002 and 0003 patches, and they seem OK, but > they are obviously not of much use without 0004. What is your ambition > for getting 0004 reviewed and committed for PG10? I'd really like to get it in. The

Re: [HACKERS] Explicit subtransactions for PL/Tcl

On Thu, 9 Mar 2017 12:04:31 +0100 Pavel Stehule wrote: > > Now test demonstrate how errors uncaught on the Tcl level interact > > with postgresql error system. > > > > you can catch the exception outside and write own message OK, here is patch with tests which don't

Re: [HACKERS] SQL/JSON in PostgreSQL

On 03/09/2017 10:12 AM, Sven R. Kunze wrote: > On 08.03.2017 20:52, Magnus Hagander wrote: >> On Wed, Mar 8, 2017 at 11:48 AM, Peter van Hardenberg > > wrote: >> >> Small point of order: YAML is not strictly a super-set of JSON. >> >> Editorializing

Re: [HACKERS] Upgrading postmaster's log messages about bind/listen errors

On 3/9/17 23:43, Tom Lane wrote: > However, if we're measuring this on a scale of usefulness to the average > DBA, I would argue that it's of more interest than any of these messages > that currently appear by default: > > 2017-03-09 23:40:12.334 EST [19335] LOG: MultiXact member wraparound >

Re: [HACKERS] WIP: Faster Expression Processing v4

On 2017-03-10 08:51:25 -0500, Peter Eisentraut wrote: > On 3/7/17 19:14, Andres Freund wrote: > >> Why shouldn't the function itself also depend on the components of its > >> return type? > > Because that'd make it impossible to change the return type components - > > if the return type is baked

Re: [HACKERS] [PATCH] Enabling atomics on ARM64

Hi, On 2017-03-08 19:18:04 -0800, Roman Shaposhnik wrote: > I'd like to offer a forward port from a change I'm contributing > the Greenplum code base over here I think the change makes sense. Any chance we could convince you to bring up an arm64 buildfarm animal (our test infrastructure) up, so

Re: [HACKERS] Adding support for Default partition in partitioning

On 3/2/17 21:40, Robert Haas wrote: > On the point mentioned above, I > don't think adding a partition should move tuples, necessarily; seems > like it would be good enough - maybe better - for it to fail if there > are any that would need to be moved. ISTM that the uses cases of various

Re: [HACKERS] SQL Standard Feature T211

On 3/9/17 18:39, Kevin Grittner wrote: > With the addition of transition tables we have all four, although > I'm not sure whether the CREATE TRIGGER statement conforms closely > enough to claim the feature. The two basic issues I can think of > are: > - we don't allow the OLD and NEW transition

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

On 3/10/17 03:27, Jim Nasby wrote: > Perhaps https://travis-ci.org/ or something similar could be used for > this. That avoids any issues about random code. That doesn't achieve any platform coverage, which is the main point here. -- Peter Eisentraut http://www.2ndQuadrant.com/

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

On 3/10/17 13:02, Magnus Hagander wrote: > for their largest feature development. Could be a good idea to for > example ave an example yml file somewhere on the wiki that people could > put into their branches. https://github.com/petere/postgresql/blob/travis/.travis.yml -- Peter Eisentraut

Re: [HACKERS] ANALYZE command progress checker

Hi, On 2017-03-10 02:11:18 -0600, Jim Nasby wrote: > Perhaps instead of adding more clutter to \dvS we could just have a SRF for > now. I don't see that as clutter, it's useful information, and keeping it discoverable is good, not bad. > At over 2800 rows currently, you're not going to notice

Re: [HACKERS] logical replication access control patches

On 3/3/17 10:07, Stephen Frost wrote: > Will users really understand that the PUBLISH right actually allows > complete access to the entire relation, rather than just the ability for > a user to PUBLISH what they are currently about to SELECT? It certainly > doesn't seem intuitive to me, which is

Re: [HACKERS] logical replication access control patches

On 2/27/17 22:10, Stephen Frost wrote: > Peter, > > * Peter Eisentraut (peter.eisentr...@2ndquadrant.com) wrote: >> On 2/18/17 18:06, Stephen Frost wrote: >>> I'm not convinced that it really makes sense to have PUBLICATION of a >>> table be independent from the rights an owner of a table has.

Re: [HACKERS] Bizarre choice of case for RELKIND_PARTITIONED_TABLE

I wrote: > Robert Haas writes: >> On Tue, Mar 7, 2017 at 12:55 PM, Tom Lane wrote: >>> Is there a good reason why RELKIND_PARTITIONED_TABLE is 'P' not 'p'? >> I can't muster a lot of outrage about this one way or another. One >> possible advantage of

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

Robert Haas wrote: > On Wed, Mar 8, 2017 at 2:30 PM, Alvaro Herrera > wrote: > > Not really -- it's a bit slower actually in a synthetic case measuring > > exactly the slowed-down case. See > >

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

On Fri, Mar 10, 2017 at 11:29 AM, Dagfinn Ilmari Mannsåker < ilm...@ilmari.org> wrote: > Magnus Hagander writes: > > > AFAIK travis-ci would require us to use github as our hoster for all > those > > things, and embrace that workflow, they don't support anything else. > > >

Re: [HACKERS] SQL/JSON in PostgreSQL

On Thu, Mar 9, 2017 at 1:12 PM, Sven R. Kunze wrote: > On 08.03.2017 20:52, Magnus Hagander wrote: > > On Wed, Mar 8, 2017 at 11:48 AM, Peter van Hardenberg wrote: > >> Small point of order: YAML is not strictly a super-set of JSON. >> >> Editorializing slightly, I

[HACKERS] scram and \password

Should the \password tool in psql inspect password_encryption and act on it being 'scram'? I didn't see this issue discussed, but the ability to search the archives for backslashes is rather limited. Cheers, Jeff

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

Hi all and thank you for your quick replies. > [two people interested in the same GSoC project] Mr. Grittner thank you for sharing this ahead of time. Liu(is this your first name?), > I have been concentrating on it for a long time, reading papers, reading > source codes, and discussing

Re: [HACKERS] SQL/JSON in PostgreSQL

On 10.03.2017 05:07, Petr Jelinek wrote: The original complain was about JSON_VALUE extracting date but I don't understand why there is problem with that, the SQL/JSON defines that behavior. The RETURNING clause there is more or less just shorthand for casting with some advanced options.

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

Kevin, * Kevin Grittner (kgri...@gmail.com) wrote: > > [two people interested in the same GSoC project] > > It's an interesting problem to have. > > If neither of you chooses to voluntarily back down, the obvious > resolution is for the mentors to vote on the better proposal. If we > do that

Re: [HACKERS] Parallel Append implementation

On Fri, Mar 10, 2017 at 12:17 AM, Amit Khandekar wrote: > I agree that the two-lists approach will consume less memory than > bitmapset. Keeping two lists will effectively have an extra pointer > field which will add up to the AppendPath size, but this size will not > grow

Re: [HACKERS] Upgrading postmaster's log messages about bind/listen errors

Stephen Frost writes: > * Tom Lane (t...@sss.pgh.pa.us) wrote: >> ... So I think the logging setup I had in >> my patch is pretty much the only sane way to do it, and we just have >> to decide whether it's worth exposing at default log level or not. > I definitely think we

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

> [two people interested in the same GSoC project] It's an interesting problem to have. If neither of you chooses to voluntarily back down, the obvious resolution is for the mentors to vote on the better proposal. If we do that early enough during the student application period, there might

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

Magnus Hagander writes: > AFAIK travis-ci would require us to use github as our hoster for all those > things, and embrace that workflow, they don't support anything else. > > There might be others that do, just not travis. It merely requires the repository to exist on

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

Hi George, I am Mengxing Liu. Happy to meet someone with the same idea : ) I have been concentrating on it for a long time, reading papers, reading source codes, and discussing details with Mr Grittner. So I really understand your passion on it. But definitely I don't want all these effects

Re: [HACKERS] Upgrading postmaster's log messages about bind/listen errors

* Tom Lane (t...@sss.pgh.pa.us) wrote: > Stephen Frost writes: > > database system is ready to accept connections on (1.2.3.4) > > That would be a problem from a couple of directions. First, it wouldn't > be unusual for there to be half a dozen addresses to list, not just

Re: [HACKERS] Upgrading postmaster's log messages about bind/listen errors

2017-03-10 1:43 GMT-03:00 Tom Lane : > Yeah, my thought was that if we've gotten along without this for 20 years, > it's probably not of interest to most people most of the time. > > +1 for DEBUG1. > 2017-03-09 23:40:12.334 EST [19335] LOG: MultiXact member wraparound >

Re: [HACKERS] [PATCH] few fts functions for jsonb

> On 28 February 2017 at 19:21, Oleg Bartunov wrote: > 1. add json support I've added json support for all functions. > Its_headline should returns the original json with highlighting Yes, I see now. I don't think it's worth it to add a special option for that purpose,

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

On Fri, Mar 10, 2017 at 3:27 AM, Jim Nasby wrote: > On 3/7/17 9:52 PM, Magnus Hagander wrote: > >> There have also on and off been discussions about building arbitrary >> patches as they are sent to the mailinglists. Doing that without any >> committer (or other trusted

Re: [HACKERS] Upgrading postmaster's log messages about bind/listen errors

Stephen Frost writes: > * Tels (nospam-pg-ab...@bloodgate.com) wrote: >> I'd argue that from a security standpoint it is important to log at >> startup what addresses the service binds to, just so it is visible, >> explicit and logged. > It's also terribly useful for

Re: [HACKERS] rename pg_log directory?

On Fri, Mar 10, 2017 at 11:23:54AM +0100, Andreas Karlsson wrote: > On 03/09/2017 11:25 PM, Bruce Momjian wrote: > >"data" and "base" where chosen because it is a "data-base", but with the > >pg_ prefixes it would be a pg_data_pg_base. ;-) > > Haha, I had not spotted that one despite always

Re: [HACKERS] Re: proposal - psql: possibility to specify sort for describe commands, when size is printed

2017-03-10 16:05 GMT+01:00 Peter Eisentraut < peter.eisentr...@2ndquadrant.com>: > On 3/10/17 09:57, Pavel Stehule wrote: > > PREFERRED_SORT_COLUMNS > > and PREFERRED_SORT_DIRECTION ? > > I think the name "preferred" implies that it will be ignored if it's not > found or something like that, but

Re: [HACKERS] Re: proposal - psql: possibility to specify sort for describe commands, when size is printed

2017-03-10 16:00 GMT+01:00 Alexander Korotkov : > On Fri, Mar 10, 2017 at 5:16 PM, Stephen Frost wrote: > >> * Peter Eisentraut (peter.eisentr...@2ndquadrant.com) wrote: >> > On 2/24/17 16:32, Pavel Stehule wrote: >> > > set

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

On 10.03.2017 04:00, Michael Paquier wrote: On Thu, Mar 9, 2017 at 10:25 PM, Artur Zakirov wrote: I think this is good fixes. I've checked them. And in my opinion they are correct. The code also is good. Having something with conflicts is not nice, so attached is a

Re: [HACKERS] Re: proposal - psql: possibility to specify sort for describe commands, when size is printed

On 3/10/17 09:57, Pavel Stehule wrote: > PREFERRED_SORT_COLUMNS > and PREFERRED_SORT_DIRECTION ? I think the name "preferred" implies that it will be ignored if it's not found or something like that, but I don't think that's what you are implementing. -- Peter Eisentraut

Re: [HACKERS] some dblink refactoring

On 3/8/17 00:10, Tsunakawa, Takayuki wrote: > I changed the status to ready for committer. The patch applied cleanly, > passed the regression test (make installcheck in contrib/dblink/), and the > code looks perfect. > > How about applying the attached small patch for another refactoring?

Re: [HACKERS] Re: proposal - psql: possibility to specify sort for describe commands, when size is printed

2017-03-10 15:16 GMT+01:00 Stephen Frost : > * Peter Eisentraut (peter.eisentr...@2ndquadrant.com) wrote: > > On 2/24/17 16:32, Pavel Stehule wrote: > > > set EXTENDED_DESCRIBE_SORT size_desc > > > \dt+ > > > \l+ > > > \di+ > > > > > > Possible variants:

  1   2   >