Re: [HACKERS] Merge join for GiST

2017-04-13 7:01 GMT+05:00 Jeff Davis : > On Tue, Apr 11, 2017 at 8:35 AM, Alexander Korotkov > wrote: >> On Tue, Apr 11, 2017 at 5:46 PM, Jeff Davis wrote: >>> Do you have a sense of how this might compare with range merge join? >>

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

On Wed, Apr 12, 2017 at 10:42 PM, Robert Haas wrote: > On Tue, Apr 11, 2017 at 1:20 PM, Pavan Deolasee > > > 5. Added code to set a CLEAR pointer to a WARM pointer when we know that > the > > entire chain is WARM. This should address the workload Dilip ran and > found >

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

On Thu, Apr 13, 2017 at 2:04 AM, Peter Geoghegan wrote: > On Wed, Apr 12, 2017 at 10:12 AM, Robert Haas > wrote: > >> I may have missed something, but there is no intention to ignore known > >> regressions/reviews. Of course, I don't think that every

Re: [HACKERS] snapbuild woes

On April 12, 2017 9:58:12 PM PDT, Noah Misch wrote: >On Wed, Apr 12, 2017 at 10:21:51AM -0700, Andres Freund wrote: >> On 2017-04-12 11:03:57 -0400, Peter Eisentraut wrote: >> > On 4/12/17 02:31, Noah Misch wrote: >> > >>> But I hope you mean to commit these snapbuild patches

Re: [HACKERS] Logical replication and inheritance

On Wed, Apr 12, 2017 at 11:02:44AM -0400, Peter Eisentraut wrote: > On 4/9/17 22:16, Noah Misch wrote: > > On Wed, Apr 05, 2017 at 08:25:56AM -0400, Peter Eisentraut wrote: > >> After thinking about it some more, I think the behavior we want would be > >> that changes to inheritance would reflect

Re: [HACKERS] snapbuild woes

On Wed, Apr 12, 2017 at 10:21:51AM -0700, Andres Freund wrote: > On 2017-04-12 11:03:57 -0400, Peter Eisentraut wrote: > > On 4/12/17 02:31, Noah Misch wrote: > > >>> But I hope you mean to commit these snapbuild patches before the > > >>> postgres 10 > > >>> release? As far as I know, logical

Re: [HACKERS] tablesync patch broke the assumption that logical rep depends on?

On Tue, Apr 11, 2017 at 02:28:44AM +0900, Fujii Masao wrote: > src/backend/replication/logical/launcher.c > * Worker started and attached to our shmem. This check is safe > * because only launcher ever starts the workers, so nobody can steal > * the worker slot.

Re: [HACKERS] WAL logging problem in 9.4.3?

On Tue, Apr 11, 2017 at 5:38 PM, Kyotaro HORIGUCHI wrote: > Sorry, what I have just sent was broken. You can use PROVE_TESTS when running make check to select a subset of tests you want to run. I use that all the time when working on patches dedicated to certain

Re: [HACKERS] [sqlsmith] ERROR: badly formatted node string "RESTRICTINFO...

On Wed, Apr 12, 2017 at 10:30 PM, Tom Lane wrote: > Amit Kapila writes: >> On Wed, Apr 12, 2017 at 12:40 AM, Tom Lane wrote: >>> Anyone want to draft a patch for this? > >> Please find patch attached based on above discussion. > >

Re: [HACKERS] Inadequate parallel-safety check for SubPlans

On Thu, Apr 13, 2017 at 1:05 AM, Tom Lane wrote: > Robert Haas writes: >> On Wed, Apr 12, 2017 at 2:41 PM, Tom Lane wrote: >>> This is 100% wrong. It's failing to recurse into the subexpressions of >>> the SubPlan, which could very

Re: [HACKERS] Remove pg_stat_progress_vacuum from Table 28.2

On 2017/04/13 12:11, Fujii Masao wrote: > On Wed, Apr 12, 2017 at 10:32 AM, Amit Langote > wrote: >> On 2017/04/12 0:22, Fujii Masao wrote: >>> On Fri, Apr 7, 2017 at 9:53 AM, Amit Langote >>> wrote: On 2017/04/07 0:56, Fujii

Re: [HACKERS] logical replication and PANIC during shutdown checkpoint in publisher

On Thu, Apr 13, 2017 at 12:28 PM, Fujii Masao wrote: > On Thu, Apr 13, 2017 at 5:25 AM, Peter Eisentraut > wrote: >> On 4/12/17 09:55, Fujii Masao wrote: >>> To fix this issue, we should terminate walsender for logical replication >>>

Re: [HACKERS] GSOC'17 project introduction: Parallel COPY execution with errors handling

On 13 April 2017 at 01:57, Stas Kelvich wrote: > However I think it worth of quick research whether it is possible to create > special > code path for COPY in which errors don’t cancel transaction. Not really. Anything at any layer of the system expects to be able to

Re: [HACKERS] logical replication and PANIC during shutdown checkpoint in publisher

On Thu, Apr 13, 2017 at 5:25 AM, Peter Eisentraut wrote: > On 4/12/17 09:55, Fujii Masao wrote: >> To fix this issue, we should terminate walsender for logical replication >> before shutdown checkpoint starts. Of course walsender for physical >> replication still

Re: [HACKERS] Remove pg_stat_progress_vacuum from Table 28.2

On Wed, Apr 12, 2017 at 10:32 AM, Amit Langote wrote: > On 2017/04/12 0:22, Fujii Masao wrote: >> On Fri, Apr 7, 2017 at 9:53 AM, Amit Langote >> wrote: >>> On 2017/04/07 0:56, Fujii Masao wrote: On Tue, Apr 4, 2017 at 10:19 AM,

[HACKERS] Different table schema in logical replication crashes

Hi, If a certain table has different schemas and the subscriber table has an unmatched column with a not null constraint, the logical replication crashes with the above stack trace. -- publisher CREATE TABLE test (a integer, b varchar not null, c numeric not null, PRIMARY KEY(a)); -- subscriber

Re: [HACKERS] delta relations in AFTER triggers

> > Great. Thanks. I wonder if there is some way we can automatically > include code fragments in the documentation without keeping them in > sync manually. > > In whatever extra docs you add, could you include an example of an INSERT ON CONFLICT, and potentially a CTE query that does two

Re: [HACKERS] pg_upgrade vs extension upgrades

On Wed, Apr 12, 2017 at 06:59:32PM -0400, Robert Haas wrote: > On Wed, Apr 12, 2017 at 6:30 PM, Peter Eisentraut > > If I restore a dump into another instance, I need to upgrade all my > > extensions to that installations's versions, no? That's not particular > > to pg_upgrade. > > No, it's an

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

On Thu, Apr 13, 2017 at 6:37 AM, Álvaro Hernández Tortosa wrote: > By looking at the them, and unless I'm missing something, I don't see > how the extra information for the future implementation of channel binding > would be added (without changing the protocol). Relevant

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

On Wed, Apr 12, 2017 at 11:46 PM, Peter Eisentraut wrote: > On 4/12/17 00:48, Masahiko Sawada wrote: >> On Wed, Apr 12, 2017 at 1:28 PM, Peter Eisentraut >>> Perhaps instead of a global last_start_time, we store a per relation >>> last_start_time in

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

On Thu, Apr 13, 2017 at 2:34 AM, Heikki Linnakangas wrote: > On 04/11/2017 02:32 PM, Álvaro Hernández Tortosa wrote: >> >> So I still see your proposal more awkward and less clear, mixing >> things that are separate. But again, your choice :) > > > So, here's my more

Re: [HACKERS] Tab completion support for ALTER SUBSCRIPTION REFRESH PUBLICATION

On Thu, Apr 13, 2017 at 11:05 AM, Masahiko Sawada wrote: > On Wed, Apr 12, 2017 at 11:48 PM, Fujii Masao wrote: >> On Wed, Apr 12, 2017 at 5:12 PM, Masahiko Sawada >> wrote: >>> Hi, >>> >>> I've attached a patch for $subject.

Re: [HACKERS] SUBSCRIPTIONS and pg_upgrade

On 4/11/17 22:16, Peter Eisentraut wrote: > On 4/10/17 13:58, Peter Eisentraut wrote: >> Proposal: Dump subscriptions if running as superuser. If not, check if >> there are subscriptions and warn about that. Remove current pg_dump >> --include-subscriptions option. > > Patch for this part. And

Re: [HACKERS] Some thoughts about SCRAM implementation

On Thu, Apr 13, 2017 at 3:21 AM, Robert Haas wrote: > On Wed, Apr 12, 2017 at 2:09 PM, Heikki Linnakangas wrote: >> Yes, we need to nail down the protocol and \password before beta. I am >> working on them now. > > Good to hear. FWIW, there are patches

Re: [HACKERS] Tab completion support for ALTER SUBSCRIPTION REFRESH PUBLICATION

On Wed, Apr 12, 2017 at 11:48 PM, Fujii Masao wrote: > On Wed, Apr 12, 2017 at 5:12 PM, Masahiko Sawada > wrote: >> Hi, >> >> I've attached a patch for $subject. Please check it. > > + COMPLETE_WITH_LIST8("WITH", "CONNECTION", "SET PUBLICATION",

Re: [HACKERS] Foreign Join pushdowns not working properly for outer joins

On 13 April 2017 at 11:22, Peter Eisentraut wrote: > Is this patch considered ready for review as a backpatch candidate? Yes, however, the v5 patch is based on master. The v4 patch should apply to 9.6. Diffing the two patches I see another tiny change to a

Re: [HACKERS] Merge join for GiST

On Tue, Apr 11, 2017 at 8:35 AM, Alexander Korotkov wrote: > On Tue, Apr 11, 2017 at 5:46 PM, Jeff Davis wrote: >> Do you have a sense of how this might compare with range merge join? > > > If you have GiST indexes over ranges for both sides of join,

Re: [HACKERS] pg_dump emits ALTER TABLE ONLY partitioned_table

On 2017/04/13 6:22, Robert Haas wrote: > On Wed, Apr 12, 2017 at 3:29 PM, Stephen Frost wrote: >> I'm not following what you're getting at here. >> >> There's already a constraint on the table, and ALTER TABLE ONLY doesn't >> say anything about what happens later on (certainly

Re: [HACKERS] Partitioned tables and relfilenode

On 2017/04/13 0:36, Robert Haas wrote: > On Tue, Apr 11, 2017 at 10:15 PM, Amit Langote > wrote: >> Alright. So I made it into two patches instead: 0001 fixes the bug that >> validateCheckConstraint() tries to scan partitioned tables and 0002 makes >> trying to

Re: [HACKERS] Function to control physical replication slot

On 2017-04-12 20:15:52 -0400, Peter Eisentraut wrote: > On 4/11/17 05:15, Magnus Hagander wrote: > > Is there a particular reason we don't have a function to *set* the > > restart_lsn of a replication slot, other than to drop it and recreate it? > > I suppose there could be lots of problems if

Re: [HACKERS] snapbuild woes

Hi, On 2017-03-03 01:30:11 +0100, Petr Jelinek wrote: > From 7d5b48c8cb80e7c867b2096c999d08feda50b197 Mon Sep 17 00:00:00 2001 > From: Petr Jelinek > Date: Fri, 24 Feb 2017 21:39:03 +0100 > Subject: [PATCH 1/5] Reserve global xmin for create slot snasphot export > >

Re: [HACKERS] Function to control physical replication slot

On 4/11/17 05:15, Magnus Hagander wrote: > Is there a particular reason we don't have a function to *set* the > restart_lsn of a replication slot, other than to drop it and recreate it? I suppose there could be lots of problems if the LSN you specify isn't valid. And it might be hard to

Re: [HACKERS] pg_upgrade vs extension upgrades

On 4/12/17 18:59, Robert Haas wrote: > I do think there might be some value in a tool that looked for old > extensions and tried to update them, but I'm not sure it should be > pg_dump. This reminds me a bit of the problem of upgrading all collations after an upgrade. Perhaps we can find similar

Re: [HACKERS] pg_statistic_ext.staenabled might not be the best column name

On 04/12/2017 03:36 PM, David Rowley wrote: "stakind" seems like a better name. I'd have personally gone with "statype" but pg_statistic already thinks stakind is better. +1 to stakind -- Tomas Vondra http://www.2ndQuadrant.com PostgreSQL Development, 24x7 Support, Remote

Re: [HACKERS] Foreign Join pushdowns not working properly for outer joins

Is this patch considered ready for review as a backpatch candidate? -- Peter Eisentraut http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your

Re: [pgsql-www] [HACKERS] Small issue in online devel documentation build

On 4/12/17 09:50, Bruce Momjian wrote: > On Wed, Apr 12, 2017 at 01:31:51PM +0200, Magnus Hagander wrote: >> I think that only leaves the change to the javascript code that Bruce sent. >> Let's see if we can figure out a way to do that one without requiring >> javascript, but after that we have

Re: [HACKERS] pg_upgrade vs extension upgrades

On Wed, Apr 12, 2017 at 6:30 PM, Peter Eisentraut wrote: > On 4/10/17 11:30, Magnus Hagander wrote: >> After you've run pg_upgrade, you have to loop through all your databases >> and do an "ALTER EXTENSION abc UPDATE" once for each extension. >> >> Is there a

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

On 2017-04-05 09:39:37 -0400, Tom Lane wrote: > Andres Freund writes: > > On 2017-04-05 02:47:55 -0400, Noah Misch wrote: > >> [Action required within three days. This is a generic notification.] > > > I've a very preliminary patch. I'd like to only start polishing it up > >

Re: [pgsql-www] [HACKERS] Small issue in online devel documentation build

On 4/12/17 15:43, Peter Eisentraut wrote: > On 4/12/17 07:31, Magnus Hagander wrote: >> Once difference I notice is that for example the "note boxes" are no >> longer centered, but they do now get the new formatting. > > I have committed something for that. The issue was that the generated >

Re: [HACKERS] SUBSCRIPTIONS and pg_upgrade

On 4/11/17 23:41, Noah Misch wrote: > On Tue, Apr 11, 2017 at 11:21:24PM -0400, Peter Eisentraut wrote: >> On 4/9/17 22:16, Noah Misch wrote: >>> [Action required within three days. This is a generic notification.] >> >> Patches have been posted. Discussion is still going on a bit. > > By what

Re: [HACKERS] pg_upgrade vs extension upgrades

On 4/10/17 11:30, Magnus Hagander wrote: > After you've run pg_upgrade, you have to loop through all your databases > and do an "ALTER EXTENSION abc UPDATE" once for each extension. > > Is there a reason we shouldn't have pg_upgrade emit a script that does > this, similar to how it emits a script

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

On 12/04/17 19:34, Heikki Linnakangas wrote: On 04/11/2017 02:32 PM, Álvaro Hernández Tortosa wrote: So I still see your proposal more awkward and less clear, mixing things that are separate. But again, your choice :) So, here's my more full-fledged proposal. The first patch

Re: [HACKERS] pg_dump emits ALTER TABLE ONLY partitioned_table

On Wed, Apr 12, 2017 at 3:29 PM, Stephen Frost wrote: > I'm not following what you're getting at here. > > There's already a constraint on the table, and ALTER TABLE ONLY doesn't > say anything about what happens later on (certainly it doesn't make new > tables created with

Re: [HACKERS] pg_statistic_ext.staenabled might not be the best column name

On Wed, Apr 12, 2017 at 9:36 AM, David Rowley wrote: > I'd been thinking that staenabled is not the most suitable column name > for storing the types of statistics that are defined for the extended > statistics. +1. -- Robert Haas EnterpriseDB:

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

On Wed, Apr 12, 2017 at 10:12 AM, Robert Haas wrote: >> I may have missed something, but there is no intention to ignore known >> regressions/reviews. Of course, I don't think that every regression will be >> solvable, like if you run a CPU-bound workload, setting it up in

Re: [HACKERS] logical replication and PANIC during shutdown checkpoint in publisher

On 4/12/17 09:55, Fujii Masao wrote: > To fix this issue, we should terminate walsender for logical replication > before shutdown checkpoint starts. Of course walsender for physical > replication still needs to keep running until shutdown checkpoint ends, > though. Can we turn it into a kind of

Re: [HACKERS] pg_dump emits ALTER TABLE ONLY partitioned_table

On Wed, Apr 12, 2017 at 3:29 PM, Stephen Frost wrote: > * Robert Haas (robertmh...@gmail.com) wrote: >> On Wed, Apr 12, 2017 at 6:29 AM, Amit Langote >> wrote: >> > Actually, p1 is a partitioned table, so the error. And I realize that >> >

Re: [pgsql-www] [HACKERS] Small issue in online devel documentation build

On 4/12/17 07:31, Magnus Hagander wrote: > Once difference I notice is that for example the "note boxes" are no > longer centered, but they do now get the new formatting. I have committed something for that. The issue was that the generated HTML contained hard-coded style attributes. -- Peter

Re: [HACKERS] TAP tests take a long time

Andrew, * Andrew Dunstan (andrew.duns...@2ndquadrant.com) wrote: > On 04/12/2017 08:40 AM, Andrew Dunstan wrote: > > On 04/12/2017 01:27 AM, Craig Ringer wrote: > >> BTW, I suggest adding --timer to our default PROVE_FLAGS, so we can > >> collect more data from the buildfarm on what takes a

Re: [HACKERS] Vacuum: allow usage of more than 1GB of work mem

On Tue, Apr 11, 2017 at 4:38 PM, Claudio Freire wrote: > In essence, the patch as it is proposed, doesn't *need* a binary > search, because the segment list can only grow up to 15 segments at > its biggest, and that's a size small enough that linear search will >

Re: [HACKERS] Inadequate parallel-safety check for SubPlans

Robert Haas writes: > On Wed, Apr 12, 2017 at 2:41 PM, Tom Lane wrote: >> This is 100% wrong. It's failing to recurse into the subexpressions of >> the SubPlan, which could very easily include parallel-unsafe function >> calls. > My understanding

Re: [HACKERS] TAP tests take a long time

On 04/12/2017 08:40 AM, Andrew Dunstan wrote: > > On 04/12/2017 01:27 AM, Craig Ringer wrote: >> BTW, I suggest adding --timer to our default PROVE_FLAGS, so we can >> collect more data from the buildfarm on what takes a while. Sample >> output: >> > > I'll add that to the commandline the

Re: [HACKERS] Inadequate parallel-safety check for SubPlans

On Wed, Apr 12, 2017 at 2:41 PM, Tom Lane wrote: > While poking at the question of parallel_safe marking for Plans, > I noticed that max_parallel_hazard_walker() does this: > > /* We can push the subplans only if they are parallel-safe. */ > else if (IsA(node,

Re: [HACKERS] pg_dump emits ALTER TABLE ONLY partitioned_table

Robert, * Robert Haas (robertmh...@gmail.com) wrote: > On Wed, Apr 12, 2017 at 6:29 AM, Amit Langote > wrote: > > Actually, p1 is a partitioned table, so the error. And I realize that > > that's a wrong behavior. Currently the check is performed using only the >

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

On Thu, Apr 6, 2017 at 7:30 AM, Rahila Syed wrote: > Thanks a lot for testing and reporting this. Please find attached an updated > patch with the fix. The patch also contains a fix > regarding operator used at the time of creating expression as default > partition

Re: [HACKERS] Cutting initdb's runtime (Perl question embedded)

On 04/12/2017 05:00 PM, Andreas Karlsson wrote: Looked at this an option 1 seems simple enough if I am not missing something. I might hack something up later tonight. Either way I think this improvement can be done separately from the proposed replacement of the catalog header files. Trying to

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

On 2017-04-11 17:42:42 -0400, Tom Lane wrote: > Now, that old behavior matches what you got in the RangeFunction case: > > regression96=# select * from int4_tbl, cast(case when f1>0 then > generate_series(1,2) else null end as int); > f1 | int4 > -+-- >0 |

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

On Thu, Apr 6, 2017 at 1:17 AM, Rushabh Lathia wrote: > I like the idea about having DEFAULT partition for the range partition. With > the > way partition is designed it can have holes into range partition. I think > DEFAULT > for the range partition is a good idea,

[HACKERS] Inadequate parallel-safety check for SubPlans

While poking at the question of parallel_safe marking for Plans, I noticed that max_parallel_hazard_walker() does this: /* We can push the subplans only if they are parallel-safe. */ else if (IsA(node, SubPlan)) return !((SubPlan *) node)->parallel_safe; This is 100% wrong. It's

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

On Tue, Apr 11, 2017 at 9:41 AM, Jeevan Ladhe wrote: > I have checked for NULLs too, and the default partition can be created even > when there are partitions for each TRUE, FALSE and NULL. > > Consider the example below: > > postgres=# CREATE TABLE list_partitioned

Re: [HACKERS] Undefined psql variables

2017-04-12 17:05 GMT+02:00 Robert Haas : > On Sun, Apr 2, 2017 at 3:56 PM, Tom Lane wrote: > > So my view of this is that "send the expression to the server" ought > > to be just one option for \if, not the only way to do it. > > I heartily agree.

Re: [HACKERS] Some thoughts about SCRAM implementation

On Wed, Apr 12, 2017 at 2:09 PM, Heikki Linnakangas wrote: > That is very much appreciated! You writing a second implementation of the > client-side support (libpq being the first) is very, very helpful, to > validate that the protocol is sane, unambiguous, and adequately

Re: [HACKERS] pg_dump emits ALTER TABLE ONLY partitioned_table

On Wed, Apr 12, 2017 at 6:29 AM, Amit Langote wrote: > Actually, p1 is a partitioned table, so the error. And I realize that > that's a wrong behavior. Currently the check is performed using only the > relkind, which is bogus. Specifying ONLY should cause an

Re: [HACKERS] Some thoughts about SCRAM implementation

On 04/12/2017 08:38 PM, Álvaro Hernández Tortosa wrote: - Even though I don't really care about SCRAM, and without having any prior knowledge about SCRAM, I volunteered some time ago to study SCRAM, give a lightning talk about SCRAM and later write a client implementation for the jdbc driver.

Re: [HACKERS] GSOC'17 project introduction: Parallel COPY execution with errors handling

> On 12 Apr 2017, at 20:23, Robert Haas wrote: > > On Wed, Apr 12, 2017 at 1:18 PM, Nicolas Barbier > wrote: >> 2017-04-11 Robert Haas : >>> If the data quality is poor (say, 50% of lines have errors) it's >>> almost

Re: [HACKERS] Some thoughts about SCRAM implementation

On 12/04/17 18:38, Robert Haas wrote: On Tue, Apr 11, 2017 at 9:20 AM, Álvaro Hernández Tortosa wrote: LOL. Do you really want a half-baked Java programmer writing a patch in C for PostgreSQL? I once tried that and Magnus said my code was Java code that happened to

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

On 04/11/2017 02:32 PM, Álvaro Hernández Tortosa wrote: So I still see your proposal more awkward and less clear, mixing things that are separate. But again, your choice :) So, here's my more full-fledged proposal. The first patch refactors libpq code, by moving the responsibility of

Re: [HACKERS] Cutting initdb's runtime (Perl question embedded)

On 2017-04-12 10:12:47 -0400, Tom Lane wrote: > Andres mentioned, and I've confirmed locally, that a large chunk of > initdb's runtime goes into regprocin's brute-force lookups of function > OIDs from function names. The recent discussion about cutting TAP test > time prompted me to look into

Re: [HACKERS] index-only count(*) for indexes supporting bitmap scans

On 12.04.2017 12:29, Alexander Korotkov wrote: That's a cool feature for FTS users! Please, register this patch to the next commitfest. I've added this to the 2017-07 commitfest: https://commitfest.postgresql.org/14/1117/ Also, what is planning overhead of this patch? That's worth

Re: [HACKERS] GSOC'17 project introduction: Parallel COPY execution with errors handling

On Wed, Apr 12, 2017 at 1:18 PM, Nicolas Barbier wrote: > 2017-04-11 Robert Haas : >> There's a nasty trade-off here between XID consumption (and the >> aggressive vacuums it eventually causes) and preserving performance in >> the face of errors -

Re: [HACKERS] snapbuild woes

On 2017-04-12 11:03:57 -0400, Peter Eisentraut wrote: > On 4/12/17 02:31, Noah Misch wrote: > >>> But I hope you mean to commit these snapbuild patches before the postgres > >>> 10 > >>> release? As far as I know, logical replication is still very broken > >>> without > >>> them (or at least

Re: [HACKERS] GSOC'17 project introduction: Parallel COPY execution with errors handling

2017-04-11 Robert Haas : > There's a nasty trade-off here between XID consumption (and the > aggressive vacuums it eventually causes) and preserving performance in > the face of errors - e.g. if you make k = 100,000 you consume 100x > fewer XIDs than if you make k = 1000,

Re: [HACKERS] Some thoughts about SCRAM implementation

On 12/04/17 18:09, Tom Lane wrote: Heikki Linnakangas writes: On 04/12/2017 06:26 PM, Bruce Momjian wrote: How does it do that? Good question, crypto magic? I don't know the details, but the basic idea is that you extract a blob of data that uniquely identifies the TLS

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

On Tue, Apr 11, 2017 at 1:20 PM, Pavan Deolasee wrote: > I don't know why you say that regressions are not addressed. Here are a few > things I did to address the regressions/reviews/concerns, apart from fixing > all the bugs discovered, but please let me know if there

Re: [HACKERS] Some thoughts about SCRAM implementation

Stephen Frost writes: > * Tom Lane (t...@sss.pgh.pa.us) wrote: >> ... which the user can't tell apart from having fat-fingered the password, >> I suppose? Doesn't sound terribly friendly. A report of a certificate >> mismatch is far more likely to lead people to realize

Re: [HACKERS] index-only count(*) for indexes supporting bitmap scans

On 12.04.2017 17:24, Tom Lane wrote: TBH, I'm not sure you need to do any of that work. Have you got evidence that the planner will fail to choose the right plan regardless? I'm particularly unconvinced that choose_bitmap_and is a critical problem, because once you're into having to AND

Re: [HACKERS] [sqlsmith] ERROR: badly formatted node string "RESTRICTINFO...

Amit Kapila writes: > On Wed, Apr 12, 2017 at 12:40 AM, Tom Lane wrote: >> Anyone want to draft a patch for this? > Please find patch attached based on above discussion. This patch seems fairly incomplete: you can't just whack around major data

Re: [HACKERS] the need to finish

On Wed, Apr 12, 2017 at 11:41 AM, Simon Riggs wrote: > On 12 April 2017 at 16:26, Tom Lane wrote: >> Erik Rijkers writes: >>> Logical replication emits logmessages like these: >>> DETAIL: 90 transactions need to finish. >>> I would

Re: [HACKERS] Some thoughts about SCRAM implementation

Tom, all, * Tom Lane (t...@sss.pgh.pa.us) wrote: > ... which the user can't tell apart from having fat-fingered the password, > I suppose? Doesn't sound terribly friendly. A report of a certificate > mismatch is far more likely to lead people to realize there's a MITM. We might be able to

Re: [HACKERS] Possible problem in Custom Scan API

Tom Lane wrote: I'm coming around to the idea that it'd be better to disable physical tlists for custom scans. I've been thinking about this all along, and it seems that this is a decent decision. However, I've made a tiny bugfix patch which allows CustomScans to notify the core code that

Re: [HACKERS] Some thoughts about SCRAM implementation

On Tue, Apr 11, 2017 at 9:20 AM, Álvaro Hernández Tortosa wrote: > LOL. Do you really want a half-baked Java programmer writing a patch in > C for PostgreSQL? I once tried that and Magnus said my code was Java code > that happened to compile with a C compiler ^_^ > >

Re: [HACKERS] Add pgstathashindex() to get hash index table statistics.

On Wed, Apr 12, 2017 at 2:28 AM, Noah Misch wrote: > [Action required within three days. This is a generic notification.] > > The above-described topic is currently a PostgreSQL 10 open item. Robert, > since you committed the patch believed to have created it, you own this

Re: [HACKERS] Some thoughts about SCRAM implementation

Heikki Linnakangas writes: > On 04/12/2017 06:26 PM, Bruce Momjian wrote: >> How does it do that? > Good question, crypto magic? I don't know the details, but the basic > idea is that you extract a blob of data that uniquely identifies the TLS > connection. Using some OpenSSL

Re: [HACKERS] Possible problem in Custom Scan API

Dmitry Ivanov writes: >> Uh, no, construction of a custom plan node is entirely driven by the >> PlanCustomPath method as far as I can see. You're free to ignore what >> create_scan_plan did and insert your own tlist. > Are you sure? Even if it's true, this targetlist

Re: [HACKERS] Some thoughts about SCRAM implementation

On 04/12/2017 06:26 PM, Bruce Momjian wrote: On Wed, Apr 12, 2017 at 12:13:03PM +0300, Heikki Linnakangas wrote: That said, I stand by my comment that I don't think it's the enterprises that need or want the channel binding. If they care about it, they have already put certificate validation in

Re: [HACKERS] error handling in RegisterBackgroundWorker

On Tue, Apr 11, 2017 at 10:13 PM, Noah Misch wrote: > On Tue, Apr 11, 2017 at 11:33:34AM -0400, Tom Lane wrote: >> Peter Eisentraut writes: >> > I think there is no clear agreement here, and no historically consistent >> > behavior. I'm

Re: [HACKERS] the need to finish

On 12 April 2017 at 16:26, Tom Lane wrote: > Erik Rijkers writes: >> Logical replication emits logmessages like these: >> DETAIL: 90 transactions need to finish. >> DETAIL: 87 transactions need to finish. >> DETAIL: 70 transactions need to finish. > >>

Re: [HACKERS] Partitioned tables and relfilenode

On Tue, Apr 11, 2017 at 10:15 PM, Amit Langote wrote: > Alright. So I made it into two patches instead: 0001 fixes the bug that > validateCheckConstraint() tries to scan partitioned tables and 0002 makes > trying to convert a partitioned table to a view a user

Re: [HACKERS] snapbuild woes

On 3 March 2017 at 00:30, Petr Jelinek wrote: >> 0004 - Changes handling of the xl_running_xacts in initial snapshot >> build to what I wrote above and removes the extra locking from >> LogStandbySnapshot introduced by logical decoding. This seems OK and unlikely

Re: [HACKERS] GCC 7 warnings

Peter Eisentraut writes: > On 4/12/17 00:12, Tom Lane wrote: >> Now a human can see that saved_timeval.tv_usec must be 0..99, so >> that the %d format item must always emit exactly 3 characters, which >> means that really 5 bytes would be enough. I wouldn't

Re: [HACKERS] the need to finish

Erik Rijkers writes: > Logical replication emits logmessages like these: > DETAIL: 90 transactions need to finish. > DETAIL: 87 transactions need to finish. > DETAIL: 70 transactions need to finish. > Could we get rid of that 'need'? It strikes me as a bit off; something >

Re: [HACKERS] Some thoughts about SCRAM implementation

On Wed, Apr 12, 2017 at 12:13:03PM +0300, Heikki Linnakangas wrote: > >That said, I stand by my comment that I don't think it's the enterprises > >that need or want the channel binding. If they care about it, they have > >already put certificate validation in place, and it won't buy them anything.

Re: [HACKERS] TAP tests take a long time

Mithun Cy writes: > I have tried to optimize the tests maintaining the same coverage we were > able to get with it. This patch looks good to me: on my workstation, it reduces the total runtime of the parallel regression tests from ~20.5 to ~16.5 seconds. I concur that

Re: [HACKERS] GCC 7 warnings

On 4/12/17 00:12, Tom Lane wrote: > The change in setup_formatted_log_time seems a bit weird: > > - charmsbuf[8]; > + charmsbuf[10]; > > The associated call is > > sprintf(msbuf, ".%03d", (int) (saved_timeval.tv_usec / 1000)); > > Now a human can see that

Re: [HACKERS] Logical replication and inheritance

On Wed, Apr 5, 2017 at 8:25 AM, Peter Eisentraut wrote: > After thinking about it some more, I think the behavior we want would be > that changes to inheritance would reflect in the publication membership. > So if you have a partitioned table, adding more

[HACKERS] the need to finish

Logical replication emits logmessages like these: DETAIL: 90 transactions need to finish. DETAIL: 87 transactions need to finish. DETAIL: 70 transactions need to finish. Could we get rid of that 'need'? It strikes me as a bit off; something that people would say but not a mechanical

Re: [HACKERS] Undefined psql variables

On Sun, Apr 2, 2017 at 3:56 PM, Tom Lane wrote: > So my view of this is that "send the expression to the server" ought > to be just one option for \if, not the only way to do it. I heartily agree. There should be some kind of client-side expression language, and one thing it

Re: [HACKERS] snapbuild woes

On 4/12/17 02:31, Noah Misch wrote: >>> But I hope you mean to commit these snapbuild patches before the postgres 10 >>> release? As far as I know, logical replication is still very broken without >>> them (or at least some of that set of 5 patches - I don't know which ones >>> are essential and

Re: [HACKERS] Logical replication and inheritance

On 4/9/17 22:16, Noah Misch wrote: > On Wed, Apr 05, 2017 at 08:25:56AM -0400, Peter Eisentraut wrote: >> After thinking about it some more, I think the behavior we want would be >> that changes to inheritance would reflect in the publication membership. >> So if you have a partitioned table,

Re: [HACKERS] Cutting initdb's runtime (Perl question embedded)

On 04/12/2017 04:12 PM, Tom Lane wrote: 1. The best thing would still be to make genbki.pl do the conversion, and write numeric OIDs into postgres.bki. The core stumbling block here seems to be that for most catalogs, Catalog.pm and genbki.pl never really break down a DATA line into fields ---

  1   2   >