From: | Andrew Dunstan <andrew(at)dunslane(dot)net> |
---|---|
To: | Robert Haas <robertmhaas(at)gmail(dot)com>, Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> |
Cc: | Mark Dilger <mark(dot)dilger(at)enterprisedb(dot)com>, Jeff Davis <pgsql(at)j-davis(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Non-superuser subscription owners |
Date: | 2021-12-10 15:20:02 |
Message-ID: | 410c39ec-efd2-cb5f-8590-33d4fc0302d3@dunslane.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 12/10/21 09:09, Robert Haas wrote:
> On Thu, Dec 9, 2021 at 11:15 PM Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> wrote:
>> Yeah, to me also (b) sounds better than (a). However, a few points
>> that we might want to consider in that regard are as follows: 1.
>> locking the subscription for each transaction will add new blocking
>> areas considering we acquire AccessExclusiveLock to change any
>> property of subscription. But as Alter Subscription won't be that
>> frequent operation it might be acceptable.
> The problem isn't the cost of the locks taken by ALTER SUBSCRIPTION.
> It's the cost of locking and unlocking the relation for every
> transaction we apply. Suppose it's a pgbench-type workload with a
> single UPDATE per transaction. You've just limited the maximum
> possible apply speed to about, I think, 30,000 transactions per second
> no matter how many parallel workers you use, because that's how fast
> the lock manager is (or was, unless newer hardware or newer PG
> versions have changed things in a way I don't know about). That seems
> like a poor idea. There's nothing wrong with noticing changes at the
> next transaction boundary, as long as we document it. So why would we
> incur a possibly-significant performance cost to provide a stricter
> guarantee?
>
> I bet users wouldn't even like this behavior. It would mean that if
> you are replicating a long-running transaction, an ALTER SUBSCRIPTION
> command might block for a long time until replication of that
> transaction completes. I have a hard time understanding why anyone
> would consider that an improvement.
>
+1
I think noticing changes at the transaction boundary is perfectly
acceptable.
cheers
andrew
--
Andrew Dunstan
EDB: https://www.enterprisedb.com
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2021-12-10 15:20:26 | Re: track_io_timing default setting |
Previous Message | Guillaume Lelarge | 2021-12-10 14:40:50 | Probable memory leak with ECPG and AIX |