Skip site navigation (1) Skip section navigation (2)

Re: Re: xReader, double-effort (was: Temporary tables under hot standby)

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: "Kevin Grittner" <Kevin(dot)Grittner(at)wicourts(dot)gov>
Cc: simon(at)2ndQuadrant(dot)com, andres(at)2ndQuadrant(dot)com, aakash(dot)bits(at)gmail(dot)com, josh(at)postgresql(dot)org, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Re: xReader, double-effort (was: Temporary tables under hot standby)
Date: 2012-04-28 15:43:09
Message-ID: 26875.1335627789@sss.pgh.pa.us (view raw or flat)
Thread:
Lists: pgsql-hackers
"Kevin Grittner" <Kevin(dot)Grittner(at)wicourts(dot)gov> writes:
> Tom Lane  wrote:
>> Simon Riggs  writes:
>>> Translating WAL is a very hard task.
>> No kidding. I would think it's impossible on its face.
 
> Well, the xReader approach (Aakash's GSoC project) is to serve as a
> proxy for a WAL stream going to a hot standby, to interpret each
> incoming WAL record by "cheating" and querying the HS before passing
> the WAL along, and then using sync rep to the HS regardless of
> whether the incoming stream is sync or async.  What reliability
> problem do you see with this approach?

Well, first off, it requires a replica that *is* a physical replica
(else it won't have the same table OIDs, for instance).  I'm not sure I
get the point of logical replication that requires a physical replica as
a prerequisite.

Next, it breaks immediately in the face of DDL:

	CREATE TABLE foo (f1 int);
	BEGIN;
	ALTER TABLE foo ALTER COLUMN f1 RENAME TO f2;
	INSERT INTO foo (f2) VALUES (1);
	COMMIT;

The standby is not going to think that the ALTER is committed, so it
will not report the right column name when it comes time to translate
the INSERT.  Actually, you can break it even more easily than that:

	CREATE TABLE bar AS SELECT ...

What will you do with the insertions executed by this CREATE?  They have
to be executed before the creation of table bar is committed.

Also, you'd need a query connection per database (at least, maybe one
per session if you were trying to track DDL effects), which seems rather
a lot of load on the HS slave.  That together with the requirement for
synchronous operation seems absolutely catastrophic from a performance
standpoint.

If you want to spend the summer building a toy, fine, but I don't see
this going anywhere for production purposes.  It would be enormously
more performant for the master to be emitting logical replication
records to start with, since it already has all the right names etc
at hand at basically no cost.

			regards, tom lane

In response to

Responses

pgsql-hackers by date

Next:From: Aakash GoelDate: 2012-04-28 16:08:49
Subject: Re: Re: xReader, double-effort (was: Temporary tables under hot standby)
Previous:From: Andrew DunstanDate: 2012-04-28 15:41:31
Subject: Re: enable_indexonly

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group