> 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.
In response to
pgsql-hackers by date
|Next:||From: Alex Hunsaker||Date: 2010-02-26 20:02:40|
|Subject: Re: Avoiding bad prepared-statement plans.|
|Previous:||From: Greg Stark||Date: 2010-02-26 19:59:57|
|Subject: Re: A thought on Index Organized Tables|