Re: [HACKERS] Assertion failure in REL9_5_STABLE

On Wed, Apr 19, 2017 at 11:19 AM, Andrew Gierth wrote: > > "Pavan" == Pavan Deolasee writes: > > Pavan> I am attaching a patch that throws a similar ERROR during > Pavan> planning even for 9.5. AFAICS in presence of grouping sets, we

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

On Wed, Apr 19, 2017 at 1:52 PM, 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: >>> >

Re: [HACKERS] Assertion failure in REL9_5_STABLE

> "Pavan" == Pavan Deolasee writes: Pavan> I am attaching a patch that throws a similar ERROR during Pavan> planning even for 9.5. AFAICS in presence of grouping sets, we Pavan> always decide to use sort-based implementation for grouping, but Pavan> do not check

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

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 to know that

[HACKERS] Assertion failure in REL9_5_STABLE

Hi All, I stumbled upon this test case from the master that sets an assertion failure (see stack trace at the end) on REL9_5_STABLE. create temp table gstest4(id integer, v integer, unhashable_col bit(4), unsortable_col xid); insert into gstest4 values

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

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 14, 2017 at 11:58:23PM -0400, Noah Misch wrote: >> >> On Wed, Apr 05,

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

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 complains about the current inconsistency at some

[HACKERS] Fixup some misusage of appendStringInfo and friends

The attached cleans up a few small misusages of appendStringInfo and related functions. Some similar work was done in, f92d6a540ac443f85f0929b284edff67da14687a d02f16470f117db3038dbfd87662d5f0eb5a2a9b cacbdd78106526d7c4f11f90b538f96ba8696fb0 so the majority of these should all be new

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

Amit Kapila writes: > On Wed, Apr 19, 2017 at 1:27 AM, Tom Lane wrote: >> I think leaving that sort of thing out is just creating a latent bug >> that is certain to bite you later. It's true that as long as the args >> list contains only Vars, it

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

On 19 April 2017 at 15:31, Tom Lane wrote: > David Rowley writes: >> OK, so I've read over this thread again and I think it's time to >> summarise the votes: >> ... >> In favour of "location" -> "lsn": Stephen, David Steel, >> In favour of "lsn"

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

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 14, 2017 at 11:58:23PM -0400, Noah Misch wrote: > >> On Wed, Apr 05, 2017 at 09:51:02PM -0400, Noah Misch wrote: > >> > On Thu, Apr 06, 2017 at

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

David Rowley writes: > OK, so I've read over this thread again and I think it's time to > summarise the votes: > ... > In favour of "location" -> "lsn": Stephen, David Steel, > In favour of "lsn" -> "location": Peter, Tom, Kyotaro FWIW, I was not voting in favor of

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

On Wed, Apr 19, 2017 at 1:27 AM, Tom Lane wrote: > Amit Kapila writes: >> I have ended up doing something along the lines suggested by you (or >> at least what I have understood from your e-mail). Basically, pass >> the safe-param-ids list to

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

On 19 April 2017 at 03:33, David Steele wrote: > +1, and I'm in favor of using "lsn" wherever applicable. It seems to me > that if a user calls a function (or queries a table) that returns an lsn > then they should be aware of what an lsn is. OK, so I've read over this

Re: [HACKERS] Failed recovery with new faster 2PC code

On Wed, Apr 19, 2017 at 11:09 AM, Jeff Janes wrote: > Would this bug have been seen in a replica server in the absence of crashes, > or was it only vulnerable during crash recovery rather than streaming > replication? This issue could have been seen on a streaming standby

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

Hi, 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 the subscriptions create in tab tests to

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

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

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

On 17/04/17 20:09, Peter Eisentraut wrote: > On 4/16/17 22:01, 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

Re: [HACKERS] Failed recovery with new faster 2PC code

On Tue, Apr 18, 2017 at 1:17 AM, Nikhil Sontakke wrote: > Hi, > > There was a bug in the redo 2PC remove code path. Because of which, > autovac would think that the 2PC is gone and cause removal of the > corresponding clog entry earlier than needed. > > Please find

Re: [HACKERS] Failed recovery with new faster 2PC code

On Tue, Apr 18, 2017 at 5:38 AM, Simon Riggs wrote: > On 18 April 2017 at 13:12, Michael Paquier > wrote: > > On Tue, Apr 18, 2017 at 7:54 PM, Simon Riggs > wrote: > >> Yeh, this is better. Pushed. > > > > I have been

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

We've hit a case where pass_down_bound() isn't pushing the row count limit from limit into sort. The issue is that we're getting a subquery scan node between the limit and the sort. The subquery is only doing column projection and has no quals or SRFs so it should be safe to push the limit into

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

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 typically used in

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

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 aligned format. I need add this to documentation (i have it in recent TODO) I

Re: [HACKERS] Passing values to a dynamic background worker

On Tue, Apr 18, 2017 at 12:34 PM, Peter Eisentraut < peter.eisentr...@2ndquadrant.com> wrote: > On 4/17/17 16:19, Keith Fiske wrote: > > I've reached a roadblock in that bgw_main_arg can only accept a single > > argument that must be passed by value for a dynamic bgw. I already > > worked around

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

Amit Kapila writes: > I have ended up doing something along the lines suggested by you (or > at least what I have understood from your e-mail). Basically, pass > the safe-param-ids list to parallel safety function and decide based > on that if Param node reference in

Re: [HACKERS] Quals not pushed down into lateral

On Thu, Apr 13, 2017 at 01:39:07PM -0700, Andres Freund wrote: > On 2017-04-13 16:34:12 -0400, Robert Haas wrote: > > On Thu, Mar 16, 2017 at 4:45 AM, Andres Freund wrote: > > > During citus development we noticed that restrictions aren't pushed down > > > into lateral

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

On 18/04/17 19:18, Tom Lane wrote: > Petr Jelinek writes: >> On 18/04/17 18:24, Peter Eisentraut wrote: >>> I don't see why we need to do that. It is showing the correct >>> information, isn't it? > >> It does, but it's also one of the things Tom complained about

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

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 is shared with EXPLAIN command. But this shared code is only related to

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

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

[HACKERS] SASL minor docs typo

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" -- Jaime Casanova www.2ndQuadrant.com

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

Andres Freund writes: > On 2017-04-17 19:26:11 -0400, Tom Lane wrote: >> If we are going to go down this road, I think it would be a good idea >> to try to provide a cursor position for the "can't accept a set" error >> message, because otherwise it will be really unclear

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

2017-04-18 12:06 GMT+02:00 Fabien COELHO : > > Hello Jan, > > It seems that the patch does not apply anymore on head due to changes in >>> psql non regression tests. Could you rebase? >>> >> >> This should work on current master (all test passed). >> > > Patch applies,

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

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 HORIGUCHI >> wrote: >>> >>> 3.

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

Petr Jelinek writes: > On 18/04/17 18:24, Peter Eisentraut wrote: >> I don't see why we need to do that. It is showing the correct >> information, isn't it? > It does, but it's also one of the things Tom complained about and I > think he is right in that at least

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

On 18/04/17 18:24, Peter Eisentraut wrote: > On 4/18/17 12:13, Petr Jelinek wrote: >> We can definitely easily detect that the bgworker is internal one by >> library_name equals 'postgres' so we can easily remove the usesysid and >> usename based on that. > > I don't see why we need to do that.

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

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 seemed >> unnecessary to have hashtable when it will be empty almost

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

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 people to use short bgw_names, which is a

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

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 HORIGUCHI > wrote: >> >> 3. >>> >>> ApplyLauncherWakeup() should be static function. >> >> Attached 003 patch fixes it (and

Re: [HACKERS] Passing values to a dynamic background worker

On 4/17/17 16:19, Keith Fiske wrote: > I've reached a roadblock in that bgw_main_arg can only accept a single > argument that must be passed by value for a dynamic bgw. I already > worked around this for passing the database name to the my existing use > of a bgw with doing partition maintenance

Re: [HACKERS] Logical replication and synchronous replication

On Tue, Apr 18, 2017 at 9:05 PM, Craig Ringer wrote: > On 18 April 2017 at 18:55, Masahiko Sawada wrote: >> Hi, >> >> As doc of logical decoding said as a note[1], logical replication can >> support the synchronous replication with some restriction.

Re: [HACKERS] Logical replication launcher uses wal_retrieve_retry_interval

On 4/18/17 12:00, Petr Jelinek wrote: > As for apply_worker_launch_interval, I think we want different > name so that it can be used for tablesync rate limiting as well. But that's a mechanism we don't have yet, so maybe we should design that when we get there? -- Peter Eisentraut

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

On 4/18/17 12:13, Petr Jelinek wrote: > We can definitely easily detect that the bgworker is internal one by > library_name equals 'postgres' so we can easily remove the usesysid and > usename based on that. I don't see why we need to do that. It is showing the correct information, isn't it? >

Re: [HACKERS] scram and \password

On 18 April 2017 at 09:25, Heikki Linnakangas wrote: > On 04/18/2017 11:15 AM, Simon Riggs wrote: >> >> As a potential open item, if we treat "md5" as ">= md5" >> should we not also treat "password" as ">=password"? >> >> It seems strange that we still support "password" and yet

[HACKERS] logical replication fixes

Hi, While inspecting the logical replication code, I found a bug that could pick the wrong remote relation if they have the same name but different schemas. Also, I did some spelling/cosmetic changes and fixed an oversight in the ALTER SUBSCRIPTION documentation. Patches attached. -- Euler

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

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 seemed > unnecessary to have hashtable when it will be empty almost always but > there is no need to have both hashtable

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

On Tue, Apr 18, 2017 at 11:22 PM, Peter Eisentraut wrote: > On 4/13/17 06:23, Masahiko Sawada wrote: >> Attached the latest patch. It didn't actually necessary to change >> GetSubscriptionNotReadyRelations. I just changed the logic refreshing >> the sync table

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

On 16/04/17 22:27, Petr Jelinek wrote: > On 16/04/17 18:47, Tom Lane wrote: >> Craig Ringer writes: >>> On 12 April 2017 at 13:34, Kuntal Ghosh wrote: For backend_type=background worker, application_name shows the name of the

[HACKERS] dtrace probes

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 depending on the call site, as seen in probes.txt file. A fix is to explicit cast 'mode' to

Re: [HACKERS] Logical replication launcher uses wal_retrieve_retry_interval

On 18/04/17 16:24, Peter Eisentraut wrote: > On 4/16/17 22:40, Masahiko Sawada wrote: >> Attached two patches add new GUCs apply_worker_timeout and >> apply_worker_launch_interval which are used instead of >> wal_receiver_timeout and wal_retrieve_retry_timeout. These new >> parameters are not

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

On 18/04/17 16:22, Peter Eisentraut wrote: > On 4/13/17 06:23, Masahiko Sawada wrote: >> Attached the latest patch. It didn't actually necessary to change >> GetSubscriptionNotReadyRelations. I just changed the logic refreshing >> the sync table state list. > > I think this was the right

Re: [HACKERS] identity columns

On 4/18/17 02:07, 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] identity columns

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 > decided to explicitly write "[NO] CACHE" in

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

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 typically used in cameras and phones), not SSD. > Saying it's slow is an understatement. It's

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

On 4/15/17 12:56 PM, Robert Haas wrote: > On Fri, Apr 14, 2017 at 6:52 PM, Tom Lane wrote: >> Peter Eisentraut writes: >>> If we're talking about making things easier to understand, wouldn't a >>> random user rather know what a WAL "location"

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

Tom Lane wrote: > Michael Paquier writes: > > That's the point I am trying to make upthread: slow buildfarm animals > > should have minimal impact on core code modifications. We could for > > example have one environment variable that lists all the parameters to > >

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

Michael Paquier writes: > That's the point I am trying to make upthread: slow buildfarm animals > should have minimal impact on core code modifications. We could for > example have one environment variable that lists all the parameters to > modify in a single string and

Re: [HACKERS] scram and \password

On 04/18/2017 08:44 AM, Noah Misch wrote: On Tue, Apr 11, 2017 at 10:07:12PM +0300, Heikki Linnakangas wrote: Thanks! I've been busy on the other thread on future-proofing the protocol with negotiating the SASL mechanism, I'll come back to this once we get that settled. By the end of the week,

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

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 is shared with EXPLAIN command. But this shared code is only related to quals, properties, children, subPlans and few

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

On Mon, Apr 17, 2017 at 10:54 AM, Tom Lane wrote: > Amit Kapila writes: >> On Sun, Apr 16, 2017 at 9:30 PM, Tom Lane wrote: >>> FYI, I have this on my to-look-at list, and expect to fix it before Robert >>> returns from vacation.

Re: [HACKERS] Logical replication launcher uses wal_retrieve_retry_interval

On 4/16/17 22:40, Masahiko Sawada wrote: > Attached two patches add new GUCs apply_worker_timeout and > apply_worker_launch_interval which are used instead of > wal_receiver_timeout and wal_retrieve_retry_timeout. These new > parameters are not settable at worker-level so far. Under what

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

On 4/13/17 06:23, Masahiko Sawada wrote: > Attached the latest patch. It didn't actually necessary to change > GetSubscriptionNotReadyRelations. I just changed the logic refreshing > the sync table state list. I think this was the right direction, but then I got worried about having a loop within

Re: [HACKERS] Passing values to a dynamic background worker

On Tue, Apr 18, 2017 at 5:40 AM, Amit Langote wrote: > On 2017/04/18 18:12, Kyotaro HORIGUCHI wrote: > > At Mon, 17 Apr 2017 16:19:13 -0400, Keith Fiske wrote: > >> So after reading a recent thread on the steep learning curve for PG > >> internals [1], I figured

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

On 04/18/2017 08:59 AM, Michael Paquier wrote: >> Lets's say we have a bunch of possible environment settings with names >> that all begin with "PG_TAP_" PostgresNode.pm could check for the >> existence of these and take action accordingly, and you could set them >> on a buildfarm animal in the

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

Hi! On 17.04.2017 15:09, Remi Colinet wrote: Hello, I've implemented a new command named PROGRESS to monitor progression of long running SQL queries in a backend process. Use case === A use case is shown in the below example based on a table named t_10m with 10 millions rows. The table

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

On Tue, Apr 18, 2017 at 9:35 PM, Andrew Dunstan wrote: > > > On 04/18/2017 08:23 AM, Michael Paquier wrote: >> On Tue, Apr 18, 2017 at 9:13 PM, Andrew Dunstan >> wrote: >>> Yeah, but the way you have done it could also to lead to

Re: [HACKERS] Failed recovery with new faster 2PC code

On 18 April 2017 at 13:12, Michael Paquier wrote: > On Tue, Apr 18, 2017 at 7:54 PM, Simon Riggs wrote: >> Yeh, this is better. Pushed. > > I have been outraced on this one, the error is obvious once you see it ;) Didn't realise you were working

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

On 04/18/2017 08:23 AM, Michael Paquier wrote: > On Tue, Apr 18, 2017 at 9:13 PM, Andrew Dunstan > wrote: >> Yeah, but the way you have done it could also to lead to errors unless >> you're very careful, as I found on axolotl (which died recently, >>

Re: [HACKERS] On How To Shorten the Steep Learning Curve Towards PG Hacking...

On 04/18/2017 03:54 AM, Craig Ringer wrote: >> But almost nothing about The Internals of PostgreSQL: > Not surprising. They'd go out of date fast, be a huge effort to write > and maintain, and sell poorly given the small audience. > > Print books probably aren't the way forward here. > Agreed,

Re: [HACKERS] On How To Shorten the Steep Learning Curve Towards PG Hacking...

On 04/18/2017 03:41 AM, Kang Yuzhe wrote: > > > But almost nothing about The Internals of PostgreSQL: > 1. The Internals of PostgreSQL: > http://www.interdb.jp/pg/index.html translated from Japanese Book > 2. PostgreSQL数据库内核分析(Chinese) Book on the Internals of PostgreSQL: > 3. PG Docs/site > 4.

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

On Tue, Apr 18, 2017 at 9:13 PM, Andrew Dunstan wrote: > Yeah, but the way you have done it could also to lead to errors unless > you're very careful, as I found on axolotl (which died recently, > unfortunately). There I had to set the stats_temp directory to a >

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

On 04/18/2017 03:07 AM, Michael Paquier wrote: > Hi all, > > Some of you may have noticed that hamster is heavily red on the > buildfarm. I have done a bit of investigation, and I am able to > reproduce the failure manually. But actually after looking at the logs > the error has obviously showed

Re: [HACKERS] Failed recovery with new faster 2PC code

On Tue, Apr 18, 2017 at 7:54 PM, Simon Riggs wrote: > Yeh, this is better. Pushed. I have been outraced on this one, the error is obvious once you see it ;) Thanks for the investigation and the fix! I have spent a couple of hours reviewing the interactions between the

Re: [HACKERS] Logical replication and synchronous replication

On 18 April 2017 at 18:55, Masahiko Sawada wrote: > Hi, > > As doc of logical decoding said as a note[1], logical replication can > support the synchronous replication with some restriction. But In > addition to this, IIUC in logical replication decoded data is sent to >

Re: [HACKERS] SCRAM authentication, take three

On Tue, Apr 18, 2017 at 1:52 PM, Heikki Linnakangas wrote: > On 04/14/2017 10:33 PM, Peter Eisentraut wrote: > >> On 4/11/17 01:10, Heikki Linnakangas wrote: >> >>> That question won't arise in practice. Firstly, if the server can do >>> scram-sha-256-plus, it presumably can

Re: [HACKERS] SCRAM authentication, take three

On 04/14/2017 10:33 PM, Peter Eisentraut wrote: On 4/11/17 01:10, Heikki Linnakangas wrote: That question won't arise in practice. Firstly, if the server can do scram-sha-256-plus, it presumably can also do scram-sha-512-plus. Unless there's a change in the way the channel binding works, such

[HACKERS] Logical replication ApplyContext bloat

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 subscription worker will occupy more than 10G of

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

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 partitioned index. I could to change the control flow in partitioned index creation

[HACKERS] Logical replication and synchronous replication

Hi, As doc of logical decoding said as a note[1], logical replication can support the synchronous replication with some restriction. But In addition to this, IIUC in logical replication decoded data is sent to subscribers only when the commit WAL record is decoded (calls ReorderBufferCommit) . It

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

On Wed, Apr 5, 2017 at 8:39 AM, Robert Haas wrote: > On Tue, Apr 4, 2017 at 10:22 AM, Ashutosh Bapat > wrote: >> Yes, I agree. For an inner join, the partition key types need to "shrink" >> and for outer join they need to be "widened". I

Re: [HACKERS] Failed recovery with new faster 2PC code

On 18 April 2017 at 09:57, Nikhil Sontakke wrote: > Please find attached a second version of my bug fix which is stylistically > better and clearer than the first one. Yeh, this is better. Pushed. The bug was that the loop set gxact to be the last entry in the array,

Re: [HACKERS] PANIC in pg_commit_ts slru after crashes

On Tue, Apr 18, 2017 at 7:05 PM, Simon Riggs wrote: > I've added a recheck in ProcessTwoPhaseBuffer() after we acquire the lock. > > If its worth acquiring the lock its worth checking we don't have a race. I see. No objections to that. -- Michael -- Sent via

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

On Tue, Apr 18, 2017 at 4:15 PM, Andres Freund wrote: > Hi, > > On 2017-04-18 16:07:38 +0900, Michael Paquier wrote: >> Some of you may have noticed that hamster is heavily red on the >> buildfarm. I have done a bit of investigation, and I am able to >> reproduce the failure

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

Hi, On 2017/04/17 23:00, Maksim Milyutin wrote: > On 10.04.2017 14:20, Robert Haas wrote: >> On Tue, Apr 4, 2017 at 12:10 PM, Maksim Milyutin >> wrote: >>> 1. I have added a new relkind for local indexes named RELKIND_LOCAL_INDEX >>> (literal 'l'). >> >> Seems like it

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

Hello Jan, It seems that the patch does not apply anymore on head due to changes in psql non regression tests. Could you rebase? This should work on current master (all test passed). Patch applies, compiles and make check is ok. There are different flavour of markdown, maybe you should

Re: [HACKERS] PANIC in pg_commit_ts slru after crashes

On 18 April 2017 at 09:51, Simon Riggs wrote: > On 17 April 2017 at 16:33, Jeff Janes wrote: >> On Sun, Apr 16, 2017 at 6:59 PM, Michael Paquier >> wrote: >>> >>> >>> >>> Jeff, does this patch make the situation better? The

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

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 3:04 AM, Fujii Masao

Re: [HACKERS] Comments not allowed on partitioned table columns

On 2017/04/18 18:45, Simon Riggs wrote: > On 18 April 2017 at 06:57, Amit Langote wrote: >> On 2017/04/18 14:50, Amit Langote wrote: >>> Attached patch fixes the oversight that COMMENT ON COLUMN is not allowed >>> on partitioned tables columns. >> >> Forgot to

Re: [HACKERS] Comments not allowed on partitioned table columns

On 18 April 2017 at 06:57, Amit Langote wrote: > On 2017/04/18 14:50, Amit Langote wrote: >> Attached patch fixes the oversight that COMMENT ON COLUMN is not allowed >> on partitioned tables columns. > > Forgot to mention that I added this to the open items list.

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

At Tue, 18 Apr 2017 14:58:50 +0900, Masahiko Sawada wrote in > On Tue, Apr 18, 2017 at 3:04 AM, Fujii Masao wrote: > > On Wed, Apr 12, 2017 at 2:36 AM, Masahiko Sawada

Re: [HACKERS] Passing values to a dynamic background worker

On 2017/04/18 18:12, Kyotaro HORIGUCHI wrote: > At Mon, 17 Apr 2017 16:19:13 -0400, Keith Fiske wrote: >> So after reading a recent thread on the steep learning curve for PG >> internals [1], I figured I'd share where I've gotten stuck with this in a >> new thread vs hijacking that one. >> >> One

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

Tom Lane writes: > Andres Freund writes: >> On 2017-04-17 17:49:54 +0100, Dagfinn Ilmari Mannsåker wrote: >>> I threw Devel::NYTProf at it and picked some more low-hanging fruit. > >> I'm a bit doubtful about improving the performance of genbki at the

Re: [HACKERS] Passing values to a dynamic background worker

Hello, At Mon, 17 Apr 2017 16:19:13 -0400, Keith Fiske wrote in > So after reading a recent thread on the steep learning curve for PG > internals [1], I figured I'd share where I've gotten stuck with this in

Re: [HACKERS] Failed recovery with new faster 2PC code

Please find attached a second version of my bug fix which is stylistically better and clearer than the first one. Regards, Nikhils On 18 April 2017 at 13:47, Nikhil Sontakke wrote: > Hi, > > There was a bug in the redo 2PC remove code path. Because of which, > autovac

Re: [HACKERS] CREATE TRIGGER document typo

On 04/17/2017 12:09 PM, Yugo Nagata wrote: Hi, Attached is a patch fixing simple typos in the CREATE TRIGGER document. Applied, thanks! - Heikki -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription:

Re: [HACKERS] On How To Shorten the Steep Learning Curve Towards PG Hacking...

Hello Amit, Thanks gain for being patient with me. YES, I am working with the PostgreSQL source git repository but I don't think I updated my local forked/cloned branch. I am also working on standalone PG 9.6.2 source code as well. I will try to fetch/pull the PG master content to my

Re: [HACKERS] PANIC in pg_commit_ts slru after crashes

On 17 April 2017 at 16:33, Jeff Janes wrote: > On Sun, Apr 16, 2017 at 6:59 PM, Michael Paquier > wrote: >> >> >> >> Jeff, does this patch make the situation better? The fix is rather >> simple as it just makes sure that the next XID never gets

Re: [HACKERS] On How To Shorten the Steep Learning Curve Towards PG Hacking...

Thanks Craig for teaching me a lot of things. I am just learning a lot why PG hacking/development is the way it is. Regarding interest and enthusiasm, no problem. Whats is lacking is the skill-sets and I believe having interest and enthusiasm and with your support, we will expand PG

Re: [HACKERS] scram and \password

On 04/18/2017 11:15 AM, Simon Riggs wrote: As a potential open item, if we treat "md5" as ">= md5" should we not also treat "password" as ">=password"? It seems strange that we still support "password" and yet tell everyonenot to use it. I'd like PG10 to be the version where I don't have to

Re: [HACKERS] On How To Shorten the Steep Learning Curve Towards PG Hacking...

Hi, On 2017/04/18 16:54, Kang Yuzhe wrote: > Thanks Amit for taking your time and pointing to some useful stuff on the > Internals of PostgreSQL. > > > One thing I have learned is that PG community is not as hostile/harsh as I > imagined to newbies. Rather, its the reverse. > I am feeling at

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

On Fri, Apr 14, 2017 at 9:21 PM, Jaime Casanova wrote: > > > Hi Pavan, > > I run a test on current warm patchset, i used pgbench with a scale of > 20 and a fillfactor of 90 and then start the pgbench run with 6 > clients in parallel i also run sqlsmith on it. > >

  1   2   >