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 have some >> information abound the way those constants l

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 > allow that in old-sch

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 partition-wise, it should

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

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 > length, structure etc. That's the reaso

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 and adjusting some comments. Bu

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

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 5:12 PM, Kyotaro HORIGUCHI wrote: > At Tue, 18 Apr 201

Re: [HACKERS] identity columns

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 sequence behind the column, I >> dec

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

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 walsenders to acknowledge the >> receipt of SIGUSR2 (or simil

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

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 has started >>> shutdown, and then the walsender would reject $certain

Re: [HACKERS] Highly Variable Planning Times

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] [PATCH] Push limit to sort through a subquery

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 child (unlike MergeAp

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

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(), Da

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

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 shu

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

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

Re: [HACKERS] pg_dump emits ALTER TABLE ONLY partitioned_table

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 today and I've got s

[HACKERS] AGG_HASHED cost estimate

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 +* preferr

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

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 directory as being a reliable fix for this. >> >>> It's an SD card (the kind

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

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 s

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

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 > > >> | efficient than priority-based one wh

Re: [HACKERS] snapbuild woes

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. Ba

Re: [HACKERS] Unportable implementation of background worker start

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 postmasters with enough lis

Re: [HACKERS] Unportable implementation of background worker start

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 portable > way to get consisten

Re: [HACKERS] Highly Variable Planning Times

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] Highly Variable Planning Times

> 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: http://www.postgresql.org/mailpref/

Re: [HACKERS] Highly Variable Planning Times

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 let

Re: [HACKERS] Unportable implementation of background worker start

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 has already done that. I s

Re: [HACKERS] Unportable implementation of background worker start

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 are many bgworkers needing

Re: [HACKERS] Unportable implementation of background worker start

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 be started, the > other wor

Re: [HACKERS] Unportable implementation of background worker start

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 d

Re: [HACKERS] Highly Variable Planning Times

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 let

[HACKERS] Unportable implementation of background worker start

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 machi

Re: [HACKERS] Highly Variable Planning Times

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 this is the current state

Re: [HACKERS] Highly Variable Planning Times

> 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 > p

Re: [HACKERS] Relation cache invalidation on replica

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 check this out soon! --

Re: [HACKERS] Highly Variable Planning Times

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 elaborated on in > https://blog.he

Re: [HACKERS] Highly Variable Planning Times

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 > https://

Re: [HACKERS] Highly Variable Planning Times

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 e

[HACKERS] Highly Variable Planning Times

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 https://blog.heapanalytics.com/running-10-m

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

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. > > Tom> Just to clarify, what do you think is "pro

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

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 the IRC > channel recently. >

Re: [HACKERS] Relation cache invalidation on replica

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 transaction mode for bot

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

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 an existing way for the walsender t

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

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 Timbira - ht

Fwd: [HACKERS] GSoC 2017 Proposal

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 Thu,

Re: [HACKERS] SASL minor docs typo

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] [buildfarm-members] BuildFarm client release 4.19

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 you. >> * Improvements to TAP

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

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

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 test set (i.e > each /t dire

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

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 src/te

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

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 v

[HACKERS] BRIN autosummarize tests

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 op

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

On 19.04.2017 17:13, Remi Colinet wrote: Maksim, 2017-04-18 20:31 GMT+02:00 Maksim Milyutin mailto:m.milyu...@postgrespro.ru>>: On 18.04.2017 17:39, Remi Colinet wrote: Regarding the queryDesc state of SQL query upon receiving a request to report its execution pro

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

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 daylight to be sure of > >> making it work in 32-bi

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

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 2017 18:40:56 +0200, Petr Jelinek wrote in > On

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

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 t

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

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, so I suspect we'd need some retry >> logic an

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

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 >> implementation. >> Some source code i

Re: [HACKERS] Relation cache invalidation on replica

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 quite typical to have ses

[HACKERS] BuildFarm client release 4.19

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 usually

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

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 >>> wrote in >>> On 18/04/17 18:14, Peter Eisentraut wrote: > On 4/18

Re: [HACKERS] Logical replication ApplyContext bloat

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 > ApplyMessag

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

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 >> >>> On 18/04/17 18:14, Peter Eisentraut wrote: On 4/18/17 11:59, Petr Jelinek wrote: > Hmm if we create hashtable

Re: [HACKERS] Logical replication ApplyContext bloat

> 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 your definitions that is ApplyMess

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

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 4/18/17 11:59, Petr Jelinek wrote: >> >> Hmm if we create hashtable for this, I'd say create hashtable for the >> >> w

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

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 was done in, > > f92d6a540ac443f

Re: [HACKERS] Logical replication ApplyContext bloat

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 handling each message so nothing that needs to survive for

Re: [HACKERS] Logical replication ApplyContext bloat

> 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 survive for >> example whole transaction can be allocate

Re: [HACKERS] Logical replication ApplyContext bloat

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 well > visible IMHO (and I know

Re: [HACKERS] Logical replication ApplyContext bloat

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 freed during transaction process

Re: [HACKERS] Logical replication ApplyContext bloat

> 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 >> publication >> side is perfor

Re: [HACKERS] Logical replication ApplyContext bloat

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 >

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

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 = relation_open(IndexGetRelation(indexid, false), heapL

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

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 >> wrote in >> Commit has been moved fro

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

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 wrote: > We'v

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

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 > > > > Commit has been moved from after to before of the lock section. > > > This ca

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

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 dead-lock, I'm not sure it can cause realistic problem, > > though..) Isn't it better to be af

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

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 introduction of a new relkind for >>> p

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

At Wed, 19 Apr 2017 03:03:38 +0900, Fujii Masao wrote in > On Tue, Apr 18, 2017 at 7:02 PM, Masahiko Sawada > wrote: > > On Tue, Apr 18, 2017 at 6:40 PM, Kyotaro HORIGUCHI > > wrote: > >> At Tue, 18 Apr 2017 14:58:50 +0900, Masahiko Sawada > >> wrote in > >> > >>> On Tue, Apr 18, 2017 at

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

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 >>> wrote: Thank you for working on this! On 18/04/17 10:16, Masahiko Sawada wro

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

At Wed, 19 Apr 2017 13:32:48 +0900, Michael Paquier wrote in > On Wed, Apr 19, 2017 at 12:36 PM, David Rowley > wrote: > > In favour of "location" -> "lsn": Tom, Stephen, David Steel > > In favour of "lsn" -> "location": Peter, Kyotaro > > I vote for "location" -> "lsn". I would expect complai

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

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 working on this! > >> > >> On 18/04/17 10:16, Masahiko Sawada wrote: > >>> On Tue, Apr 18, 2017 at 12:24 PM, Kyotaro

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

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 for the > >> whole table_states then. The reason why it's list now was that it seeme

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

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 table (changing values, >>

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

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 n