Re: [HACKERS] pg_basebackup: Allow use of arbitrary compression program

Hi, Thanks for the feedback! >> 2) The current logic either uses zlib if compiled in, or offers no >> compression at all, controlled by a series of #ifdef/#endif. I would >> prefer that the user can either use zlib or an external program >> without having to recompile, so I would remove the

Re: [HACKERS] Possible problem in Custom Scan API

On Wed, Apr 12, 2017 at 12:59 AM, Dmitry Ivanov wrote: > Tom Lane wrote: > >> 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.

Re: [HACKERS] Why does logical replication launcher set application_name?

On Wed, Apr 12, 2017 at 6:02 AM, Robert Haas wrote: > On Tue, Apr 11, 2017 at 8:11 PM, Michael Paquier > wrote: >> On Wed, Apr 12, 2017 at 3:40 AM, Tom Lane wrote: >>> I notice looking at pg_stat_activity that the logical

Re: [HACKERS] TAP tests take a long time

On 12 April 2017 at 08:22, Michael Paquier wrote: > On Wed, Apr 12, 2017 at 9:12 AM, Craig Ringer > wrote: >> Well, you can get a lot of information on timings in crake's latest >> builds for example, or nightjar's. >> >> Here's an

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

On Wed, Apr 12, 2017 at 1:28 PM, Peter Eisentraut wrote: > On 4/10/17 08:10, Petr Jelinek wrote: >> I don't think solution is quite this simple. This will cause all table >> sync workers to be delayed which means concurrency will suffer and the >> initial sync of

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

On 4/10/17 08:10, Petr Jelinek wrote: > I don't think solution is quite this simple. This will cause all table > sync workers to be delayed which means concurrency will suffer and the > initial sync of all tables will take much longer especially if there is > little data. We need a way to either

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

On Wed, Apr 12, 2017 at 9:23 AM, Amit Kapila wrote: > On Tue, Apr 11, 2017 at 10:50 PM, Pavan Deolasee > > > > > And I fixed them as quickly as humanly possible. > > > > Yes, you have responded to them quickly, but I didn't get a chance to > re-verify all of those.

Re: [HACKERS] GCC 7 warnings

Peter Eisentraut writes: > Attached is a more refined patch that I propose for PG10 now. Compared > to the previous rushed version, this one uses some more precise > arithmetic to size some of the buffers. Generally +1 for switching the snprintf calls to use

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

On 3/24/17 10:49, Petr Jelinek wrote: > Rebase after table copy patch got committed. You could please sent another rebase of this, perhaps with some more documentation, as discussed downthread. Also, I wonder why we don't offer the other values of synchronous_commit. In any case, we should keep

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

On Tue, Apr 11, 2017 at 10:50 PM, Pavan Deolasee wrote: > > > On Tue, Apr 11, 2017 at 7:10 PM, Robert Haas wrote: >> >> >> >> Yes, and as Andres says, you don't help with those, and then you're >> upset when your own patch doesn't get attention. >

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

On Tue, Apr 11, 2017 at 10:02 PM, Tom Lane wrote: > Ashutosh Bapat writes: >> On Tue, Apr 11, 2017 at 8:11 PM, Tom Lane wrote: >>> OK. I was trying to be noninvasive, but this does look more sensible. >>> I think this

Re: [HACKERS] GCC 7 warnings

On 4/11/17 13:57, Alvaro Herrera wrote: > Tom Lane wrote: >> Peter Eisentraut writes: > >>> d) Replace most of the problematic code with psprintf() and dynamically >>> sized buffers. >> >> +1 for (c) as you have it. Later we might think about selectively >>

Re: [HACKERS] logical replication worker and statistics

On 4/10/17 13:06, Stas Kelvich wrote: > >> On 10 Apr 2017, at 19:50, Peter Eisentraut >> wrote: >> >> On 4/10/17 05:49, Stas Kelvich wrote: >>> Here is small patch to call statistics in logical worker. Originally i >>> thought that stat >>> collection during

Re: [HACKERS] SUBSCRIPTIONS and pg_upgrade

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 day should the community look for your next

Re: [HACKERS] error handling in RegisterBackgroundWorker

"David G. Johnston" writes: > On Tue, Apr 11, 2017 at 11:10 AM, Peter Eisentraut < > peter.eisentr...@2ndquadrant.com> wrote: >> On 4/11/17 11:47, David G. Johnston wrote: >>> ​A potential middle-ground is to start, but then only allow superuser >>> connections. >>

Re: [HACKERS] SUBSCRIPTIONS and pg_upgrade

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. -- Peter Eisentraut http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training &

Re: [HACKERS] SUBSCRIPTIONS and pg_upgrade

On 4/10/17 20:55, Stephen Frost wrote: >> Proposal: Dump all subscriptions in DISABLED state. Remove current >> pg_dump --no-subscription-connect option. > I like this idea in general, I'm just not sure if it's the right answer > when we're talking about pg_upgrade. At a minimum, if we go with

Re: [HACKERS] TAP tests take a long time

Andres Freund writes: > The time in initdb is largely spent in regprocin and server start/stop, > so that doesn't surprise me. Yeah. We had a plan for removing the regprocin overhead via preprocessing of the .bki file, but I've not heard anything about that project for

Re: [HACKERS] TAP tests take a long time

On 2017-04-12 10:39:22 +0800, Craig Ringer wrote: > On 12 April 2017 at 08:22, Michael Paquier wrote: > > On Wed, Apr 12, 2017 at 9:12 AM, Craig Ringer > > wrote: > >> > >> We should also have a debug --no-fsync option for initdb, or maybe

Re: [HACKERS] TAP tests take a long time

On 04/11/2017 08:12 PM, Craig Ringer wrote: > > > On 12 Apr. 2017 03:14, "Andrew Dunstan" > > wrote: > > > > On 04/11/2017 12:08 PM, Tom Lane wrote: > > Robert Haas

Re: [HACKERS] TAP tests take a long time

On 12 April 2017 at 08:22, Michael Paquier wrote: > On Wed, Apr 12, 2017 at 9:12 AM, Craig Ringer > wrote: >> >> We should also have a debug --no-fsync option for initdb, or maybe allow it >> to take -o options to pass to child postgres so

Re: [HACKERS] error handling in RegisterBackgroundWorker

On Mon, Apr 10, 2017 at 11:22:38PM -0400, Tom Lane wrote: > Noah Misch writes: > > On Mon, Apr 10, 2017 at 09:36:59PM -0400, Peter Eisentraut wrote: > >> If history had been different, we could have implemented, say, > >> autovacuum or walreceiver on the background worker

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

On Wed, Apr 12, 2017 at 12:40 AM, Tom Lane wrote: > Amit Kapila writes: > >> I think there is a possibility of doing ExecInitNode in a parallel >> worker for a parallel-unsafe subplan, because we pass a list of all >> the sublans stored in planned

Re: [HACKERS] SUBSCRIPTIONS and pg_upgrade

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. -- Peter Eisentraut

Re: [HACKERS] Partitioned tables and relfilenode

On 2017/04/12 2:41, Robert Haas wrote: > On Tue, Apr 11, 2017 at 9:45 AM, Tom Lane wrote: >> Amit Langote writes: >>> 2. DefineQueryRewrite() may try to scan a partitioned table in the case of >>> converting a table to view, where we must make

Re: [HACKERS] error handling in RegisterBackgroundWorker

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 prepared to let it go and cross it off the list of open > > items. I believe we

Re: [HACKERS] Remove pg_stat_progress_vacuum from Table 28.2

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, Amit Langote >>> wrote: It seems

Re: [HACKERS] Some thoughts about SCRAM implementation

On Tue, Apr 11, 2017 at 08:58:30PM -0400, Stephen Frost wrote: > > > But just a bit more is needed to make it really a big announcement and > > > provide real value to (I guess, mostly but very interesting) enterprise > > > customers, for which MITM and impersonating are big things. The good

Re: [HACKERS] RENAME RULE doesn't work with partitioned tables

On 2017/04/12 2:20, Robert Haas wrote: > On Tue, Apr 11, 2017 at 5:54 AM, Amit Langote > wrote: >> Just noticed that RangeVarCallbackForRenameRule() was not updated to >> handle partitioned tables, causing the following bug: >> >> create table parted_table (a int)

Re: [HACKERS] dropping a partition may cause deadlock

On 2017/04/11 22:18, Robert Haas wrote: > On Sun, Apr 9, 2017 at 7:57 PM, Noah Misch wrote: >> 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 open >> item. If some other

Re: [HACKERS] Some thoughts about SCRAM implementation

Bruce, * Bruce Momjian (br...@momjian.us) wrote: > On Tue, Apr 11, 2017 at 02:53:24PM +0200, Álvaro Hernández Tortosa wrote: > > Let's put ourselves on the foot of potential users. Why would anyone > > want to use SCRAM? What for? The hashing mechanism is better, no question. > > And bring

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

On Tue, Apr 11, 2017 at 04:51:03PM -0400, Tom Lane wrote: > Bruce Momjian writes: > Yeah, very long ago. A quick search of our archives shows that the number > of mentions of Borland pretty much fell off a cliff after 2009 (excluding > the repeated conversations about dropping

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

On Mon, Apr 10, 2017 at 04:34:50PM -0700, Andres Freund wrote: > Hi, > > > On 2017-04-08 23:36:13 +0530, Pavan Deolasee wrote: > > On Wed, Apr 5, 2017 at 11:57 PM, Andres Freund wrote: > > > > > On 2017-04-05 09:36:47 -0400, Robert Haas wrote: > > > > By the way, the

Re: [HACKERS] Some thoughts about SCRAM implementation

On Tue, Apr 11, 2017 at 02:53:24PM +0200, Álvaro Hernández Tortosa wrote: > Let's put ourselves on the foot of potential users. Why would anyone > want to use SCRAM? What for? The hashing mechanism is better, no question. > And bring some added benefits, true. So its "better". But the real

Re: [HACKERS] Why does logical replication launcher set application_name?

On Tue, Apr 11, 2017 at 8:11 PM, Michael Paquier wrote: > On Wed, Apr 12, 2017 at 3:40 AM, Tom Lane wrote: >> I notice looking at pg_stat_activity that the logical replication launcher >> sets its application_name to "logical replication launcher".

Re: [HACKERS] TAP tests take a long time

On Wed, Apr 12, 2017 at 9:12 AM, Craig Ringer wrote: > Well, you can get a lot of information on timings in crake's latest > builds for example, or nightjar's. > > Here's an interesting fact: almost all the time taken up in the scripts > test set seems to be consumed

Re: [HACKERS] TAP tests take a long time

On 12 Apr. 2017 03:14, "Andrew Dunstan" wrote: On 04/11/2017 12:08 PM, Tom Lane wrote: > Robert Haas writes: >> On Tue, Apr 11, 2017 at 11:32 AM, Andrew Dunstan >> wrote: >>> This buildfarm run as you can

Re: [HACKERS] Why does logical replication launcher set application_name?

On Wed, Apr 12, 2017 at 3:40 AM, Tom Lane wrote: > I notice looking at pg_stat_activity that the logical replication launcher > sets its application_name to "logical replication launcher". This seems > inconsistent (no other standard background process sets application_name),

Re: [HACKERS] error handling in RegisterBackgroundWorker

On Tue, Apr 11, 2017 at 11:10 AM, Peter Eisentraut < peter.eisentr...@2ndquadrant.com> wrote: > On 4/11/17 11:47, David G. Johnston wrote: > > ​A potential middle-ground is to start, but then only allow superuser > > connections. > > Then you might as well start and allow all connections. I

Re: [HACKERS] Variable substitution in psql backtick expansion

Hmmm. Although I do not buy this, it could work as a replacement for \set which it seems cannot be upgraded because some people may rely on it to just store whatever comes after it in a variable. I have no strong opinion on how expressive expressions should be, but having a separate \expr (or

Re: [HACKERS] Possible problem in Custom Scan API

Tom Lane wrote: 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 should still contain each and every Var

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

Andres Freund writes: > On 2017-04-11 17:25:52 -0400, Tom Lane wrote: >> What was the previous behavior for such cases? If it was reasonably >> sane, we probably have to preserve it. If it was unpredictable or >> completely wacko, maybe we don't. > Previously we'd stash the

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

On Tue, Apr 11, 2017 at 8:24 PM, Alexander Kuzmenkov < a.kuzmen...@postgrespro.ru> wrote: > I would like to propose a patch that speeds up the queries of the form > 'select > count(*) ... where ...', where the restriction clauses can be satisfied > by some > indexes. At the moment, such queries

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

On 2017-04-11 17:25:52 -0400, Tom Lane wrote: > Andres Freund writes: > > Tom, do you have any opinion on the volatility stuff? > > What was the previous behavior for such cases? If it was reasonably > sane, we probably have to preserve it. If it was unpredictable or >

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

Andres Freund writes: > Tom, do you have any opinion on the volatility stuff? What was the previous behavior for such cases? If it was reasonably sane, we probably have to preserve it. If it was unpredictable or completely wacko, maybe we don't.

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

On 2017-01-30 18:54:50 -0500, 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 of injecting a > > ProjectSet node we'd add a FunctionScan node below a Result

Re: [HACKERS] TAP tests take a long time

On 04/11/2017 03:58 PM, Andres Freund wrote: > On 2017-04-11 15:52:34 -0400, Tom Lane wrote: >> Andrew Dunstan writes: The other thing that might be useful here is to push on parallelizing buildfarm runs. >>> One reason I haven't supported "make -j nn"

Re: [HACKERS] Possible problem in Custom Scan API

Dmitry Ivanov writes: >> Reading between the lines, I think the problem may be that you're not >> being careful about how you set up custom_scan_tlist. But since the >> core code has zero involvement in that decision, it's hard to see why >> it would be a core code bug.

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

Bruce Momjian writes: > I am fine with removing things, but I do remember one reason the Borland > part was kept is that some tool would only work with the > Borland-compiled library, not gcc or MSVC, but that was long ago. Yeah, very long ago. A quick search of our archives

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

On Tue, Apr 11, 2017 at 4:17 PM, Robert Haas wrote: > On Tue, Apr 11, 2017 at 2:59 PM, Claudio Freire > wrote: >> On Tue, Apr 11, 2017 at 3:53 PM, Robert Haas wrote: >>> 1TB / 8kB per page * 60 tuples/page * 20% * 6

Re: [HACKERS] Replication status in logical replication

On 22 March 2017 at 02:50, Masahiko Sawada wrote: > When using logical replication, I ran into a situation where the > pg_stat_replication.state is not updated until any wal record is sent > after started up. For example, I set up logical replication with 2 > subscriber

Re: [HACKERS] Possible problem in Custom Scan API

Tom Lane wrote: Reading between the lines, I think the problem may be that you're not being careful about how you set up custom_scan_tlist. But since the core code has zero involvement in that decision, it's hard to see why it would be a core code bug. I'm sorry, but you didn't understand.

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

On Tue, Apr 11, 2017 at 03:14:23PM +0200, Magnus Hagander wrote: > On Tue, Apr 11, 2017 at 4:18 AM, Michael Paquier > wrote: > > On Tue, Apr 11, 2017 at 1:45 AM, Tom Lane wrote: > > Magnus Hagander writes: > >

Re: [HACKERS] TAP tests take a long time

Andres Freund writes: > On 2017-04-11 15:52:34 -0400, Tom Lane wrote: >> Agreed, that would be a mess. > Doesn't make's -Otarget largely solve this? Given a sufficiently new make (which would include exactly zero of my own buildfarm critters), that would help. I think it

Re: [HACKERS] TAP tests take a long time

On 2017-04-11 15:52:34 -0400, Tom Lane wrote: > Andrew Dunstan writes: > >> The other thing that might be useful here is to push on parallelizing > >> buildfarm runs. > > > One reason I haven't supported "make -j nn" everywhere (it is supported > > for making

Re: [HACKERS] SCRAM authentication, take three

On Tue, Apr 11, 2017 at 08:10:23AM +0300, Heikki Linnakangas wrote: > On 04/11/2017 04:52 AM, Peter Eisentraut wrote: > Good question. We would need to decide the order of preference for those. > > That question won't arise in practice. Firstly, if the server can do > scram-sha-256-plus, it

Re: [HACKERS] TAP tests take a long time

Andrew Dunstan writes: >> The other thing that might be useful here is to push on parallelizing >> buildfarm runs. > One reason I haven't supported "make -j nn" everywhere (it is supported > for making core, contrib and test_modules) is that the output tends to >

Re: [HACKERS] Possible problem in Custom Scan API

Dmitry Ivanov writes: > Tom Lane wrote: >> Uh, why would you see that? The planner would never generate an >> IndexOnlyScan in the first place if the query required any columns >> not available from the index. > True, but as you can see, create_append_plan() produces

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

On Tue, Apr 11, 2017 at 2:59 PM, Claudio Freire wrote: > On Tue, Apr 11, 2017 at 3:53 PM, Robert Haas wrote: >> 1TB / 8kB per page * 60 tuples/page * 20% * 6 bytes/tuple = 9216MB of >> maintenance_work_mem >> >> So we'll allocate

Re: [HACKERS] TAP tests take a long time

On 04/11/2017 12:08 PM, Tom Lane wrote: > Robert Haas writes: >> On Tue, Apr 11, 2017 at 11:32 AM, Andrew Dunstan >> wrote: >>> This buildfarm run as you can see takes 33m32s, and the Tap tests take a >>> combined 19m52s of that time. >> I

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

Amit Kapila writes: > On Tue, Apr 11, 2017 at 5:29 AM, Tom Lane wrote: >> I think the fact that we see this problem at all may indicate an >> oversight in commit 5e6d8d2bbbcace304450b309e79366c0da4063e4 ("Allow >> parallel workers to execute

Re: [HACKERS] scram and \password

On 04/10/2017 08:42 AM, Michael Paquier wrote: As there have been some conflicts because of the commit of SASLprep, here is a rebased set of patches. A couple of things worth noting: - SASLprep does an allocation of the prepared password string. It is definitely better to do all the ground work

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

On Tue, Apr 11, 2017 at 3:59 PM, Claudio Freire wrote: > On Tue, Apr 11, 2017 at 3:53 PM, Robert Haas wrote: >> 1TB / 8kB per page * 60 tuples/page * 20% * 6 bytes/tuple = 9216MB of >> maintenance_work_mem >> >> So we'll allocate

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

On Tue, Apr 11, 2017 at 3:53 PM, Robert Haas wrote: > 1TB / 8kB per page * 60 tuples/page * 20% * 6 bytes/tuple = 9216MB of > maintenance_work_mem > > So we'll allocate 128MB+256MB+512MB+1GB+2GB+4GB which won't be quite > enough so we'll allocate another 8GB, for a total of

Re: [HACKERS] bumping HASH_VERSION to 3

On Tue, Apr 11, 2017 at 2:23 PM, Bruce Momjian wrote: > On Fri, Mar 31, 2017 at 02:48:05PM -0400, Tom Lane wrote: >> +1, as long as we're clear on what will happen when pg_upgrade'ing >> an installation containing hash indexes. I think a minimum requirement is >> that it

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

On Fri, Apr 7, 2017 at 9:12 PM, Andres Freund wrote: >> Why do you say exponential growth fragments memory? AFAIK, all those >> allocations are well beyond the point where malloc starts mmaping >> memory, so each of those segments should be a mmap segment, >> independently

[HACKERS] Why does logical replication launcher set application_name?

I notice looking at pg_stat_activity that the logical replication launcher sets its application_name to "logical replication launcher". This seems inconsistent (no other standard background process sets application_name), redundant with other columns that already tell you what it is, and an

Re: [HACKERS] Possible problem in Custom Scan API

Tom Lane wrote: Uh, why would you see that? The planner would never generate an IndexOnlyScan in the first place if the query required any columns not available from the index. True, but as you can see, create_append_plan() produces its own targetlist: static Plan *

Re: [HACKERS] bumping HASH_VERSION to 3

On Fri, Mar 31, 2017 at 02:48:05PM -0400, Tom Lane wrote: > +1, as long as we're clear on what will happen when pg_upgrade'ing > an installation containing hash indexes. I think a minimum requirement is > that it succeed and be able to start up, and allow the user to manually > REINDEX such

Re: [HACKERS] error handling in RegisterBackgroundWorker

On 4/11/17 11:47, David G. Johnston wrote: > ​A potential middle-ground is to start, but then only allow superuser > connections. Then you might as well start and allow all connections. I don't see what this buys. -- Peter Eisentraut http://www.2ndQuadrant.com/ PostgreSQL

Re: [HACKERS] TAP tests take a long time

On 4/11/17 12:08, Tom Lane wrote: > The other thing that might be useful here is to push on parallelizing > buildfarm runs. Admittedly that will do nothing for the oldest and > slowest buildfarm critters, but for reasonably modern hardware the > serialization of the tests really handicaps you.

Re: [HACKERS] Possible problem in Custom Scan API

Dmitry Ivanov writes: > In theory, CustomScans should be able to use any Plan nodes (i.e. > 'custom_plans' list), but as far as I can understand, there's no way to > override behavior of use_physical_tlist(), which means that we might see > something like this: >

Re: [HACKERS] GCC 7 warnings

Tom Lane wrote: > Peter Eisentraut writes: > > d) Replace most of the problematic code with psprintf() and dynamically > > sized buffers. > > +1 for (c) as you have it. Later we might think about selectively > doing (d), but it seems like more work for

Re: [HACKERS] Merge join for GiST

2017-04-11 14:17 GMT+05:00 Alexander Korotkov : > FYI, I've implemented this algorithm for pgsphere. See following branch. > https://github.com/akorotkov/pgsphere/tree/experimental > It's implemented as crossmatch() function which takes as arguments names of > two

Re: [HACKERS] Partitioned tables and relfilenode

On Tue, Apr 11, 2017 at 9:45 AM, Tom Lane wrote: > Amit Langote writes: >> 2. DefineQueryRewrite() may try to scan a partitioned table in the case of >> converting a table to view, where we must make sure that the table being >> converted is

Re: [HACKERS] logical rep worker for table sync can start and stop very frequently unexpectedly

On Wed, Apr 12, 2017 at 2:05 AM, Fujii Masao wrote: > Hi, > > I observed $subject when I ran the following steps. > > 1. start the publisher server > 2. start the subscriber server > 3. create table with primary key and publication for it > 4. insert several records into

Re: [HACKERS] Quorum commit for multiple synchronous replication.

On Thu, Apr 6, 2017 at 4:17 PM, Masahiko Sawada wrote: > On Thu, Apr 6, 2017 at 10:51 AM, Noah Misch wrote: >> On Thu, Apr 06, 2017 at 12:48:56AM +0900, Fujii Masao wrote: >>> On Wed, Apr 5, 2017 at 3:45 PM, Noah Misch wrote: >>> > On

[HACKERS] my open items vs. my vacation

I've managed to clean up all but one of the open items[1] attributable to my v10 commits; the exception is the issue with pg_dump and partitioned tables, which I still hope to get resolved this week. On Friday, I'm leaving on vacation; my first day back in the office will be April 24th. While I

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

Hi, I would like to propose a patch that speeds up the queries of the form 'select count(*) ... where ...', where the restriction clauses can be satisfied by some indexes. At the moment, such queries use index-only scans followed by aggregation. Index-only scans are only possible for indexes

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

On Tue, Apr 11, 2017 at 7:10 PM, Robert Haas wrote: > > > Yes, and as Andres says, you don't help with those, and then you're > upset when your own patch doesn't get attention. I am not upset, I was obviously a bit disappointed which I think is a very natural emotion

Re: [HACKERS] FDW and parallel execution

hello ... did you check out antonin houska's patches? we basically got code, which can do that. many thanks, hans On 04/02/2017 03:30 PM, Konstantin Knizhnik wrote: > Hi hackers and personally Robet (you are the best expert in both areas). > I want to ask one more question

Re: [HACKERS] RENAME RULE doesn't work with partitioned tables

On Tue, Apr 11, 2017 at 5:54 AM, Amit Langote wrote: > Just noticed that RangeVarCallbackForRenameRule() was not updated to > handle partitioned tables, causing the following bug: > > create table parted_table (a int) partition by list (a); > create table part

Re: [HACKERS] FDW and parallel execution

On 04.04.2017 13:29, Kyotaro HORIGUCHI wrote: Hi, At Sun, 02 Apr 2017 16:30:24 +0300, Konstantin Knizhnik wrote in <58e0fcf0.2070...@postgrespro.ru> Hi hackers and personally Robet (you are the best expert in both areas). I want to ask one more question

Re: [HACKERS] strange parallel query behavior after OOM crashes

On Tue, Apr 11, 2017 at 12:15 PM, Robert Haas wrote: > On Mon, Apr 10, 2017 at 7:17 PM, Tomas Vondra > wrote: >> At first I was like 'WTF? Why do we need a new GUC just becase of an >> assert?' but you're actually not adding a new GUC

[HACKERS] logical rep worker for table sync can start and stop very frequently unexpectedly

Hi, I observed $subject when I ran the following steps. 1. start the publisher server 2. start the subscriber server 3. create table with primary key and publication for it 4. insert several records into the table 5. create table with primary key and subscription 6. wait for table sync to finish

Re: [HACKERS] Reversed sync check in pg_receivewal

Magnus Hagander writes: > Something like the attached? Not sure about + * All methods that have a failure path will set errno on failure. Given that you've got a getlasterror method, I don't think that's really the API invariant is it? If it were, you'd just have the

[HACKERS] Possible problem in Custom Scan API

Hi hackers, I'm struggling to understand one particular thing about Custom Scan API. As you may know, there's a function called use_physical_tlist(), which aims to eliminate meaningless projections during query execution. Any scan node (e.g. CustomScan) aims to take advantage of physical

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

Ashutosh Bapat writes: > On Tue, Apr 11, 2017 at 8:11 PM, Tom Lane wrote: >> OK. I was trying to be noninvasive, but this does look more sensible. >> I think this might read better if we inverted the test (so that >> the

Re: [HACKERS] SUBSCRIPTIONS and pg_upgrade

On Tue, Apr 11, 2017 at 10:13 AM, Stephen Frost wrote: >> I totally agree, which is why I was rather surprised when you >> vigorously objected to my attempts to replace the remainder of the >> main tree's superuser checks that completely block execution of >> certain SQL

Re: [HACKERS] SUBSCRIPTIONS and pg_upgrade

On Tue, Apr 11, 2017 at 9:48 AM, Robert Haas wrote: > On Mon, Apr 10, 2017 at 1:58 PM, Peter Eisentraut > wrote: >> OK, we need to come to a conclusion here. To summarize: >> >> Problem 1: pg_subscription.subconninfo can only be read by

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

On Tue, Apr 11, 2017 at 8:11 PM, Tom Lane wrote: > Ashutosh Bapat writes: >> On Tue, Apr 11, 2017 at 3:53 AM, Tom Lane wrote: >> +* there is no need for EPQ recheck at a join (and Vars or Aggrefs in >> +*

Re: [HACKERS] strange parallel query behavior after OOM crashes

On Mon, Apr 10, 2017 at 7:17 PM, Tomas Vondra wrote: > At first I was like 'WTF? Why do we need a new GUC just becase of an > assert?' but you're actually not adding a new GUC parameter, you're adding a > constant which is then used as a max value for max for the two

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

Andreas Seltenreich writes: > I see the above ERROR logged a lot when testing master at eef8c0069e > with a postgres_fdw around. Below is a recipe to reproduce it on top of > the regression DB. I've pushed a fix that should get you past that problem, although I suspect we

Re: [HACKERS] Problem in Parallel Bitmap Heap Scan?

On Sun, Apr 9, 2017 at 11:17 PM, Noah Misch wrote: > The above-described topic is currently a PostgreSQL 10 open item. I have committed the patch. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing

Re: [HACKERS] TAP tests take a long time

Robert Haas writes: > On Tue, Apr 11, 2017 at 11:32 AM, Andrew Dunstan > wrote: >> This buildfarm run as you can see takes 33m32s, and the Tap tests take a >> combined 19m52s of that time. > I don't think it's quite fair to complain about

Re: [HACKERS] TAP tests take a long time

On Tue, Apr 11, 2017 at 11:32 AM, Andrew Dunstan wrote: > I've complained about this before. Below are some timings from buildfarm > member nightjar as I test out the new client code. > > This buildfarm run as you can see takes 33m32s, and the Tap tests take a >

Re: [HACKERS] error handling in RegisterBackgroundWorker

On Tue, Apr 11, 2017 at 8:33 AM, Tom Lane wrote: > Peter Eisentraut writes: > > On 4/10/17 23:22, Tom Lane wrote: > >> Personally I'd err on the side of "starting up degraded is better than > >> not starting at all". Or maybe we should

Re: [HACKERS] Reversed sync check in pg_receivewal

On Tue, Apr 11, 2017 at 3:53 PM, Tom Lane wrote: > Magnus Hagander writes: > > On Tue, Apr 11, 2017 at 3:19 PM, Tom Lane wrote: > >> I think the patch is correct, but if there's any documentation of the > >> walmethod APIs that would

Re: [HACKERS] Merge join for GiST

On Tue, Apr 11, 2017 at 5:46 PM, Jeff Davis wrote: > On Tue, Apr 11, 2017 at 2:17 AM, Alexander Korotkov > wrote: > > FYI, I've implemented this algorithm for pgsphere. See following branch. > >

Re: [HACKERS] error handling in RegisterBackgroundWorker

Peter Eisentraut writes: > On 4/10/17 23:22, Tom Lane wrote: >> Personally I'd err on the side of "starting up degraded is better than >> not starting at all". Or maybe we should invent a GUC to let DBAs >> express their preference on that? > If we defaulted

  1   2   >