Re: [HACKERS] AGG_HASHED cost estimate

On Thu, Apr 20, 2017 at 11:35 PM, Jeff Janes wrote: > Regardless, it seems like something is > getting overlooked. I agree with this. > The way final_cost_hashjoin charges for the actual data > comparison is via pg_proc.procost, rather than just assuming 1.0. I don't >

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

At Fri, 21 Apr 2017 13:20:05 +0900, Masahiko Sawada wrote in > On Fri, Apr 21, 2017 at 12:02 PM, Noah Misch wrote: > > On Wed, Apr 19, 2017 at 01:52:53PM +0900, Masahiko Sawada wrote:

Re: [HACKERS] some review comments on logical rep code

At Wed, 19 Apr 2017 10:59:00 +0200, Petr Jelinek wrote in <3ef9c831-0508-51a9-5ded-c2e31e958...@2ndquadrant.com> > On 19/04/17 10:45, Kyotaro HORIGUCHI wrote: > > At Wed, 19 Apr 2017 17:43:17 +0900 (Tokyo Standard Time), Kyotaro HORIGUCHI > >

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

On Fri, Apr 21, 2017 at 12:02 PM, Noah Misch wrote: > On Wed, Apr 19, 2017 at 01:52:53PM +0900, Masahiko Sawada wrote: >> On Wed, Apr 19, 2017 at 12:34 PM, Noah Misch wrote: >> > On Sun, Apr 16, 2017 at 07:25:28PM +0900, Fujii Masao wrote: >> >> On Sun, Apr

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

On Fri, Apr 21, 2017 at 12:29 AM, Peter Eisentraut wrote: > On 4/20/17 07:52, Petr Jelinek wrote: >> On 20/04/17 05:57, Michael Paquier wrote: >>> 2nd thoughts here... Ah now I see your point. True that there is no >>> way to ensure that an unwanted command is

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

On Wed, Apr 19, 2017 at 01:52:53PM +0900, Masahiko Sawada wrote: > On Wed, Apr 19, 2017 at 12:34 PM, Noah Misch wrote: > > On Sun, Apr 16, 2017 at 07:25:28PM +0900, Fujii Masao wrote: > >> On Sun, Apr 16, 2017 at 1:19 PM, Noah Misch wrote: > >> > On Fri, Apr

Re: [HACKERS] Unportable implementation of background worker start

On 2017-04-20 20:10:41 -0400, Tom Lane wrote: > Andres Freund writes: > > On 2017-04-20 20:05:02 -0400, Tom Lane wrote: > >> Also, if it's not there we'd fall back to using plain poll(), which is > >> not so awful that we need to work hard to avoid it. I'd just as soon > >>

Re: [HACKERS] DROP SUBSCRIPTION, query cancellations and slot handling

On Fri, Apr 21, 2017 at 11:34 AM, Petr Jelinek wrote: > On 20/04/17 23:30, Peter Eisentraut wrote: >> On 4/20/17 10:19, Petr Jelinek wrote: >>> Hmm well since this only affects the synchronization of table >>> states/names, I guess we could just simply do that before

Re: [HACKERS] some review comments on logical rep code

On Fri, Apr 21, 2017 at 4:41 AM, Peter Eisentraut wrote: > On 4/20/17 12:30, Fujii Masao wrote: >> I've pushed several patches, and there is now only one remaining patch. >> I posted the review comment on that patch, and I'm expecting that >> Masahiko-san will

Re: [HACKERS] pg_dump emits ALTER TABLE ONLY partitioned_table

Hi Stephen, On 2017/04/21 8:43, Stephen Frost wrote: > * Amit Langote (langote_amit...@lab.ntt.co.jp) wrote: >> On 2017/04/18 1:43, Stephen Frost wrote: >>> Please take a look at the attached and let me know your thoughts on it. >>> I changed the code to complain again regarding TRUNCATE ONLY,

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

On Thu, Apr 20, 2017 at 8:43 PM, Petr Jelinek wrote: > On 20/04/17 06:21, Masahiko Sawada wrote: >> On Thu, Apr 20, 2017 at 12:30 AM, Petr Jelinek >> wrote: >>> On 19/04/17 15:57, Masahiko Sawada wrote: On Wed, Apr 19, 2017 at

Re: [HACKERS] walsender & parallelism

On 21/04/17 04:32, Craig Ringer wrote: > On 21 April 2017 at 10:20, Petr Jelinek wrote: >> On 21/04/17 03:40, Andres Freund wrote: >>> >>> Since [1] walsender (not receiver as commit message says) can execute >>> SQL queries. While doing some testing of [2] I

Re: [HACKERS] DROP SUBSCRIPTION, query cancellations and slot handling

On 20/04/17 23:30, Peter Eisentraut wrote: > On 4/20/17 10:19, Petr Jelinek wrote: >> Hmm well since this only affects the synchronization of table >> states/names, I guess we could just simply do that before we create the >> slot as there is no expectancy of consistency between slot and the table

Re: [HACKERS] walsender & parallelism

On 21 April 2017 at 10:20, Petr Jelinek wrote: > On 21/04/17 03:40, Andres Freund wrote: >> >> Since [1] walsender (not receiver as commit message says) can execute >> SQL queries. While doing some testing of [2] I noticed that SQL queries >> in walsender get stuck

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

On Mon, Apr 17, 2017 at 02:09:54PM -0400, Peter Eisentraut wrote: > I think we're not really sure yet what to do about this. Discussion is > ongoing. I'll report back on Wednesday. This PostgreSQL 10 open item is past due for your status update, and this is overall the seventh time you have you

Re: [HACKERS] walsender & parallelism

On 21/04/17 03:40, Andres Freund wrote: > > Since [1] walsender (not receiver as commit message says) can execute > SQL queries. While doing some testing of [2] I noticed that SQL queries > in walsender get stuck if parallelism is used - I have not investigated > why that is yet, but it surely

Re: [HACKERS] pg_dump emits ALTER TABLE ONLY partitioned_table

Greetings, * Noah Misch (n...@leadboat.com) wrote: > On Mon, Apr 17, 2017 at 03:41:25PM -0400, Stephen Frost wrote: > > I've put up a new patch for review on the thread and plan to commit > > that tomorrow, assuming there isn't anything further. That should > > resolve the immediate issue, but I

[HACKERS] walsender & parallelism

Hi, Since [1] walsender (not receiver as commit message says) can execute SQL queries. While doing some testing of [2] I noticed that SQL queries in walsender get stuck if parallelism is used - I have not investigated why that is yet, but it surely is an issue. On first blush I'd suspect that

Re: [HACKERS] Logical replication and inheritance

On 2017/04/21 3:22, Peter Eisentraut wrote: > On 4/18/17 01:58, Amit Langote wrote: >> We could be more explicit here and say the following instead: >> >> create publication mypub for table p; >> ERROR: "p" is a partitioned table >> DETAIL: Adding partitioned tables to publications is not

Re: [HACKERS] WITH clause in CREATE STATISTICS

On 04/21/2017 12:13 AM, Tom Lane wrote: Alvaro Herrera writes: Simon just pointed out that having the WITH clause appear in the middle of the CREATE STATISTICS command looks odd; apparently somebody else already complained on list about the same. Other commands put

Re: [HACKERS] Unportable implementation of background worker start

Andres Freund writes: > On 2017-04-20 20:05:02 -0400, Tom Lane wrote: >> Also, if it's not there we'd fall back to using plain poll(), which is >> not so awful that we need to work hard to avoid it. I'd just as soon >> keep the number of combinations down. > Just using

Re: [HACKERS] Unportable implementation of background worker start

On 2017-04-20 20:05:02 -0400, Tom Lane wrote: > Andres Freund writes: > > On 2017-04-20 19:53:02 -0400, Tom Lane wrote: > >> So ... what would you say to replacing epoll_create() with > >> epoll_create1(EPOLL_CLOEXEC) ? Then a WaitEventSet would not > >> represent

Re: [HACKERS] Unportable implementation of background worker start

Andres Freund writes: > On 2017-04-20 19:53:02 -0400, Tom Lane wrote: >> So ... what would you say to replacing epoll_create() with >> epoll_create1(EPOLL_CLOEXEC) ? Then a WaitEventSet would not >> represent inheritable-across-exec resources on any platform, >> making it a

Re: [HACKERS] Unportable implementation of background worker start

On 2017-04-20 19:53:02 -0400, Tom Lane wrote: > I wrote: > > Andres Freund writes: > >> On 2017-04-20 19:23:28 -0400, Tom Lane wrote: > >>> or are the HANDLEs in a Windows WaitEventSet not inheritable > >>> resources? > > >> So that kind of sounds like it should be doable. >

Re: [HACKERS] Unportable implementation of background worker start

I wrote: > Andres Freund writes: >> On 2017-04-20 19:23:28 -0400, Tom Lane wrote: >>> or are the HANDLEs in a Windows WaitEventSet not inheritable >>> resources? >> So that kind of sounds like it should be doable. > Ah, good. I'll add a comment about that and press on. So

Re: [HACKERS] Unportable implementation of background worker start

On 2017-04-20 00:50:13 -0400, Tom Lane wrote: > I wrote: > > Alvaro Herrera writes: > >> Tom Lane wrote: > >>> Hm. Do you have a more-portable alternative? > > >> I was thinking in a WaitEventSet from latch.c. > > My first reaction was that that sounded like a lot

Re: [HACKERS] pg_dump emits ALTER TABLE ONLY partitioned_table

Amit, * Amit Langote (langote_amit...@lab.ntt.co.jp) wrote: > On 2017/04/18 1:43, Stephen Frost wrote: > > * Amit Langote (langote_amit...@lab.ntt.co.jp) wrote: > >> OK, I agree. I tweaked the existing bullet point about differences from > >> traditional inheritance when using ONLY with

Re: [HACKERS] Unportable implementation of background worker start

Andres Freund writes: > On 2017-04-20 19:23:28 -0400, Tom Lane wrote: >> or are the HANDLEs in a Windows WaitEventSet not inheritable >> resources? > I think we have control over that. According to >

Re: [HACKERS] Unportable implementation of background worker start

On 2017-04-20 19:23:28 -0400, Tom Lane wrote: > or are the HANDLEs in a Windows WaitEventSet not inheritable > resources? I think we have control over that. According to https://msdn.microsoft.com/en-us/library/windows/desktop/ms724466(v=vs.85).aspx CreateProcess() has to be called with

Re: [HACKERS] Unportable implementation of background worker start

I wrote: > Alvaro Herrera writes: >> Tom Lane wrote: >>> Hm. Do you have a more-portable alternative? >> I was thinking in a WaitEventSet from latch.c. > My first reaction was that that sounded like a lot more work than removing > two lines from maybe_start_bgworker

Re: [HACKERS] WITH clause in CREATE STATISTICS

Alvaro Herrera writes: > Simon just pointed out that having the WITH clause appear in the middle > of the CREATE STATISTICS command looks odd; apparently somebody else > already complained on list about the same. Other commands put the WITH > clause at the end, so

Re: [HACKERS] Removing select(2) based latch (was Unportable implementation of background worker start)

I wrote: > I did my own checking, and concur that only the MinGW buildfarm members > are reporting lacking poll(2) or poll.h. Since they also report lacking > sys/select.h, they must be falling through to the WAIT_USE_WIN32 > implementation. BTW, another amusing thing I just noted is that given

Re: [HACKERS] Removing select(2) based latch (was Unportable implementation of background worker start)

Andres Freund writes: > On 2017-04-20 17:27:42 -0400, Tom Lane wrote: >> In short: yeah, let's nuke the WAIT_USE_SELECT implementation. >> It's dead code and it's unlikely to get resurrected. > Ok, cool. v10 or wait till v11? I see very little reason to wait > personally.

Re: [HACKERS] Use sync commit for logical replication apply in TAP tests

Peter Eisentraut writes: > Double hmm, I ran a few more tests and different machines and get > consistent but underwhelming improvements. > I don't mind applying the patch nonetheless, but maybe we can get a few > more test results from others. > (Instructions:

Re: [HACKERS] Removing select(2) based latch (was Unportable implementation of background worker start)

Hi, On 2017-04-20 17:27:42 -0400, Tom Lane wrote: > Andres Freund writes: > > On 2017-04-19 20:06:05 -0400, Tom Lane wrote: > >> We should check the buildfarm to see if the select() implementation is > >> being tested at all. > > > I verified it's currently not (unless I

Re: [HACKERS] DROP SUBSCRIPTION, query cancellations and slot handling

On 4/20/17 10:19, Petr Jelinek wrote: > Hmm well since this only affects the synchronization of table > states/names, I guess we could just simply do that before we create the > slot as there is no expectancy of consistency between slot and the table > list snapshot. I suppose that wouldn't hurt.

Re: [HACKERS] Removing select(2) based latch (was Unportable implementation of background worker start)

Andres Freund writes: > On 2017-04-19 20:06:05 -0400, Tom Lane wrote: >> We should check the buildfarm to see if the select() implementation is >> being tested at all. > I verified it's currently not (unless I made a mistake): I did my own checking, and concur that only the

Re: [HACKERS] DROP SUBSCRIPTION, query cancellations and slot handling

On 4/20/17 08:41, Michael Paquier wrote: > As subscription is a self-contained concept, it seems to me that any > errors happening should at least try to do some cleanup action before > just giving up processing, that would be a less frustrating > experience. This is the way it's designed. The

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

On Wed, Apr 12, 2017 at 4:35 PM, Robert Haas wrote: > 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

[HACKERS] WITH clause in CREATE STATISTICS

Simon just pointed out that having the WITH clause appear in the middle of the CREATE STATISTICS command looks odd; apparently somebody else already complained on list about the same. Other commands put the WITH clause at the end, so perhaps we should do likewise in the new command. Here's a

Re: [HACKERS] OK, so culicidae is *still* broken

Andres Freund writes: > On 2017-04-20 16:57:03 +0530, Amit Kapila wrote: >> Agreed. I have done some further study by using VMMap tool in Windows >> and it seems to me that all 64-bit processes use address range >> (0001 ~ 07FE). I have attached two

Re: [HACKERS] [POC] hash partitioning

On Mon, Apr 17, 2017 at 10:50 AM, Yugo Nagata wrote: > I thought that the partition constraint could be decided every > time a new partition is created or attached, and that it woule be > needed to relocate records automatically when the partition configuration > changes.

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

On Thu, Apr 20, 2017 at 8:45 AM, Ashutosh Bapat wrote: > I think you are confusing join condition application and partition > bounds of a join relation. You're right, I misunderstood what you were talking about. > But the problem we are trying to solve here

Re: [HACKERS] some review comments on logical rep code

On 4/20/17 12:30, Fujii Masao wrote: > I've pushed several patches, and there is now only one remaining patch. > I posted the review comment on that patch, and I'm expecting that > Masahiko-san will update the patch. So what about waiting for the updated > version of the patch by next Monday

[HACKERS] changing mvstats output to be valid JSON

Hi, While writing the recent ext.stats docs, I became annoyed by the output functions of the new types used by multivariate statistics: they are almost JSON, but not quite. Since they can become largish, I propose that we make a point of ensuring the output of those types is valid JSON, so that

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

On 4/19/17 23:02, Noah Misch wrote: > This PostgreSQL 10 open item is past due for your status update. Kindly send > a status update within 24 hours, and include a date for your subsequent status > update. Refer to the policy on open item ownership: >

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

On 4/18/17 13:18, Tom Lane wrote: > I think you're thinking about it wrong. To my mind the issue is that > there should be some generic way to determine that a bgworker process > is or is not laboring on behalf of an identifiable user. It's great > that we can tell which user it is when there is

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

On 4/18/17 12:37, Tom Lane wrote: > Peter Eisentraut writes: >> I think showing bgw_name as backend_type always sounds reasonable. No >> need to treat external implementations differently. > > That's definitely an approach we could use. It would encourage

Re: [HACKERS] OK, so culicidae is *still* broken

On 2017-04-20 16:57:03 +0530, Amit Kapila wrote: > On Wed, Apr 19, 2017 at 9:01 PM, Andres Freund wrote: > > On 2017-04-19 10:15:31 -0400, Tom Lane wrote: > >> Amit Kapila writes: > >> > On Sun, Apr 16, 2017 at 3:04 AM, Tom Lane

Re: [HACKERS] Logical replication - TRAP: FailedAssertion in pgstat.c

On 4/16/17 16:11, Petr Jelinek wrote: > Yeah it is, it needs to be fenced to happen only after commit, which is > not guaranteed at the point of code, we probably need to put the > pgstat_report_stat() inside the if above after the > CommitTransactionCommand() (that will make it report stats for

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

On 20/04/17 18:58, Peter Eisentraut wrote: > On 4/18/17 22:13, Petr Jelinek wrote: >> So my idea was to add some kind of inuse flag. This turned out to be bit >> more complicated in terms of how to clean it than I would have hoped. >> This is due to the fact that there is no way to reliably tell

Re: [HACKERS] Logical replication and inheritance

On 4/18/17 01:58, Amit Langote wrote: > We could be more explicit here and say the following instead: > > create publication mypub for table p; > ERROR: "p" is a partitioned table > DETAIL: Adding partitioned tables to publications is not supported. > > Thoughts? (a patch is attached for

Re: [HACKERS] AGG_HASHED cost estimate

On Thu, Apr 20, 2017 at 3:46 AM, Ashutosh Bapat < ashutosh.ba...@enterprisedb.com> wrote: > On Thu, Apr 20, 2017 at 7:47 AM, Jeff Janes wrote: > > > > In cost_size.c, there is this comment block: > > > > +* Note: in this cost model, AGG_SORTED and AGG_HASHED have >

Re: [HACKERS] Fwd: WIP Patch: Precalculate stable functions

Marina Polyakova writes: > Now in Postgresql only immutable functions are precalculated; stable > functions are calculated for every row so in fact they don't differ from > volatile functions. > There's a proposal to precalculate stable and immutable functions (= >

Re: [HACKERS] pgbench more operators & functions

Here is a v9 which includes some more cleanup, hopefully in the expected direction which is to make pgbench expressions behave as SQL expressions, and I hope taking into account all other feedback as well. CONTEXT Pgbench has been given an expression parser (878fdcb8) which allows to use

Re: [HACKERS] pgbench tap tests & minor fixes

Hello Nikolay, Hi! Since I used to be good at perl, I like tests, and I've dealt with postgres TAP tests before, I think I can review you patch. If it is OK for everyone. I think that all good wills are welcome, especially concerning code reviews. For now I've just gave this patch a

[HACKERS] Fwd: WIP Patch: Precalculate stable functions

Sorry, attached patch. Исходное сообщение Тема: WIP Patch: Precalculate stable functions Дата: 20-04-2017 19:56 От: Marina Polyakova Кому: pgsql-hackers@postgresql.org Hello everyone! Now in Postgresql only immutable functions are precalculated;

[HACKERS] WIP Patch: Precalculate stable functions

Hello everyone! Now in Postgresql only immutable functions are precalculated; stable functions are calculated for every row so in fact they don't differ from volatile functions. There's a proposal to precalculate stable and immutable functions (= calculate once for all output rows, but as

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

On 4/18/17 22:13, Petr Jelinek wrote: > So my idea was to add some kind of inuse flag. This turned out to be bit > more complicated in terms of how to clean it than I would have hoped. > This is due to the fact that there is no way to reliably tell if worker > has failed to start if the parent

Re: [HACKERS] some review comments on logical rep code

On Thu, Apr 20, 2017 at 12:05 PM, Noah Misch wrote: > On Sun, Apr 16, 2017 at 06:14:49AM +, Noah Misch wrote: >> On Fri, Apr 14, 2017 at 04:47:12AM +0900, Fujii Masao wrote: >> > Though I've read only a part of the logical rep code yet, I'd like to >> > share some

Re: [HACKERS] some review comments on logical rep code

On Tue, Apr 18, 2017 at 5:16 PM, Masahiko Sawada wrote: > On Tue, Apr 18, 2017 at 12:24 PM, Kyotaro HORIGUCHI > wrote: >> Hi, >> >> Thank you for the revised version. >> >> At Mon, 17 Apr 2017 23:29:28 +0900, Masahiko Sawada

Re: [HACKERS] [PATCH] New command to monitor progression of long running queries

2017-04-19 18:41 GMT+02:00 Maksim Milyutin : > On 19.04.2017 17:13, Remi Colinet wrote: > >> Maksim, >> >> >> 2017-04-18 20:31 GMT+02:00 Maksim Milyutin > >: >> >> On 18.04.2017 17:39, Remi Colinet wrote:

Re: [HACKERS] Range Merge Join v1

On Thu, Apr 20, 2017 at 2:05 AM, Rafia Sabih wrote: > Looks like an interesting idea, however, in an attempt to test this patch I > found following error when compiling, > selfuncs.c: In function ‘mergejoinscansel’: > selfuncs.c:2901:12: error: ‘op_strategy’

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

On 4/19/17 23:04, Noah Misch wrote: > This PostgreSQL 10 open item is past due for your status update. Kindly send > a status update within 24 hours, and include a date for your subsequent status > update. Refer to the policy on open item ownership: >

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

On 4/20/17 07:52, Petr Jelinek wrote: > On 20/04/17 05:57, Michael Paquier wrote: >> 2nd thoughts here... Ah now I see your point. True that there is no >> way to ensure that an unwanted command is not running when SIGUSR2 is >> received as the shutdown checkpoint may have already begun. Here is

Re: [HACKERS] Use sync commit for logical replication apply in TAP tests

On 4/20/17 09:46, Petr Jelinek wrote: > On 20/04/17 14:57, Peter Eisentraut wrote: >> On 4/18/17 22:25, Petr Jelinek wrote: >>> The commit 887227a1c changed the defaults for subscriptions to do async >>> commit. But since the tests often wait for disk flush and there is no >>> concurrent activity

Re: [HACKERS] dtrace probes

Hi, On 04/20/2017 09:24 AM, Amit Kapila wrote: The lwlock dtrace probes define LWLockMode as int, and the TRACE_POSTGRESQL_LWLOCK methods are called using both a variable and constant definition. This leads to a mix of argument definitions depending on the call site, as seen in probes.txt

Re: [HACKERS] Optimization for updating foreign tables in Postgres FDW

The subject of this thread is not directly related to this discussion and we have a new thread [1] for relevant discussion. So, let's discuss this further on that thread. [1] https://www.postgresql.org/message-id/CAF1DzPU8Kx%2BfMXEbFoP289xtm3bz3t%2BZfxhmKavr98Bh-C0TqQ%40mail.gmail.com On Tue,

Re: [HACKERS] statement_timeout is not working as expected with postgres_fdw

On Thu, Apr 20, 2017 at 4:08 PM, Suraj Kharage wrote: > Hello All, > > The query on foreign table hangs due to network down of remote server for > near about 16 minutes before exiting. > statement_timeout is expected to work in this case as well but when i tried >

Re: [HACKERS] DROP SUBSCRIPTION, query cancellations and slot handling

On 20/04/17 14:41, Michael Paquier wrote: > On Thu, Apr 20, 2017 at 8:47 PM, Petr Jelinek > wrote: >> Or you can drop the slot manually on upstream. > > Sure, but the point here is that if for example users have > client_min_messages set at least at warning, they

Re: [HACKERS] Logical replication ApplyContext bloat

On Thu, Apr 20, 2017 at 7:04 PM, Stas Kelvich wrote: > Thanks for noting. > > Added short description of ApplyContext and ApplyMessageContext to README. +ApplyContext --- permanent during whole lifetime of apply worker. It is +possible to use TopMemoryContext here as

Re: [HACKERS] Use sync commit for logical replication apply in TAP tests

On 20/04/17 14:57, Peter Eisentraut wrote: > On 4/18/17 22:25, Petr Jelinek wrote: >> The commit 887227a1c changed the defaults for subscriptions to do async >> commit. But since the tests often wait for disk flush and there is no >> concurrent activity this has increased the amount of time needed

Re: [HACKERS] Logical replication ApplyContext bloat

> On 19 Apr 2017, at 16:07, Alvaro Herrera wrote: > > Stas Kelvich wrote: > >> With patch MemoryContextStats() shows following hierarchy during slot >> operations in >> apply worker: >> >> TopMemoryContext: 83824 total in 5 blocks; 9224 free (8 chunks); 74600 used

Re: [HACKERS] dtrace probes

On Tue, Apr 18, 2017 at 9:38 PM, Jesper Pedersen wrote: > Hi, > > The lwlock dtrace probes define LWLockMode as int, and the > TRACE_POSTGRESQL_LWLOCK methods are called using both a variable and > constant definition. > > This leads to a mix of argument definitions

Re: [HACKERS] Use sync commit for logical replication apply in TAP tests

On 4/18/17 22:25, Petr Jelinek wrote: > The commit 887227a1c changed the defaults for subscriptions to do async > commit. But since the tests often wait for disk flush and there is no > concurrent activity this has increased the amount of time needed for > each test. So the attached patch changes

Re: [HACKERS] Highly Variable Planning Times

On 19 April 2017 at 22:39, Michael Malis wrote: >> *At best*, you're doing substantial work in the >> planner to avoid the first tree descent step or two in a single >> non-partial index. Fwiw, in addition to replacing the first few levels of the descent with

Re: [HACKERS] pgbench tap tests & minor fixes

В письме от 17 апреля 2017 14:51:45 пользователь Fabien COELHO написал: > When developping new features for pgbench, I usually write some tests > which are lost when the feature is committed. Given that I have submitted > some more features and that part of pgbench code may be considered for >

Re: [HACKERS] DROP SUBSCRIPTION, query cancellations and slot handling

On Thu, Apr 20, 2017 at 8:47 PM, Petr Jelinek wrote: > Or you can drop the slot manually on upstream. Sure, but the point here is that if for example users have client_min_messages set at least at warning, they may have no idea that an underlying slot has been

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

On 20/04/17 05:57, Michael Paquier wrote: > On Thu, Apr 20, 2017 at 12:40 PM, Michael Paquier > wrote: >> On Thu, Apr 20, 2017 at 4:57 AM, Peter Eisentraut >> wrote: >>> I think the problem with a signal-based solution is that there is

Re: [HACKERS] DROP SUBSCRIPTION, query cancellations and slot handling

On 20/04/17 09:35, Michael Paquier wrote: > On Thu, Apr 20, 2017 at 4:22 PM, Michael Paquier > wrote: >> I am adding an open item. > > Just adding something... When a subscription is created, if the step > synchronizing tables fails then CREATE SUBSCRIPTION fails but

Re: [HACKERS] DROP SUBSCRIPTION, query cancellations and slot handling

On 20/04/17 09:22, Michael Paquier wrote: > Hi, > > I have noticed the following behavior with DROP SUBSCRIPTION followed > by a cancel request. If the remote replication slot is dropped, the > subscription may still be present locally: > =# CREATE SUBSCRIPTION mysub CONNECTION 'port=5432

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

On 20/04/17 06:21, Masahiko Sawada wrote: > On Thu, Apr 20, 2017 at 12:30 AM, Petr Jelinek > wrote: >> On 19/04/17 15:57, Masahiko Sawada wrote: >>> On Wed, Apr 19, 2017 at 10:07 PM, Petr Jelinek >>> wrote: On 19/04/17 14:42,

Re: [HACKERS] AGG_HASHED cost estimate

On Thu, Apr 20, 2017 at 4:16 PM, Ashutosh Bapat wrote: > but cost this without numGroups. > > /* > * The transCost.per_tuple component of aggcosts should be charged once > * per input tuple, corresponding to the costs of evaluating the aggregate >

Re: [HACKERS] snapbuild woes

On 20/04/17 02:09, Andres Freund wrote: > On 2017-04-17 21:16:57 -0700, Andres Freund wrote: >> I think we might need some more tests for this to be committable, so >> it might not become committable tomorrow. > > I'm working on some infrastructure around this. Not sure if it needs to > be

Re: [HACKERS] AGG_HASHED cost estimate

On Thu, Apr 20, 2017 at 7:47 AM, Jeff Janes wrote: > > In cost_size.c, there is this comment block: > > +* Note: in this cost model, AGG_SORTED and AGG_HASHED have exactly > the > +* same total CPU cost, but AGG_SORTED has lower startup cost. If > the > +

[HACKERS] statement_timeout is not working as expected with postgres_fdw

Hello All, The query on foreign table hangs due to network down of remote server for near about 16 minutes before exiting. statement_timeout is expected to work in this case as well but when i tried statement_timeout, it is not working as expected. Below is test case to reproduce the issue: [I

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

On Thu, Apr 20, 2017 at 3:35 PM, Amit Langote wrote: > On 2017/04/20 15:45, Ashutosh Bapat wrote: >> On Thu, Apr 20, 2017 at 10:42 AM, Robert Haas wrote: >>> I don't understand why you think that partition-wise join needs any >>> new logic

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

On 2017/04/20 15:45, Ashutosh Bapat wrote: > On Thu, Apr 20, 2017 at 10:42 AM, Robert Haas wrote: >> I don't understand why you think that partition-wise join needs any >> new logic here; if this were a non-partitionwise join, we'd similarly >> need to use the correct

Re: [HACKERS] Range Merge Join v1

On Thu, Apr 6, 2017 at 2:13 PM, Jeff Davis wrote: > > Example: > > > Find different people using the same website at the same time: > > create table session(sessionid text, username text, during tstzrange); > SELECT s1.username, s2.username, s1.during *

[HACKERS] Patch - Tcl 8.6 version support for PostgreSQL

Hello Team This is regarding Tcl version (8.6) support in PostgreSQL. Currently in PostgreSQL server file (src/tools/msvc/Mkvcbuild.pm) it supports only till Tcl version 8.5 Attach patch contains adding Tcl 8.6 support. Please Note - In Tcl8.6, the library name now contains an extra 't" in

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

> Hello, > >> I think you'd better to change the following comments because there's >> no psqlscan.l or psqlscanslash.l in pgbench source tree. >> >> + * underscore. Keep this in sync with the definition of >> variable_char in >> + * psqlscan.l and psqlscanslash.l. > > Here is a v3 with a more

Re: [HACKERS] DROP SUBSCRIPTION, query cancellations and slot handling

On Thu, Apr 20, 2017 at 4:22 PM, Michael Paquier wrote: > I am adding an open item. Just adding something... When a subscription is created, if the step synchronizing tables fails then CREATE SUBSCRIPTION fails but the slot remains present on the publisher side, so

[HACKERS] DROP SUBSCRIPTION, query cancellations and slot handling

Hi, I have noticed the following behavior with DROP SUBSCRIPTION followed by a cancel request. If the remote replication slot is dropped, the subscription may still be present locally: =# CREATE SUBSCRIPTION mysub CONNECTION 'port=5432 user=mpaquier dbname=mpaquier' PUBLICATION mypub,

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

On Thu, Apr 20, 2017 at 10:42 AM, Robert Haas wrote: > On Tue, Apr 18, 2017 at 6:55 AM, Ashutosh Bapat > wrote: >> When we merge partition bounds from two relations with different >> partition key types, the merged partition bounds need to

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

On Thu, Apr 20, 2017 at 11:32 AM, Tom Lane wrote: > > BTW, I remain totally mystified as to what people think the semantics of > partitioning ought to be. Child columns can have a different type from > parent columns? Really? Why is this even under discussion? We don't >

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

Robert Haas writes: > I don't understand why you think that partition-wise join needs any > new logic here; if this were a non-partitionwise join, we'd similarly > need to use the correct operator, but the existing code handles that > just fine. If the join is performed