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
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
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
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
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
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,
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
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
>
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
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
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
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
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
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:
>>
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?
>
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
: 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
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?
>
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
19 matches
Mail list logo