Re: [HACKERS] Relation cache invalidation on replica

2017-04-19 Thread Victor Yegorov
2017-03-13 9:22 GMT+02:00 Andres Freund : > >I think we're hitting this particular issue quite frequently when > >rebuilding indexes on master after big-volume data manipulations. > > > >We have `pgbouncer` in transaction mode for both, master and slave, > >therefore it's

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

2017-04-19 Thread Remi Colinet
Maksim, 2017-04-18 20:31 GMT+02:00 Maksim Milyutin : > On 18.04.2017 17:39, Remi Colinet wrote: > >> Hello Maksim, >> >> The core implementation I suggested for the new PROGRESS command uses >> different functions from the one used by EXPLAIN for its core >>

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

2017-04-19 Thread Andres Freund
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 wrote: > >> Obviously, any such fix would be a lot more likely to be reliable in > >> 64-bit machines. There's probably not enough

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

2017-04-19 Thread Masahiko Sawada
On Wed, Apr 19, 2017 at 10:07 PM, Petr Jelinek wrote: > On 19/04/17 14:42, Masahiko Sawada wrote: >> On Wed, Apr 19, 2017 at 5:12 PM, Kyotaro HORIGUCHI >> wrote: >>> At Tue, 18 Apr 2017 18:40:56 +0200, Petr Jelinek >>>

[HACKERS] BuildFarm client release 4.19

2017-04-19 Thread Andrew Dunstan
I have released version 4.19 of the PostgreSQL Buildfarm client. It can be downloaded from Apart from some minor bug fixes, the following changes are made: * Include the script's path in @INC. That means you can

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

2017-04-19 Thread Tom Lane
Amit Kapila writes: > On Sun, Apr 16, 2017 at 3:04 AM, Tom Lane wrote: >> Obviously, any such fix would be a lot more likely to be reliable in >> 64-bit machines. There's probably not enough daylight to be sure of >> making it work in 32-bit Windows,

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

2017-04-19 Thread Remi Colinet
Following on previous email I have added below some use cases which I find very relevant when we need to know the progress of a SQL query. The command can be used by any SQL query (select, update, delete, insert). The tables used have been created with : CREATE TABLE T_1M (id integer, md5

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

2017-04-19 Thread Petr Jelinek
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, Masahiko Sawada wrote: >>> On Wed, Apr 19, 2017 at 5:12 PM, Kyotaro HORIGUCHI >>> wrote: At Tue, 18 Apr

Re: [HACKERS] [PATCH] Push limit to sort through a subquery

2017-04-19 Thread Douglas Doole
Thanks for the feedback Ashutosh. I disagree that we need to call pass_down_bound() recursively. The whole point of the recursive call would be to tunnel through a plan node. Since SubqueryScanState only has one child (unlike MergeAppendState) this can be more efficiently done inline rather than

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

2017-04-19 Thread 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: Regarding the queryDesc state of SQL query upon receiving a request to

Re: [HACKERS] Cost of src/test/recovery and .../subscription tests

2017-04-19 Thread Andrew Dunstan
On 04/19/2017 01:28 PM, Tom Lane wrote: > So I updated longfin to the new release of the buildfarm client, > and was quite dismayed by the fact that its cycle time went > from 16 minutes to 24. Some of that might be random effects like > the state of the kernel disk caches, but a large chunk of

Re: [HACKERS] [buildfarm-members] BuildFarm client release 4.19

2017-04-19 Thread Tom Lane
Andrew Dunstan writes: > I have released version 4.19 of the PostgreSQL Buildfarm client. It can > be downloaded from > Nice work! > * Improvements to TAP tests logging and coverage. Each

Re: [HACKERS] [buildfarm-members] BuildFarm client release 4.19

2017-04-19 Thread Andrew Dunstan
On 04/19/2017 01:38 PM, Tom Lane wrote: > Andrew Dunstan writes: >> I have released version 4.19 of the PostgreSQL Buildfarm client. It can >> be downloaded from >> > Nice work! > Thank

Re: [HACKERS] SASL minor docs typo

2017-04-19 Thread Heikki Linnakangas
On 04/18/2017 08:50 PM, Jaime Casanova wrote: Hi, reading SASL docs found this typo: in protocol.sgml:1356 """ To begin a SASL authentication exchange, the server an AuthenticationSASL message. """ I guess it should say "the server sends an AuthenticationSASL message" Yep, fixed. Thanks!

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

2017-04-19 Thread Peter Eisentraut
On 4/19/17 01:45, Michael Paquier wrote: > On Tue, Apr 18, 2017 at 3:27 AM, Peter Eisentraut > wrote: >> I'd imagine the postmaster would tell the walsender that it has started >> shutdown, and then the walsender would reject $certain_things. But I >> don't see

Re: [HACKERS] Should pg_current_wal_location() become pg_current_wal_lsn()

2017-04-19 Thread Euler Taveira
2017-04-19 1:32 GMT-03:00 Michael Paquier : > I vote for "location" -> "lsn". I would expect complains about the > current inconsistency at some point, and the function names have been > already changed for this release.. > +1. -- Euler Taveira

Fwd: [HACKERS] GSoC 2017 Proposal

2017-04-19 Thread Mark Rofail
Dear Mr Alexander, I was checking the archives today and to my shock, I did not find my reply to your previous question which was almost two weeks ago. I apologise for the inconvenience, I have however replied within an hour but apparently, it did not go through. Best Regards, Mark Moheb On

[HACKERS] Highly Variable Planning Times

2017-04-19 Thread Michael Malis
Hi, I've been encountering highly variable planning time on PG 9.5.4. Running `EXPLAIN SELECT * FROM events_1171738` will take anywhere from 200ms to 4s. This likely has to do with the table having 1300 partial indexes on it (for reasons elaborated on in

Re: [HACKERS] Relation cache invalidation on replica

2017-04-19 Thread Andres Freund
On 2017-04-19 17:07:49 +0300, Victor Yegorov wrote: > 2017-03-13 9:22 GMT+02:00 Andres Freund : > > > >I think we're hitting this particular issue quite frequently when > > >rebuilding indexes on master after big-volume data manipulations. > > > > > >We have `pgbouncer` in

Re: [HACKERS] Ongoing issues with representation of empty arrays

2017-04-19 Thread David G. Johnston
On Mon, Apr 10, 2017 at 4:57 PM, Andrew Gierth wrote: > The distinction between the standard representation of '{}' as an array > with zero dimensions and nonstandard representations as a 1-dimensional > array with zero elements has come up in a couple of contexts on

Re: [HACKERS] Ongoing issues with representation of empty arrays

2017-04-19 Thread Merlin Moncure
On Mon, Apr 10, 2017 at 11:17 PM, Andrew Gierth wrote: >> "Tom" == Tom Lane writes: > > >> First is contrib/intarray, _AGAIN_ (see past bugs such as #7730): > >> ... > >> I plan to fix this one properly, unless anyone has any objections. >

Re: [HACKERS] Relation cache invalidation on replica

2017-04-19 Thread Victor Yegorov
2017-04-19 23:08 GMT+03:00 Andres Freund : > I was thinking of c6ff84b06a68b71719aa1aaa5f6704d8db1b51f8 > Thanks a lot! I found, that this got into 9.6 already via the Release Notes: https://www.postgresql.org/docs/current/static/release-9-6.html#AEN131397 Will certainly

[HACKERS] Unportable implementation of background worker start

2017-04-19 Thread Tom Lane
I chanced to notice that on gaur/pademelon, the "select_parallel" regression test sometimes takes a great deal longer than normal, for no obvious reason. It does eventually terminate, but sometimes only after 10 to 20 minutes rather than the couple dozen seconds that are typical on that slow

Re: [HACKERS] Highly Variable Planning Times

2017-04-19 Thread Michael Malis
> TBH, I see no convincing explanation in that article of why 1300 partial > indexes are a good idea. I don't like it much either. I've been trying to eliminate most of the need for the partial indexes, but this is the current state of things. > *At best*, you're doing substantial work in the >

Re: [HACKERS] Highly Variable Planning Times

2017-04-19 Thread Andres Freund
On 2017-04-19 14:14:54 -0700, Michael Malis wrote: > > Could you also get a profile using perf record -g? The strace isn't > > telling us all that much. > > I've attached the perf.data file from `perf record -g -p > `. I'm not that familiar with perf so if there is more > information you need

Re: [HACKERS] Unportable implementation of background worker start

2017-04-19 Thread Alvaro Herrera
Tom Lane wrote: > While I haven't yet tested it, it seems like a fix might be as simple > as deleting these lines in maybe_start_bgworker: > > /* > * Have ServerLoop call us again. Note that there might not > * actually *be* another runnable worker, but we

Re: [HACKERS] Highly Variable Planning Times

2017-04-19 Thread Andres Freund
Hi, On 2017-04-19 13:39:40 -0700, Michael Malis wrote: > I've been encountering highly variable planning time on PG 9.5.4. > Running `EXPLAIN SELECT * FROM events_1171738` will take anywhere from > 200ms to 4s. This likely has to do with the table having 1300 partial > indexes on it (for reasons

Re: [HACKERS] Unportable implementation of background worker start

2017-04-19 Thread Tom Lane
Alvaro Herrera writes: > Tom Lane wrote: >> So I'm wondering what the design rationale was for only starting one >> bgworker per invocation. > The rationale was that there may be other tasks waiting for postmaster > attention, and if there are many bgworkers needing to

Re: [HACKERS] Highly Variable Planning Times

2017-04-19 Thread Michael Malis
> The profile seems to confirm that this is largely due to cache misses. Can you elaborate? Cache misses of what? Why is the planning time so variable? -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription:

Re: [HACKERS] Unportable implementation of background worker start

2017-04-19 Thread Tom Lane
Andres Freund writes: > FWIW, I'd wished before that we used something a bit more modern than > select() if available... It's nice to be able to listen to a larger > number of sockets without repeated O(sockets) overhead. [ raised eyebrow... ] Is anyone really running

Re: [HACKERS] snapbuild woes

2017-04-19 Thread Andres Freund
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 committed, but it's certainly useful for evaluation.

Re: [HACKERS] Continuous buildfarm failures on hamster with bin-check

2017-04-19 Thread Michael Paquier
On Wed, Apr 19, 2017 at 7:03 AM, Michael Paquier wrote: > On Wed, Apr 19, 2017 at 12:48 AM, Tom Lane wrote: >> Alvaro Herrera writes: >>> Tom Lane wrote: FWIW, I'm a bit suspicious of relocating the temp stats

[HACKERS] BRIN autosummarize tests

2017-04-19 Thread Nikolay Shaplov
Hi! Alvaro, you've recently commited patch with BRIN autosummarize Tell me, this feature can't be really tested via regression tests? Because now I am rebasing my reloptions patch (again!), and as it was partly rebased, I run make check. At that point I did not moved implementation of this

[HACKERS] Cost of src/test/recovery and .../subscription tests

2017-04-19 Thread Tom Lane
So I updated longfin to the new release of the buildfarm client, and was quite dismayed by the fact that its cycle time went from 16 minutes to 24. Some of that might be random effects like the state of the kernel disk caches, but a large chunk of it --- over 5 minutes --- evidently is from

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

2017-04-19 Thread Michael Paquier
On Thu, Apr 20, 2017 at 4:57 AM, Peter Eisentraut wrote: > On 4/19/17 01:45, Michael Paquier wrote: >> On Tue, Apr 18, 2017 at 3:27 AM, Peter Eisentraut >> wrote: >>> I'd imagine the postmaster would tell the walsender that it

Re: [HACKERS] Highly Variable Planning Times

2017-04-19 Thread Michael Malis
Thanks for the help Andres. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers

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

2017-04-19 Thread Michael Paquier
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 no >> feedback. Ideally, you would wait for all

Re: [HACKERS] identity columns

2017-04-19 Thread Vitaly Burovoy
On 4/18/17, Peter Eisentraut wrote: > On 4/7/17 01:26, Vitaly Burovoy wrote: >> I've implement SET GENERATED ... IF NOT EXISTS. It must be placed >> before other SET options but fortunately it conforms with the >> standard. >> Since that form always changes the

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

2017-04-19 Thread Masahiko Sawada
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, Masahiko Sawada wrote: On Wed, Apr 19, 2017 at

Re: [HACKERS] Highly Variable Planning Times

2017-04-19 Thread Andres Freund
On 2017-04-19 16:43:07 -0700, Michael Malis wrote: > > The profile seems to confirm that this is largely due to cache misses. > > Can you elaborate? Cache misses of what? Why is the planning time so > variable? Postgres uses caches for a lot of metadata of tables, indexes, ... Some actions, like

Re: [HACKERS] Unportable implementation of background worker start

2017-04-19 Thread Andres Freund
On 2017-04-19 18:56:26 -0400, Tom Lane wrote: > Alvaro Herrera writes: > > Tom Lane wrote: > >> Hm. Do you have a more-portable alternative? > > > I was thinking in a WaitEventSet from latch.c. > > Yeah, some googling turns up the suggestion that a self-pipe is a

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

2017-04-19 Thread Kyotaro HORIGUCHI
Ok, I got the point. At Wed, 19 Apr 2017 17:39:01 +0900 (Tokyo Standard Time), Kyotaro HORIGUCHI wrote in <20170419.173901.16598616.horiguchi.kyot...@lab.ntt.co.jp> > > >> | > > >> | Quorum-based synchronous replication is basically more > > >> |

Re: [HACKERS] Highly Variable Planning Times

2017-04-19 Thread Alvaro Herrera
Michael Malis wrote: > Hi, > > I've been encountering highly variable planning time on PG 9.5.4. > Running `EXPLAIN SELECT * FROM events_1171738` will take anywhere from > 200ms to 4s. This likely has to do with the table having 1300 partial > indexes on it (for reasons elaborated on in >

Re: [HACKERS] Highly Variable Planning Times

2017-04-19 Thread Tom Lane
Michael Malis writes: > I've been encountering highly variable planning time on PG 9.5.4. > Running `EXPLAIN SELECT * FROM events_1171738` will take anywhere from > 200ms to 4s. This likely has to do with the table having 1300 partial > indexes on it (for reasons

Re: [HACKERS] Highly Variable Planning Times

2017-04-19 Thread Jeff Janes
On Wed, Apr 19, 2017 at 2:39 PM, Michael Malis wrote: > > TBH, I see no convincing explanation in that article of why 1300 partial > > indexes are a good idea. > > I don't like it much either. I've been trying to eliminate most of the > need for the partial indexes, but

Re: [HACKERS] Unportable implementation of background worker start

2017-04-19 Thread Alvaro Herrera
Tom Lane wrote: > Alvaro Herrera writes: > > Tom Lane wrote: > >> So I'm wondering what the design rationale was for only starting one > >> bgworker per invocation. > > > The rationale was that there may be other tasks waiting for postmaster > > attention, and if there

Re: [HACKERS] Unportable implementation of background worker start

2017-04-19 Thread Tom Lane
Alvaro Herrera writes: > Tom Lane wrote: >> Hm. Do you have a more-portable alternative? > I was thinking in a WaitEventSet from latch.c. Yeah, some googling turns up the suggestion that a self-pipe is a portable way to get consistent semantics from select(); latch.c

Re: [HACKERS] Highly Variable Planning Times

2017-04-19 Thread Andres Freund
On 2017-04-19 14:14:54 -0700, Michael Malis wrote: > > Could you also get a profile using perf record -g? The strace isn't > > telling us all that much. > > I've attached the perf.data file from `perf record -g -p > `. I'm not that familiar with perf so if there is more > information you need

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

2017-04-19 Thread Andres Freund
On 2017-04-19 20:06:05 -0400, Tom Lane wrote: > > BTW, we IIRC had discussed removing the select() backed latch > > implementation in this release. I'll try to dig up that discussion. > > Might be sensible. Even my pet dinosaurs have poll(2). I can't find the discussion anymore, but I'm fairly

Re: [HACKERS] Other formats in pset like markdown, rst, mediawiki

2017-04-19 Thread Fabien COELHO
I still do not understand "why" this variant vs CommonMark or whatever other version. Because of simply implementation and readability (looks similar to aligned format) and it is comfortable to edit generated table (changing values, aligning columns etc.). Hmmm. Why not. Sorry, maybe I`m

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

2017-04-19 Thread Masahiko Sawada
On Wed, Apr 19, 2017 at 5:12 PM, Kyotaro HORIGUCHI wrote: > At Tue, 18 Apr 2017 18:40:56 +0200, Petr Jelinek > wrote in > >> On 18/04/17 18:14, Peter Eisentraut wrote: >> > On

Re: [HACKERS] Fixup some misusage of appendStringInfo and friends

2017-04-19 Thread Ashutosh Bapat
I reviewed the patch. It compiles clean, make check-world passes. I do not see any issue with it. On Wed, Apr 19, 2017 at 9:13 AM, David Rowley wrote: > The attached cleans up a few small misusages of appendStringInfo and > related functions. > > Some similar work

Re: [HACKERS] Logical replication ApplyContext bloat

2017-04-19 Thread Stas Kelvich
> On 19 Apr 2017, at 14:30, Petr Jelinek wrote: > > On 19/04/17 12:46, Stas Kelvich wrote: >> >> Right now ApplyContext cleaned after each transaction and by this patch I >> basically >> suggest to clean it after each command counter increment. >> >> So in

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

2017-04-19 Thread Petr Jelinek
On 19/04/17 14:42, Masahiko Sawada wrote: > On Wed, Apr 19, 2017 at 5:12 PM, Kyotaro HORIGUCHI > wrote: >> At Tue, 18 Apr 2017 18:40:56 +0200, Petr Jelinek >> wrote in >> >>>

Re: [HACKERS] Logical replication ApplyContext bloat

2017-04-19 Thread Alvaro Herrera
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 > ApplyContext: 8192 total in 1 blocks; 6520 free (4 chunks); 1672 used >

Re: [HACKERS] Logical replication ApplyContext bloat

2017-04-19 Thread Simon Riggs
On 19 April 2017 at 11:24, Petr Jelinek wrote: > I'd still like you to add comment to the ApplyContext saying that it's > cleaned after handling each message so nothing that needs to survive for > example whole transaction can be allocated in it as that's not very

Re: [HACKERS] Logical replication ApplyContext bloat

2017-04-19 Thread Petr Jelinek
On 19/04/17 12:46, Stas Kelvich wrote: > >> On 19 Apr 2017, at 13:34, Simon Riggs wrote: >> >> On 19 April 2017 at 11:24, Petr Jelinek wrote: >> >>> I'd still like you to add comment to the ApplyContext saying that it's >>> cleaned after

Re: [HACKERS] Unportable implementation of background worker start

2017-04-19 Thread Tom Lane
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 and

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

2017-04-19 Thread Robert Haas
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 have some > information abound the way those constants look like e.g. their >

Re: [HACKERS] Logical replication ApplyContext bloat

2017-04-19 Thread Petr Jelinek
On 19/04/17 11:55, Stas Kelvich wrote: > >> On 19 Apr 2017, at 12:37, Petr Jelinek wrote: >> >> On 18/04/17 13:45, Stas Kelvich wrote: >>> Hi, >>> >>> currently logical replication worker uses ApplyContext to decode received >>> data >>> and that context is never

Re: [HACKERS] Logical replication ApplyContext bloat

2017-04-19 Thread Stas Kelvich
> On 19 Apr 2017, at 13:34, Simon Riggs wrote: > > On 19 April 2017 at 11:24, Petr Jelinek wrote: > >> I'd still like you to add comment to the ApplyContext saying that it's >> cleaned after handling each message so nothing that needs to

[HACKERS] AGG_HASHED cost estimate

2017-04-19 Thread Jeff Janes
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 +* input path is already sorted appropriately, AGG_SORTED should be +*

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

2017-04-19 Thread Noah Misch
On Sun, Apr 16, 2017 at 06:12:58AM +, Noah Misch wrote: > On Wed, Apr 12, 2017 at 10:55:08PM +0900, Fujii Masao wrote: > > When I shut down the publisher while I repeated creating and dropping > > the subscription in the subscriber, the publisher emitted the following > > PANIC error during

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

2017-04-19 Thread Noah Misch
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 (relatively minor) review comments that I got so far. > > > > In ApplyWorkerMain(),

Re: [HACKERS] [PATCH] Push limit to sort through a subquery

2017-04-19 Thread Ashutosh Bapat
On Wed, Apr 19, 2017 at 10:51 PM, Douglas Doole wrote: > Thanks for the feedback Ashutosh. > > I disagree that we need to call pass_down_bound() recursively. The whole > point of the recursive call would be to tunnel through a plan node. Since > SubqueryScanState only has one

Re: [HACKERS] pg_dump emits ALTER TABLE ONLY partitioned_table

2017-04-19 Thread Noah Misch
On Mon, Apr 17, 2017 at 03:41:25PM -0400, Stephen Frost wrote: > * Noah Misch (n...@leadboat.com) wrote: > > On Thu, Apr 13, 2017 at 11:38:08AM -0400, Robert Haas wrote: > > > On Thu, Apr 13, 2017 at 11:05 AM, Stephen Frost > > > wrote: > > > > Sure, though I won't be able to

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

2017-04-19 Thread Noah Misch
On Sun, Apr 16, 2017 at 06:08:41AM +, Noah Misch wrote: > On Thu, Apr 06, 2017 at 11:33:22AM +0900, Masahiko Sawada wrote: > > While testing table sync worker for logical replication I noticed that > > if the table sync worker of logical replication failed to insert the > > data for whatever

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

2017-04-19 Thread Kyotaro HORIGUCHI
At Tue, 18 Apr 2017 18:40:56 +0200, Petr Jelinek wrote in > On 18/04/17 18:14, Peter Eisentraut wrote: > > On 4/18/17 11:59, Petr Jelinek wrote: > >> Hmm if we create hashtable for this, I'd say create hashtable

Re: [HACKERS] Should pg_current_wal_location() become pg_current_wal_lsn()

2017-04-19 Thread Kyotaro HORIGUCHI
At Wed, 19 Apr 2017 13:32:48 +0900, Michael Paquier wrote in

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

2017-04-19 Thread Petr Jelinek
On 19/04/17 10:25, Kyotaro HORIGUCHI wrote: > At Wed, 19 Apr 2017 04:18:18 +0200, Petr Jelinek > wrote in > >> On 18/04/17 19:27, Fujii Masao wrote: >>> On Wed, Apr 19, 2017 at 1:35 AM, Petr Jelinek >>>

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

2017-04-19 Thread Amit Kapila
On Sun, Apr 16, 2017 at 3:04 AM, Tom Lane wrote: > Andres Freund writes: >> On 2017-04-15 17:24:54 -0400, Tom Lane wrote: >>> I wonder whether we could work around that by just destroying the created >>> process and trying again if we get a collision.

Re: [HACKERS] Other formats in pset like markdown, rst, mediawiki

2017-04-19 Thread Jan Michálek
2017-04-19 9:18 GMT+02:00 Fabien COELHO : > > I still do not understand "why" this variant vs CommonMark or whatever >>> other version. >>> >> >> Because of simply implementation and readability (looks similar to aligned >> format) and it is comfortable to edit generated

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

2017-04-19 Thread Kyotaro HORIGUCHI
At Wed, 19 Apr 2017 04:18:18 +0200, Petr Jelinek wrote in > On 18/04/17 19:27, Fujii Masao wrote: > > On Wed, Apr 19, 2017 at 1:35 AM, Petr Jelinek > > wrote: > >> Thank you for

Re: [HACKERS] Other formats in pset like markdown, rst, mediawiki

2017-04-19 Thread Jan Michálek
2017-04-18 23:06 GMT+02:00 Fabien COELHO : > > Hello, > > There are different flavour of markdown, maybe you should document which >>> one is targetted. Should it be CommonMark? Another variant? Why? >>> >> >> This should be pandoc pipe table. It's because it is similar to

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

2017-04-19 Thread Kyotaro HORIGUCHI
At Wed, 19 Apr 2017 17:43:17 +0900 (Tokyo Standard Time), Kyotaro HORIGUCHI wrote in <20170419.174317.114509231.horiguchi.kyot...@lab.ntt.co.jp> > At Wed, 19 Apr 2017 10:33:29 +0200, Petr Jelinek > wrote in >

Re: [HACKERS] Proposal: Local indexes for partitioned table

2017-04-19 Thread Maksim Milyutin
On 19.04.2017 11:42, Ashutosh Bapat wrote: On Tue, Apr 18, 2017 at 4:43 PM, Maksim Milyutin wrote: Local partitioned indexes can be recognized through the check on the relkind of table to which the index refers. Something like this: heap =

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

2017-04-19 Thread Kyotaro HORIGUCHI
At Wed, 19 Apr 2017 10:33:29 +0200, Petr Jelinek wrote in > > Commit has been moved from after to before of the lock section. > > This causes potential race condition. (As the same as the > > potential

Re: [HACKERS] Proposal: Local indexes for partitioned table

2017-04-19 Thread Ashutosh Bapat
On Tue, Apr 18, 2017 at 4:43 PM, Maksim Milyutin wrote: > On 18.04.2017 13:08, Amit Langote wrote: >> >> Hi, >> > > Hi, Amit! > >> On 2017/04/17 23:00, Maksim Milyutin wrote: >>> >>> >>> Ok, thanks for the note. >>> >>> But I want to discuss the relevancy of

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

2017-04-19 Thread Kyotaro HORIGUCHI
At Wed, 19 Apr 2017 03:03:38 +0900, Fujii Masao wrote in

Re: [HACKERS] [PATCH] Push limit to sort through a subquery

2017-04-19 Thread Ashutosh Bapat
The function pass_down_bound() is a recursive function. For SubqueryScanState we have to do something similar to ResultState i.e. call pass_down_bound() recursively on subqueryScanState->subplan. Please add this to the next commitfest. On Wed, Apr 19, 2017 at 6:09 AM, Douglas Doole

Re: [HACKERS] Logical replication ApplyContext bloat

2017-04-19 Thread Stas Kelvich
> On 19 Apr 2017, at 12:37, Petr Jelinek wrote: > > On 18/04/17 13:45, Stas Kelvich wrote: >> Hi, >> >> currently logical replication worker uses ApplyContext to decode received >> data >> and that context is never freed during transaction processing. Hence if

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

2017-04-19 Thread Petr Jelinek
On 19/04/17 10:45, Kyotaro HORIGUCHI wrote: > At Wed, 19 Apr 2017 17:43:17 +0900 (Tokyo Standard Time), Kyotaro HORIGUCHI > wrote in > <20170419.174317.114509231.horiguchi.kyot...@lab.ntt.co.jp> >> At Wed, 19 Apr 2017 10:33:29 +0200, Petr Jelinek >>

Re: [HACKERS] Logical replication ApplyContext bloat

2017-04-19 Thread Petr Jelinek
On 18/04/17 13:45, Stas Kelvich wrote: > Hi, > > currently logical replication worker uses ApplyContext to decode received data > and that context is never freed during transaction processing. Hence if > publication > side is performing something like 10M row inserts in single transaction, then