On 7/24/21, 5:25 PM, "Andres Freund" wrote:
> First, from the user experience side of things, the issue is that this seems
> to propose violating read-your-own-writes. Within a single connection to a
> single node. Which imo is *far* worse than seeing writes that haven't yet been
> acknowledged as
> 25 июля 2021 г., в 05:29, Andres Freund написал(а):
>
> Hi,
>
> On 2021-07-24 15:53:15 +0500, Andrey Borodin wrote:
>> Are there any other problems with blocking cancels?
>
> Unless you have commandline access to the server, it's not hard to get
> into a situation where you can't change the
Hi,
On 2021-07-24 15:53:15 +0500, Andrey Borodin wrote:
> Are there any other problems with blocking cancels?
Unless you have commandline access to the server, it's not hard to get
into a situation where you can't change the configuration setting
because all connections are hanging, and you can't
Hi,
On 2021-07-22 21:17:56 +, Bossart, Nathan wrote:
> AFAICT there are a variety of ways that the aforementioned problem may
> occur:
> 1. Server restarts: As noted in the docs [2], "waiting transactions
> will be marked fully committed once the primary database
> recovers." I th
> 23 июля 2021 г., в 22:54, Bossart, Nathan написал(а):
>
> On 7/23/21, 4:33 AM, "Andrey Borodin" wrote:
>> Thanks for you interest in the topic. I think in the thread [0] we almost
>> agreed on general design.
>> The only left question is that we want to threat pg_ctl stop and kill
>> SIGT
23 июля 2021 г., в 22:54, Bossart, Nathan написал(а):On 7/23/21, 4:33 AM, "Andrey Borodin" wrote:Thanks for you interest in the topic. I think in the thread [0] we almost agreed on general design.The only left question is that we want to threat pg_ctl stop and kill SIGTERM differently to pg_termi
On 7/23/21, 4:33 AM, "Andrey Borodin" wrote:
> Thanks for you interest in the topic. I think in the thread [0] we almost
> agreed on general design.
> The only left question is that we want to threat pg_ctl stop and kill SIGTERM
> differently to pg_terminate_backend().
I didn't get the idea tha
On 7/23/21, 4:23 AM, "Laurenz Albe" wrote:
> But that would mean that changes ostensibly rolled back (because the
> cancel request succeeded) will later turn out to be committed after all,
> just like it is now (only later). Where is the advantage?
The advantage is that I can cancel waits for sy
On 7/23/21, 3:58 AM, "Amit Kapila" wrote:
> On Fri, Jul 23, 2021 at 2:48 AM Bossart, Nathan wrote:
>> Instead of blocking query cancellations and backend terminations, I
>> think we should allow them to proceed, but we should keep the
>> transactions marked in-progress so they do not yet become v
Hi Nathan!
Thanks for you interest in the topic. I think in the thread [0] we almost
agreed on general design.
The only left question is that we want to threat pg_ctl stop and kill SIGTERM
differently to pg_terminate_backend().
> 23 июля 2021 г., в 02:17, Bossart, Nathan написал(а):
>
> Hi ha
On Thu, 2021-07-22 at 21:17 +, Bossart, Nathan wrote:
> As previously discussed [0], canceling synchronous replication waits
> can have the unfortunate side effect of making transactions visible on
> a primary server before they are replicated. A failover at this time
> would cause such transa
On Fri, Jul 23, 2021 at 2:48 AM Bossart, Nathan wrote:
>
> Hi hackers,
>
> As previously discussed [0], canceling synchronous replication waits
> can have the unfortunate side effect of making transactions visible on
> a primary server before they are replicated. A failover at this time
> would c
Hi hackers,
As previously discussed [0], canceling synchronous replication waits
can have the unfortunate side effect of making transactions visible on
a primary server before they are replicated. A failover at this time
would cause such transactions to be lost. The proposed solution in
the prev
13 matches
Mail list logo
