Re: [HACKERS] WIP: long transactions on hot standby feedback replica / proof of concept

2017-11-05 Thread Masahiko Sawada
On Sat, Nov 4, 2017 at 7:04 AM, Alexander Korotkov wrote: > On Wed, Nov 1, 2017 at 5:55 AM, Masahiko Sawada > wrote: >> >> On Tue, Oct 31, 2017 at 6:17 PM, Alexander Korotkov >> wrote: >> > On Tue, Oct 31, 2017 at 5:16

Re: [HACKERS] WIP: long transactions on hot standby feedback replica / proof of concept

2017-11-05 Thread Robert Haas
On Fri, Nov 3, 2017 at 5:57 PM, Alexander Korotkov wrote: > On Thu, Nov 2, 2017 at 5:56 AM, Robert Haas wrote: >> > I can propose following alternative approach: teach read-only queries on >> > hot >> > standby to tolerate concurrent relation

Re: [HACKERS] WIP: long transactions on hot standby feedback replica / proof of concept

2017-11-03 Thread Alexander Korotkov
On Wed, Nov 1, 2017 at 5:55 AM, Masahiko Sawada wrote: > On Tue, Oct 31, 2017 at 6:17 PM, Alexander Korotkov > wrote: > > On Tue, Oct 31, 2017 at 5:16 AM, Masahiko Sawada > > wrote: > >> > >> On Mon, Oct 30, 2017 at 10:16

Re: [HACKERS] WIP: long transactions on hot standby feedback replica / proof of concept

2017-11-03 Thread Alexander Korotkov
On Thu, Nov 2, 2017 at 5:56 AM, Robert Haas wrote: > On Tue, Oct 31, 2017 at 2:47 PM, Alexander Korotkov > wrote: > > However, from user prospective of view, current behavior of > > hot_standby_feedback is just broken, because it both increases

Re: [HACKERS] WIP: long transactions on hot standby feedback replica / proof of concept

2017-11-01 Thread Robert Haas
On Tue, Oct 31, 2017 at 2:47 PM, Alexander Korotkov wrote: > However, from user prospective of view, current behavior of > hot_standby_feedback is just broken, because it both increases bloat and > doesn't guarantee that read-only query on standby wouldn't be cancelled

Re: [HACKERS] WIP: long transactions on hot standby feedback replica / proof of concept

2017-10-31 Thread Masahiko Sawada
On Tue, Oct 31, 2017 at 6:17 PM, Alexander Korotkov wrote: > On Tue, Oct 31, 2017 at 5:16 AM, Masahiko Sawada > wrote: >> >> On Mon, Oct 30, 2017 at 10:16 PM, Robert Haas >> wrote: >> > On Tue, Oct 24, 2017 at 1:26 PM,

Re: [HACKERS] WIP: long transactions on hot standby feedback replica / proof of concept

2017-10-31 Thread Alexander Korotkov
On Tue, Oct 31, 2017 at 5:16 AM, Masahiko Sawada wrote: > On Mon, Oct 30, 2017 at 10:16 PM, Robert Haas > wrote: > > On Tue, Oct 24, 2017 at 1:26 PM, Ivan Kartyshov > > wrote: > >> Hello. I made some bugfixes and rewrite

Re: [HACKERS] WIP: long transactions on hot standby feedback replica / proof of concept

2017-10-30 Thread Masahiko Sawada
On Mon, Oct 30, 2017 at 10:16 PM, Robert Haas wrote: > On Tue, Oct 24, 2017 at 1:26 PM, Ivan Kartyshov > wrote: >> Hello. I made some bugfixes and rewrite the patch. > > I don't think it's a good idea to deliberately leave the state of the >

Re: [HACKERS] WIP: long transactions on hot standby feedback replica / proof of concept

2017-10-30 Thread Robert Haas
On Tue, Oct 24, 2017 at 1:26 PM, Ivan Kartyshov wrote: > Hello. I made some bugfixes and rewrite the patch. I don't think it's a good idea to deliberately leave the state of the standby different from the state of the master on the theory that it won't matter. I

Re: [HACKERS] WIP: long transactions on hot standby feedback replica / proof of concept

2017-10-24 Thread Alexander Korotkov
On Tue, Oct 24, 2017 at 10:56 AM, Ivan Kartyshov wrote: > Hello. I made some bugfixes and rewrite the patch. > > Simon Riggs писал 2017-09-05 14:44: > >> As Alexander says, simply skipping truncation if standby is busy isn't >> a great plan. >> >> If we defer an

Re: [HACKERS] WIP: long transactions on hot standby feedback replica / proof of concept

2017-10-24 Thread Ivan Kartyshov
Hello. I made some bugfixes and rewrite the patch. Simon Riggs писал 2017-09-05 14:44: As Alexander says, simply skipping truncation if standby is busy isn't a great plan. If we defer an action on standby replay, when and who will we apply it? What happens if the standby is shutdown or crashes

Re: [HACKERS] WIP: long transactions on hot standby feedback replica / proof of concept

2017-09-15 Thread i . kartyshov
Alexander Korotkov писал 2017-09-05 00:33: I've following comments on this patch: 1) You shouldn't use ">=" to compare xids. You should use TransactionIdFollowsOrEquals() function which handles transaction id wraparound correctly. I fixed it and as an additional I add GUC parameter that could

Re: [HACKERS] WIP: long transactions on hot standby feedback replica / proof of concept

2017-09-05 Thread Simon Riggs
On 4 September 2017 at 09:06, Alexander Korotkov wrote: > Aborting read-only query on standby because of vacuum on master seems to be > rather unexpected behaviour for user when hot standby feedback is on. > I think we should work on this problem for v11. Happy to

Re: [HACKERS] WIP: long transactions on hot standby feedback replica / proof of concept

2017-09-05 Thread Amit Kapila
On Tue, Sep 5, 2017 at 3:03 AM, Alexander Korotkov wrote: > On Mon, Sep 4, 2017 at 2:04 PM, wrote: >> >> Our clients complain about this issue and therefore I want to raise the >> discussion and suggest several solutions to this problem: >>

Re: [HACKERS] WIP: long transactions on hot standby feedback replica / proof of concept

2017-09-04 Thread Alexander Korotkov
On Mon, Sep 4, 2017 at 2:04 PM, wrote: > Our clients complain about this issue and therefore I want to raise the > discussion and suggest several solutions to this problem: > > I. Why does PG use Fatal when Error is enough to release lock that rises > lock conflict? >

Re: [HACKERS] WIP: long transactions on hot standby feedback replica / proof of concept

2017-09-04 Thread Alexander Korotkov
On Mon, Sep 4, 2017 at 4:51 PM, Alex Ignatov wrote: > In this situation this parameter (max_standby_streaming_delay) wont help > because if you have subsequent statement on standby (following info is from > documentation and from our experience ): Thus, if one query has

Re: [HACKERS] WIP: long transactions on hot standby feedback replica / proof of concept

2017-09-04 Thread Alex Ignatov
: long transactions on hot standby feedback replica / proof of concept On Mon, Sep 4, 2017 at 4:34 PM, <i.kartys...@postgrespro.ru> wrote: > Our clients complain about this issue and therefore I want to raise > the discussion and suggest several solutions to this problem: > > I. Wh

Re: [HACKERS] WIP: long transactions on hot standby feedback replica / proof of concept

2017-09-04 Thread Amit Kapila
On Mon, Sep 4, 2017 at 4:34 PM, wrote: > Our clients complain about this issue and therefore I want to raise the > discussion and suggest several solutions to this problem: > > I. Why does PG use Fatal when Error is enough to release lock that rises > lock conflict? >

[HACKERS] WIP: long transactions on hot standby feedback replica / proof of concept

2017-09-04 Thread i . kartyshov
Our clients complain about this issue and therefore I want to raise the discussion and suggest several solutions to this problem: I. Why does PG use Fatal when Error is enough to release lock that rises lock conflict? "If (RecoveryConflictPending && DoingCommandRead)" II. Do we really need