On Tue, Oct 15, 2024 at 9:23 PM Laurenz Albe
wrote:
> On Tue, 2024-10-15 at 16:27 -0700, Jacob Biesinger wrote:
> > *would you* expect to be able to stand up a `repeatable read` replica
> against a
> > `serializable` master? My expectation is that you'd simply change the
&
>
> Just out of curiosity, what’s the use case for this?
>
>
We use the read-only replica as a data source for analytics workflows. The
setup allows us to have fresh data without affecting performance of the
production environment.
Howdy!
I've been going back and forth with the GCP CloudSQL engineering team about
the feasibility of a particular setup, and I'm pinging the list here
hoping for a sanity check. They assure me that it's impossible and I think
they must be mistaken, but I have limited experience administrating my
>
> Any value in supplying a single insert statement a la (less back and forth
> perhaps?):
>
Yes, absolutely that would be better. This particular endpoint has some
ancient + crufty code backing it (migrated from a NoSQL DB with a
db-agnostic shim that we're slowly replacing). The old code likes
On Wed, Aug 28, 2024 at 5:39 AM Greg Sabino Mullane
wrote:
> On Tue, Aug 27, 2024 at 9:03 PM Jacob Biesinger
> wrote:
>
>> I'm scratching my head at a few rows in the root DB, where it seems the
>> corresponding tenant transaction rolled back, but the root D
Hi there!
We have a setup where, for compliance reasons, we hoist a portion of data
from several "tenant" databases into a "root" / common / untenanted DB.
Through the magic of postgres_fdw, row triggers, and distributed
transactions, we automatically hoist the needed columns into the untenanted
D
