Re: [HACKERS] No-op case in ExecEvalConvertRowtype

On Fri, Apr 7, 2017 at 9:02 AM, Tom Lane wrote: > Ashutosh Bapat writes: >> While I agree that we can remove indesc->tdtypeid == >> outdesc->tdtypeid, I am not sure whether it should be replaced by >> !indesc->tdhasoid && !outdesc->tdhasoid. >

Re: [HACKERS] Making clausesel.c Smarter

On 4 April 2017 at 13:35, Claudio Freire wrote: > On Mon, Apr 3, 2017 at 9:19 PM, Claudio Freire wrote: > If you ask me, I'd just leave: > > + if (rqlist->hibound == DEFAULT_INEQ_SEL || rqlist->lobound == > DEFAULT_INEQ_SEL) > + { > + /* No

Re: [HACKERS] identity columns

On 4/6/17, Peter Eisentraut wrote: > On 4/4/17 22:53, Vitaly Burovoy wrote: >> The next nitpickings to the last patch. I try to get places with >> lacking of variables' initialization. >> All other things seem good for me now. I'll continue to review the >> patch

[HACKERS] POC: Sharing record typmods between backends

Hi hackers, Tuples can have type RECORDOID and a typmod number that identifies a "blessed" TupleDesc in a backend-private cache. To support the sharing of such tuples through shared memory and temporary files, I think we need a typmod registry in shared memory. Here's a proof-of-concept patch

Re: [HACKERS] SCRAM authentication, take three

On Thu, Apr 06, 2017 at 09:46:29PM +0300, Heikki Linnakangas wrote: > On 04/06/2017 08:36 AM, Noah Misch wrote: > >On Tue, Mar 07, 2017 at 02:36:13PM +0200, Heikki Linnakangas wrote: > >>I didn't include the last-minute changes to the way you specify this in > >>pg_hba.conf. So it's still just

Re: [HACKERS] New SQL counter statistics view (pg_stat_sql)

On Thu, Apr 6, 2017 at 5:17 AM, Andres Freund wrote: > Hi, > > > I'm somewhat inclined to think that this really would be better done in > an extension like pg_stat_statements. > Thanks for the review. > > > +} > > + > > +/* > > + * Count SQL statement for pg_stat_sql

Re: [HACKERS] Interval for launching the table sync worker

On Fri, Apr 7, 2017 at 1:23 PM, Kyotaro HORIGUCHI wrote: > At Thu, 6 Apr 2017 18:42:37 +0200, Petr Jelinek > wrote in > <8c7afb37-be73-c6bd-80bc-e87522f04...@2ndquadrant.com> >> On 06/04/17 16:44, Masahiko Sawada wrote: >> > On

Re: [HACKERS] Foreign tables don't enforce the partition constraint

On 2017/04/03 16:44, Amit Langote wrote: > Hi Ashutosh, > > On 2017/04/03 15:49, Ashutosh Bapat wrote: Similarly, a partition constraint should also be enforced at the foreign server. Probably we should update documentation of create foreign table to mention this. >>> >>> That is a

Re: [HACKERS] No-op case in ExecEvalConvertRowtype

On 2017/04/07 12:16, Ashutosh Bapat wrote: > On Fri, Apr 7, 2017 at 7:28 AM, Amit Langote > wrote: >> >> And I see that just in 3f902354b08 lets the partition tuple-routing code >> keep utilizing that optimization. > > I am not able to find this commit > fatal:

Re: [HACKERS] Hash tables in dynamic shared memory

On Mon, Dec 19, 2016 at 12:33 PM, Thomas Munro wrote: > Since Dilip Kumar's Parallel Bitmap Heap Scan project is no longer > using this, I think I should park it here unless/until another > potential use case pops up. Some interesting candidates have been >

Re: [HACKERS] src/interfaces/libpq shipping nmake-related Makefiles

Andres Freund writes: > On 2017-04-07 13:07:59 +0900, Michael Paquier wrote: >> On Fri, Apr 7, 2017 at 1:01 PM, Tom Lane wrote: >>> Still, it's not very clear why we need to cater for building just libpq >>> rather than the whole distribution, and a user

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

On Thu, Apr 6, 2017 at 12:20 AM, Peter Geoghegan wrote: > On Wed, Apr 5, 2017 at 11:27 AM, Andres Freund wrote: > > I propose we move this patch to the next CF. > > I agree. I think it's too late to be working out fine details around > TOAST like this. This is

Re: [HACKERS] Faster methods for getting SPI results (460% improvement)

On 4/6/17 9:21 PM, Andres Freund wrote: Personally I'm way more excited about what a SPI feature like this could do for plpgsql than about what it can do for plpython. If the latter is what floats your boat, that's fine; but I want a feature that we can build on for other uses, not a hack that

Re: [HACKERS] Interval for launching the table sync worker

At Thu, 6 Apr 2017 18:42:37 +0200, Petr Jelinek wrote in <8c7afb37-be73-c6bd-80bc-e87522f04...@2ndquadrant.com> > On 06/04/17 16:44, Masahiko Sawada wrote: > > On Thu, Apr 6, 2017 at 9:06 PM, Kyotaro HORIGUCHI > > wrote: > >>> I

Re: [HACKERS] Faster methods for getting SPI results (460% improvement)

On 2017-04-07 00:11:59 -0400, Tom Lane wrote: > Jim Nasby writes: > > On 4/6/17 8:13 PM, Tom Lane wrote: > >> Given Peter's objections, I don't think this is getting into v10 anyway, > >> so we might as well take a bit more time and do it right. > > > Well, Peter's

[HACKERS] Minor code improvement to postgresGetForeignPlan

Hi, The declaration of postgresGetForeignPlan uses baserel, but the actual definition uses foreignrel. It would be better to sync. Please find attached a patch. Tatsuro Yamada NTT Open Source Software Center diff --git a/contrib/postgres_fdw/postgres_fdw.c b/contrib/postgres_fdw/postgres_fdw.c

Re: [HACKERS] Faster methods for getting SPI results (460% improvement)

On Apr 6, 2017, at 9:10 PM, Andres Freund wrote: > >>> Why? We could very well return a somewhat "smarter" object. Returning >>> rows row-by-row if accessed via iterator, materializes when accessed via >>> row offset. >> >> I completely agree with that. What I don't

Re: [HACKERS] src/interfaces/libpq shipping nmake-related Makefiles

On 2017-04-07 13:07:59 +0900, Michael Paquier wrote: > On Fri, Apr 7, 2017 at 1:01 PM, Tom Lane wrote: > > Still, it's not very clear why we need to cater for building just libpq > > rather than the whole distribution, and a user of win32.mak presumably > > has the option to

Re: [HACKERS] Faster methods for getting SPI results (460% improvement)

Jim Nasby writes: > On 4/6/17 8:13 PM, Tom Lane wrote: >> Given Peter's objections, I don't think this is getting into v10 anyway, >> so we might as well take a bit more time and do it right. > Well, Peter's objection is that we're not going far enough in plpython, > but

Re: [HACKERS] Faster methods for getting SPI results (460% improvement)

On 2017-04-06 21:06:59 -0700, Jim Nasby wrote: > On 4/6/17 9:04 PM, Andres Freund wrote: > > On 2017-04-06 09:14:43 -0700, Jim Nasby wrote: > > > On 4/6/17 9:04 AM, Peter Eisentraut wrote: > > > > On 4/6/17 03:50, Craig Ringer wrote: > > > > > But otherwise, pending docs changes, I think it's

Re: [HACKERS] src/interfaces/libpq shipping nmake-related Makefiles

On Fri, Apr 7, 2017 at 1:01 PM, Tom Lane wrote: > Still, it's not very clear why we need to cater for building just libpq > rather than the whole distribution, and a user of win32.mak presumably > has the option to do the latter. The core argument for bcc32.mak, > I think, is

Re: [HACKERS] Faster methods for getting SPI results (460% improvement)

On 4/6/17 9:04 PM, Andres Freund wrote: On 2017-04-06 09:14:43 -0700, Jim Nasby wrote: On 4/6/17 9:04 AM, Peter Eisentraut wrote: On 4/6/17 03:50, Craig Ringer wrote: But otherwise, pending docs changes, I think it's ready for committer. My opinion is still that this is ultimately the wrong

Re: [HACKERS] src/interfaces/libpq shipping nmake-related Makefiles

On 2017-04-07 00:01:01 -0400, Tom Lane wrote: > Still, it's not very clear why we need to cater for building just libpq > rather than the whole distribution, and a user of win32.mak presumably > has the option to do the latter. I think the raison d'etre for that infrastructure primarily comes

Re: [HACKERS] Faster methods for getting SPI results (460% improvement)

On 2017-04-06 09:14:43 -0700, Jim Nasby wrote: > On 4/6/17 9:04 AM, Peter Eisentraut wrote: > > On 4/6/17 03:50, Craig Ringer wrote: > > > But otherwise, pending docs changes, I think it's ready for committer. > > > > My opinion is still that this is ultimately the wrong approach. The > > right

Re: [HACKERS] src/interfaces/libpq shipping nmake-related Makefiles

I wrote: > Michael Paquier writes: >> While looking at some SCRAM stuff, I have bumped into bcc32.mak and >> win32.mak in src/interfaces/libpq. To put it short: those files are >> not up to date. The code of SCRAM is in the tree for a bit of time >> now, and should have

Re: [HACKERS] Faster methods for getting SPI results (460% improvement)

On 4/6/17 8:13 PM, Tom Lane wrote: It's on the pointy end for Pg10, and I thought we'd be fine to include this in pg10 then aim to clean up DestReceiver in early pg11, or even as a post-feature-freeze refactoring fixup in pg10. Should the callback approach be blocked because the API it has to

Re: [HACKERS] No-op case in ExecEvalConvertRowtype

Ashutosh Bapat writes: > While I agree that we can remove indesc->tdtypeid == > outdesc->tdtypeid, I am not sure whether it should be replaced by > !indesc->tdhasoid && !outdesc->tdhasoid. No, that was overly conservative; the correct test is that the tdhasoid

Re: [HACKERS] src/interfaces/libpq shipping nmake-related Makefiles

Michael Paquier writes: > While looking at some SCRAM stuff, I have bumped into bcc32.mak and > win32.mak in src/interfaces/libpq. To put it short: those files are > not up to date. The code of SCRAM is in the tree for a bit of time > now, and should have updated those

Re: [HACKERS] No-op case in ExecEvalConvertRowtype

On Fri, Apr 7, 2017 at 5:06 AM, Tom Lane wrote: > So I now think it's okay to remove consideration of matching the target > rowtype OID from the tupconvert.c functions, although we have to realize > that that is effectively an API change for them, one which has a definite >

Re: [HACKERS] No-op case in ExecEvalConvertRowtype

On Fri, Apr 7, 2017 at 7:35 AM, Tom Lane wrote: > Amit Langote writes: >> ... One of >> the earlier versions of that patch introduced a consider_typeid parameter >> for which only ExecEvalConvertRowtype() passed true. > > Yeah, I was thinking of

Re: [HACKERS] No-op case in ExecEvalConvertRowtype

On Fri, Apr 7, 2017 at 7:28 AM, Amit Langote wrote: > > And I see that just in 3f902354b08 lets the partition tuple-routing code > keep utilizing that optimization. I am not able to find this commit fatal: ambiguous argument '3f902354b08': unknown revision or path

Re: [HACKERS] Faster methods for getting SPI results (460% improvement)

Craig Ringer writes: > On 7 April 2017 at 00:54, Tom Lane wrote: >> ... External callers will only be >> interested in the result of the canSetTag subquery. > I wasn't aware that such queries could ever return a result set, though. Possibly not, but

Re: [HACKERS] No-op case in ExecEvalConvertRowtype

On Thu, Apr 6, 2017 at 8:51 PM, Tom Lane wrote: > Ashutosh Bapat writes: >> In ExecEvalConvertRowtype(), if the input row doesn't require any >> conversion, we simply return that row as is. > > Huh. That's been like that for a very long time.

[HACKERS] Compilation warning with MSVC in pg_depend.c

Hi all, I am getting the following warning with MSVC 2010 for what is a result of 3217327 (identity columns): c:\users\michael\git\postgres\src\backend\catalog\pg_depend.c(615): warning C4715: 'getOwnedSequence' : not all control paths return a value

Re: [HACKERS] Time to change pg_regress diffs to unified by default?

Peter Eisentraut writes: > I think one problem is that diff -u is not as portable as diff -c. For > example, the HP-UX 11 man page of diff doesn't list it. FWIW, I can confirm that HPUX 10.20's diff hasn't got it. That would not affect gaur/pademelon, if we

Re: [HACKERS] Undefined psql variables

At Thu, 6 Apr 2017 19:21:21 -0400, Corey Huinker wrote in

[HACKERS] src/interfaces/libpq shipping nmake-related Makefiles

Hi all, While looking at some SCRAM stuff, I have bumped into bcc32.mak and win32.mak in src/interfaces/libpq. To put it short: those files are not up to date. The code of SCRAM is in the tree for a bit of time now, and should have updated those files to list and clean up objects, but nobody has

Re: [HACKERS] PATCH: recursive json_populate_record()

On 04/05/2017 07:24 PM, Andrew Dunstan wrote: > > OK, I have been through this and I think it's basically committable. I > am currently doing some cleanup, such as putting all the typedefs in one > place, fixing redundant comments and adding more comments, declaring all > the static functions,

Re: [HACKERS] logical replication apply to run with sync commit off by default

On 7 April 2017 at 01:38, Peter Eisentraut wrote: > I think this change could use some more documentation. Under what > circumstances would a user want to turn this back on? The main reason is if you want to use synchronous_standby_names and synchronous commit

Re: [HACKERS] Implementation of SASLprep for SCRAM-SHA-256

On Fri, Apr 7, 2017 at 2:47 AM, Heikki Linnakangas wrote: > On 04/06/2017 08:42 PM, Heikki Linnakangas wrote: >>> There is for example this portion in the new tables: >>> +static const Codepoint prohibited_output_chars[] = >>> +{ >>> + 0xD800, 0xF8FF, /* C.3, C.5 */

Re: [HACKERS] Faster methods for getting SPI results (460% improvement)

On 7 April 2017 at 00:54, Tom Lane wrote: > I can certainly get on board with the idea of letting a SPI caller provide > a DestReceiver instead of accumulating the query results into a > SPITupleTable, but the way it was done here seems quite bizarre. I think > for instance

Re: [HACKERS] Time to change pg_regress diffs to unified by default?

On Thu, Apr 06, 2017 at 07:01:32PM -0400, Tom Lane wrote: > Andres Freund writes: > > I personally, and I know of a bunch of other regular contributors, find > > context diffs very hard to read. Besides general dislike, for things > > like regression test output context diffs

Re: [HACKERS] Time to change pg_regress diffs to unified by default?

On 7 April 2017 at 10:31, Andres Freund wrote: > Hi, > > I personally, and I know of a bunch of other regular contributors, find > context diffs very hard to read. Besides general dislike, for things > like regression test output context diffs are just not well suited. > E.g.

Re: [HACKERS] No-op case in ExecEvalConvertRowtype

Amit Langote writes: > ... One of > the earlier versions of that patch introduced a consider_typeid parameter > for which only ExecEvalConvertRowtype() passed true. Yeah, I was thinking of adding a flag along that line to fix this, but desisted after figuring out

[HACKERS] pg_basebackup: Allow use of arbitrary compression program

Hello, Back in pg 9.2, we hacked a copy of pg_basebackup to add a command line option which would allow the user to specify an arbitrary external program (potentially including arguments) to be used to compress the tar backup. Our motivation was to be able to use pigz (parallel gzip

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

On 7 April 2017 at 13:41, Tom Lane wrote: > David Rowley writes: >> On 7 April 2017 at 11:47, Tom Lane wrote: >>> What I'm on about is that you can't do the early advance to the >>> next outer tuple unless you're sure that

Re: [HACKERS] No-op case in ExecEvalConvertRowtype

On 2017/04/07 8:36, Tom Lane wrote: > I wrote: >> I propose to deal with this by reverting 3838074f8 in toto, and then >> trying to clarify that comment, and maybe adding a regression test case >> based on the example I showed earlier so that it will be a little more >> obvious if someone breaks

Re: [HACKERS] Time to change pg_regress diffs to unified by default?

On 04/06/2017 09:17 PM, Peter Eisentraut wrote: > On 4/6/17 18:31, Andres Freund wrote: >> I personally have PG_REGRESS_DIFF_OPTS set to -dU10, but that doesn't >> help much analyzing buildfarm output. >> >> Therefore I propose changing the defaults in pg_regress.c. > I think one problem is that

Re: [HACKERS] scram and \password

On Thu, Apr 6, 2017 at 8:04 AM, Michael Paquier wrote: > On Thu, Apr 6, 2017 at 2:11 AM, Heikki Linnakangas wrote: >> At a quick glance, moving pg_frontend_random() to src/common looks like a >> non-starter. It uses pglock_thread() which is internal to

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

David Rowley writes: > On 7 April 2017 at 11:47, Tom Lane wrote: >> What I'm on about is that you can't do the early advance to the >> next outer tuple unless you're sure that all the quals that were >> relevant to the uniqueness proof have been

[HACKERS] Question about one of the old Autonomous Transaction approach

Hi All, Regarding the discussion about Autonomous transaction in below message ID, long time ago, it has been specified that having a new structure "Struct PGAutonomousXACT" was rejected in PGCon hackers meeting. Can anyone know why is it been rejected? What is the disadvantage/problem identified

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

On 7 April 2017 at 11:47, Tom Lane wrote: > David Rowley writes: >> On 7 April 2017 at 07:26, Tom Lane wrote: >>> I'm looking through this, and I'm failing to see where it deals with >>> the problem we discussed last time,

Re: [HACKERS] Time to change pg_regress diffs to unified by default?

On 4/6/17 18:31, Andres Freund wrote: > I personally have PG_REGRESS_DIFF_OPTS set to -dU10, but that doesn't > help much analyzing buildfarm output. > > Therefore I propose changing the defaults in pg_regress.c. I think one problem is that diff -u is not as portable as diff -c. For example,

Re: [HACKERS] Bug with pg_basebackup and 'shared' tablespace

Hi, Pierre. Maybe you're the winner:p At Thu, 06 Apr 2017 12:34:09 +0200, Pierre Ducroquet wrote in <1714428.BHRm6e8A2D@peanuts2> > On Thursday, April 6, 2017 2:00:55 PM CEST Kyotaro HORIGUCHI wrote: > > https://www.postgresql.org/docs/9.6/static/manage-ag-tablespaces.html

Re: [HACKERS] Logical Replication and Character encoding

At Thu, 6 Apr 2017 14:43:56 -0400, Peter Eisentraut wrote in <330a093a-d155-c866-cbf2-8f36fdf51...@2ndquadrant.com> > On 4/6/17 11:47, Peter Eisentraut wrote: > > On 4/5/17 21:32, Kyotaro HORIGUCHI wrote: > >> At Wed, 5 Apr 2017 11:33:51 -0400, Peter Eisentraut

Re: [HACKERS] Duplicate usage of tablespace location?

I don't mean that this is the only or best way to go. I apologize for the possible lack of explanation. At Thu, 06 Apr 2017 12:03:51 -0400, Tom Lane wrote in <21084.1491494...@sss.pgh.pa.us> > Kyotaro HORIGUCHI writes: > > I noticed by the

Re: [HACKERS] Remove pg_stat_progress_vacuum from Table 28.2

On 2017/04/07 0:56, Fujii Masao wrote: > On Tue, Apr 4, 2017 at 10:19 AM, Amit Langote > wrote: >> It seems pg_stat_progress_vacuum is not supposed to appear in the table >> titled "Collected Statistics Views". It was added by c16dc1aca. Attached >> patch fixes

[HACKERS] BRIN desummarization writes junk WAL records

I am seeing the database fail to restart after a crash during the regression tests, due to a divide-by-zero fault in BRIN wal replay. Core was generated by `postgres: startup'. Program terminated with signal 8, Arithmetic exception. #0 brinSetHeapBlockItemptr (buf=, pagesPerRange=0,

Re: [HACKERS] pgbench - allow to store select results into variables

>> Having said all that, I think we're at the point in the commitfest >> where if there's any design question at all about a patch, it should >> get booted to the next cycle. We are going to have more than enough >> to do to stabilize what's already committed, we don't need to be >> adding more

Re: [HACKERS] Making clausesel.c Smarter

On 7 April 2017 at 09:05, Claudio Freire wrote: > On Tue, Apr 4, 2017 at 1:00 PM, Claudio Freire wrote: If you ask me, I'd just leave: + if (rqlist->hibound == DEFAULT_INEQ_SEL || rqlist->lobound == DEFAULT_INEQ_SEL) + {

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

David Rowley writes: > On 7 April 2017 at 07:26, Tom Lane wrote: >> I'm looking through this, and I'm failing to see where it deals with >> the problem we discussed last time, namely that you can't apply the >> optimization unless all clauses

Re: [HACKERS] increasing the default WAL segment size

On Fri, Apr 7, 2017 at 2:35 AM, Tomas Vondra wrote: > On 04/06/2017 08:33 PM, David Steele wrote: >> >> >> I'm in favor of 16,64,256,1024. >> >> > I don't see a particular reason for this, TBH. The sweet spots will be > likely dependent hardware / OS configuration

Re: [HACKERS] No-op case in ExecEvalConvertRowtype

I wrote: > I propose to deal with this by reverting 3838074f8 in toto, and then > trying to clarify that comment, and maybe adding a regression test case > based on the example I showed earlier so that it will be a little more > obvious if someone breaks this again. > However, I see that 3838074f8

Re: [HACKERS] increasing the default WAL segment size

Hello, On Wed, Apr 5, 2017 at 6:06 PM, Peter Eisentraut < peter.eisentr...@2ndquadrant.com> wrote: > > (Roughly speaking, to get started, this would mean compiling with > --with-wal-segsize 16, 32, 64, 128, 256, run make check-world both > sequentially and in parallel, and take note of a)

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

On 7 April 2017 at 07:26, Tom Lane wrote: > I'm looking through this, and I'm failing to see where it deals with > the problem we discussed last time, namely that you can't apply the > optimization unless all clauses that were used in the uniqueness > proof are included in the

Re: [HACKERS] Undefined psql variables

On Sun, Apr 2, 2017 at 4:57 PM, Fabien COELHO wrote: > > I'm inclined to suggest that we should require all extensions beyond the >> boolean-literal case to be set up as a keyword followed by appropriate >> argument(s); that seems like it's enough to prevent syntax conflicts

Re: [HACKERS] [COMMITTERS] pgsql: Collect and use multi-column dependency stats

On 6 April 2017 at 17:41, David Rowley wrote: > On 7 April 2017 at 00:47, Simon Riggs wrote: >> On 5 April 2017 at 18:48, Tom Lane wrote: >>> Simon Riggs writes: Collect and use multi-column

Re: [HACKERS] increasing the default WAL segment size

On 4/6/17 6:52 PM, Tomas Vondra wrote: > On 04/06/2017 11:45 PM, David Steele wrote: >> >> How many people in the field are running custom builds of >> Postgres? And of those, how many have changed the WAL segment size? >> I've never encountered a non-standard segment size or talked to anyone >>

Re: [HACKERS] Time to change pg_regress diffs to unified by default?

Andres Freund writes: > I personally, and I know of a bunch of other regular contributors, find > context diffs very hard to read. Besides general dislike, for things > like regression test output context diffs are just not well suited. Personally, I disagree completely.

Re: [HACKERS] increasing the default WAL segment size

On 04/06/2017 11:45 PM, David Steele wrote: On 4/6/17 5:05 PM, Tomas Vondra wrote: On 04/06/2017 08:33 PM, David Steele wrote: On 4/5/17 7:29 AM, Simon Riggs wrote: 2. It's not clear to me the advantage of being able to pick varying filesizes. I see great disadvantage in having too many

Re: [HACKERS] Time to change pg_regress diffs to unified by default?

On 04/06/2017 06:31 PM, Andres Freund wrote: > Hi, > > I personally, and I know of a bunch of other regular contributors, find > context diffs very hard to read. Besides general dislike, for things > like regression test output context diffs are just not well suited. > E.g. in >

Re: [HACKERS] Time to change pg_regress diffs to unified by default?

On Fri, Apr 7, 2017 at 10:31 AM, Andres Freund wrote: > Hi, > > I personally, and I know of a bunch of other regular contributors, find > context diffs very hard to read. Besides general dislike, for things > like regression test output context diffs are just not well suited.

Re: [HACKERS] Letting the client choose the protocol to use during a SASL exchange

On Fri, Apr 7, 2017 at 7:29 AM, Simon Riggs wrote: > On 6 April 2017 at 16:15, Álvaro Hernández Tortosa wrote: > >> Per the SCRAM RFC, it is the server who advertises and the client who >> picks. > > Yes, but what does the RFC say about how to handle

[HACKERS] Time to change pg_regress diffs to unified by default?

Hi, I personally, and I know of a bunch of other regular contributors, find context diffs very hard to read. Besides general dislike, for things like regression test output context diffs are just not well suited. E.g. in

Re: [HACKERS] Letting the client choose the protocol to use during a SASL exchange

On 6 April 2017 at 16:15, Álvaro Hernández Tortosa wrote: > Per the SCRAM RFC, it is the server who advertises and the client who > picks. Yes, but what does the RFC say about how to handle servers with an pg_hba.conf? How and what will we advertise? -- Simon Riggs

Re: [HACKERS] Letting the client choose the protocol to use during a SASL exchange

On Fri, Apr 7, 2017 at 5:15 AM, Álvaro Hernández Tortosa wrote: > I don't see it. The message AuthenticationSASL.String could contain a > CSV of the SCRAM protocols supported. This is specially important to support > channel binding (which is just another protocol name for

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

On Thu, Apr 6, 2017 at 2:50 PM, Andres Freund wrote: > Pushed with very minor wording changes. This had a typo: + * If copy is true, the slot receives a copied tuple that'll that will stay -- Peter Geoghegan VMware vCenter Server https://www.vmware.com/ -- Sent via

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

On Thu, Apr 6, 2017 at 2:50 PM, Andres Freund wrote: > Pushed with very minor wording changes. Thanks Andres. -- Peter Geoghegan VMware vCenter Server https://www.vmware.com/ -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your

Re: [HACKERS] partitioned tables and contrib/sepgsql

On 04/06/2017 12:35 PM, Tom Lane wrote: > Joe Conway writes: >> Any thoughts on whether 0001a and 0001b ought to be backpatched? I'm >> thinking not given the lack of past complaints but it might make sense >> to do. > > I think 0001a absolutely needs to be, because it is

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

On 2017-03-13 18:14:07 -0700, Peter Geoghegan wrote: > 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

Re: [HACKERS] BRIN cost estimate

Tom Lane wrote: > TBH, I think that code is in the noise. It doesn't involve any disk > access, or catalog access, or user-defined function calls. I wouldn't > bother trying to account for it. I removed it in the pushed version. > What you should be accounting for is the ensuing heap page

Re: [HACKERS] increasing the default WAL segment size

On 4/6/17 5:05 PM, Tomas Vondra wrote: > On 04/06/2017 08:33 PM, David Steele wrote: >> On 4/5/17 7:29 AM, Simon Riggs wrote: >> >>> 2. It's not clear to me the advantage of being able to pick varying >>> filesizes. I see great disadvantage in having too many options, which >>> greatly increases

Re: [HACKERS] [COMMITTERS] pgsql: Collect and use multi-column dependency stats

On 7 April 2017 at 00:47, Simon Riggs wrote: > On 5 April 2017 at 18:48, Tom Lane wrote: >> Simon Riggs writes: >>> Collect and use multi-column dependency stats >> >> The buildfarm is unhappy about the fact that this changed the

Re: [HACKERS] parallel explain analyze support not exercised

On 2017-04-06 17:33:49 -0400, Tom Lane wrote: > Andres Freund writes: > > I guess we'll have to see. My personal conclusion is that greater > > coverage of parallelism is worth some very minor config trouble for > > people doing installcheck against clusters with non-default

Re: [HACKERS] parallel explain analyze support not exercised

Andres Freund writes: > I guess we'll have to see. My personal conclusion is that greater > coverage of parallelism is worth some very minor config trouble for > people doing installcheck against clusters with non-default config. The buildfarm seems entirely unwilling to play

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

On Thu, Apr 6, 2017 at 2:05 PM, Andres Freund wrote: > I'm not sure you entirely got my point here. If tuplesort_gettupleslot > is called with copy = true, it'll store that tuple w/ > ExecStoreMinimalTuple passing shouldFree = copy = true. If the caller > is in a short-lived

Re: [HACKERS] No-op case in ExecEvalConvertRowtype

I wrote: > Ashutosh Bapat writes: >> In ExecEvalConvertRowtype(), if the input row doesn't require any >> conversion, we simply return that row as is. > Huh. That's been like that for a very long time. So I imagined that this was an ancient bug, and was

Re: [HACKERS] [COMMITTERS] pgsql: Increase parallel bitmap scan test coverage.

On 2017-04-06 20:43:48 +, Andres Freund wrote: > Increase parallel bitmap scan test coverage. > > Author: Dilip Kumar > Discussion: > https://postgr.es/m/20170331184603.qcp7t4md5bzxb...@alap3.anarazel.de This turned the !linux buildfarm red, because it relies on setting

Re: [HACKERS] Making clausesel.c Smarter

On Tue, Apr 4, 2017 at 1:00 PM, Claudio Freire wrote: >>> If you ask me, I'd just leave: >>> >>> + if (rqlist->hibound == DEFAULT_INEQ_SEL || rqlist->lobound == >>> DEFAULT_INEQ_SEL) >>> + { >>> + /* No point in checking null selectivity, DEFAULT_INEQ_SEL >>> implies

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

On 2017-04-04 13:49:11 -0700, Peter Geoghegan wrote: > On Tue, Apr 4, 2017 at 1:32 PM, Andres Freund wrote: > >> static bool > >> tuplesort_gettuple_common(Tuplesortstate *state, bool forward, > >> @@ -2091,12 +2092,15 @@ tuplesort_gettuple_common(Tuplesortstate *state, >

Re: [HACKERS] increasing the default WAL segment size

On 04/06/2017 08:33 PM, David Steele wrote: On 4/5/17 7:29 AM, Simon Riggs wrote: On 5 April 2017 at 06:04, Beena Emerson wrote: The WALfilename - LSN mapping disruption for higher values you mean? Is there anything else I have missed? I see various issues raised

Re: [HACKERS] parallel explain analyze support not exercised

Hi, On 2017-04-03 17:11:33 -0400, Robert Haas wrote: > On Mon, Apr 3, 2017 at 3:31 PM, Andres Freund wrote: > >> If this is 'make check', then we should have 8 parallel workers > >> allowed, so if we only do one of these at a time, then I think we're > >> OK. But if somebody

Re: [HACKERS] parallel bitmapscan isn't exercised in regression tests

On 2017-04-06 10:00:32 +0530, Dilip Kumar wrote: > On Tue, Apr 4, 2017 at 5:51 AM, Dilip Kumar wrote: > > Sure I can do that, In attached patch, I only fixed the problem of not > > executing the bitmap test. Now, I will add few cases to cover other > > parts especially

Re: [HACKERS] TPC-H Q20 from 1 hour to 19 hours!

Hi, I've been looking at this issue today, and so far I don't think it's a bug in the foreign key estimation. It seems mostly that the 9.5 estimates were hopelessly bad, and the join estimation changes simply pushed it a tiny bit the wrong direction. Although maybe there is a bug (or at

Re: [HACKERS] Letting the client choose the protocol to use during a SASL exchange

On 6 April 2017 at 16:05, Tom Lane wrote: > Perhaps we could turn this around: have the client send (in the connection > request packet) a list of auth protocols it thinks it is able to handle. > (I'm envisioning this as being more or less fixed for any one version of > any

Re: [HACKERS] Letting the client choose the protocol to use during a SASL exchange

On 06/04/17 22:05, Tom Lane wrote: Simon Riggs writes: How would we provide the list of protocols? Surely the protocol is defined by pg_hba.conf, which makes it dependent upon username, database and ip range. If the list were accurate, it would allow an attacker to

Re: [HACKERS] Letting the client choose the protocol to use during a SASL exchange

Simon Riggs writes: > How would we provide the list of protocols? Surely the protocol is > defined by pg_hba.conf, which makes it dependent upon username, > database and ip range. If the list were accurate, it would allow an > attacker to discover how best to attack. If the

[HACKERS] Row Level Security UPDATE Confusion

I'm a little confused on why a SELECT policy fires against the NEW record for an UPDATE when using multiple FOR policies. The ALL policy doesn't seem to have that restriction. DROP TABLE IF EXISTS t; CREATE USER simple; CREATE USER split; CREATE TABLE t(value int); grant select, update on table

Re: [HACKERS] Letting the client choose the protocol to use during a SASL exchange

On 4 April 2017 at 02:02, Michael Paquier wrote: > Hi all, > > There is still one open item pending for SCRAM that has not been > treated which is mentioned here: > https://www.postgresql.org/message-id/b081887e-1712-3aa4-7dbe-e012333d5...@iki.fi > > When doing an

Re: [HACKERS] partitioned tables and contrib/sepgsql

Joe Conway writes: > Any thoughts on whether 0001a and 0001b ought to be backpatched? I'm > thinking not given the lack of past complaints but it might make sense > to do. I think 0001a absolutely needs to be, because it is fixing what is really an ABI violation:

  1   2   >