Re: Re: Hot Standby query cancellation and Streaming Replication integration - Mailing list pgsql-hackers

From Josh Berkus
Subject Re: Re: Hot Standby query cancellation and Streaming Replication integration
Date
Msg-id 4B8828C0.7030501@agliodbs.com
Whole thread Raw
In response to Re: Re: Hot Standby query cancellation and Streaming Replication integration  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Re: Hot Standby query cancellation and Streaming Replication integration  ("Joshua D. Drake" <jd@commandprompt.com>)
Re: Re: Hot Standby query cancellation and StreamingReplication integration  ("Joshua D. Drake" <jd@commandprompt.com>)
List pgsql-hackers
> I don't see a "substantial additional burden" there.  What I would
> imagine is needed is that the slave transmits a single number back
> --- its current oldest xmin --- and the walsender process publishes
> that number as its transaction xmin in its PGPROC entry on the master.

If the main purpose of the slave is long-running queries, though, this
could cause a lot of bloat on the master.  That's a special case, but a
reason why we would want to preserve the stop replication functionality.

> I don't doubt that this approach will have its own gotchas that we
> find as we get into it.  But it looks soluble.  I have no faith in
> either the correctness or the usability of the approach currently
> being pursued.

So, why not start working on it now, instead of arguing about it?  It'll
be easy to prove the approach once we have some test code.


pgsql-hackers by date:

Previous
From: Greg Stark
Date:
Subject: Re: A thought on Index Organized Tables
Next
From: Alex Hunsaker
Date:
Subject: Re: Avoiding bad prepared-statement plans.