On 5/3/12 2:54 PM, Josh Berkus wrote:
(2) If logical transactions had been implemented as additions to
> the WAL stream, and Slony was using that, do you think they would
> still have been usable for this recovery?
Quite possibly not.
The key advantage that I see in londiste/slony replicati
> That's an interesting point. Out of curiosity, how did the
> corruption originate?
We're still not sure. It appears to be in the system catalogs, though.
Note that the original master developed memory issues.
> It suggests a couple questions:
>
> (1) Was Slony running before the corrupti
Josh Berkus wrote:
>> One thing I wanted to mention is that non-binary replication has
>> an added advantage over binary from a DR standpoint: if
>> corruption occurs on a master it is more likely to make it into
>> your replicas thanks to full page writes. You might want to
>> consider that dep
> One thing I wanted to mention is that non-binary replication has an
> added advantage over binary from a DR standpoint: if corruption occurs
> on a master it is more likely to make it into your replicas thanks to
> full page writes. You might want to consider that depending on how
> sensitive yo
On 4/29/12 9:27 AM, Kevin Grittner wrote:
Maybe I can help with that by describing what the Wisconsin court
system does for circuit court data.
Thanks for the write-up, it was insightful.
One thing I wanted to mention is that non-binary replication has an added
advantage over binary from a DR
On Sun, Apr 29, 2012 at 11:29 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Sun, Apr 29, 2012 at 6:00 PM, Hannu Krosing wrote:
>>> So you basically need a large part of postgres for reliably making sense
>>> of WAL.
>
>> Agreed, but I think that's a problem we need to fix and not a
>> tolerabl
Robert Haas writes:
> On Sun, Apr 29, 2012 at 6:00 PM, Hannu Krosing wrote:
>> So you basically need a large part of postgres for reliably making sense
>> of WAL.
> Agreed, but I think that's a problem we need to fix and not a
> tolerable situation at all. If a user can create a type-output
> f
On Sun, Apr 29, 2012 at 6:00 PM, Hannu Krosing wrote:
>> I think the question we should be asking ourselves is not whether WAL
>> as it currently exists is adequate for logical replication, but rather
>> or not it could be made adequate.
>
> Agreed.
And of course I meant "but rather whether or no
On Sun, 2012-04-29 at 16:33 -0400, Robert Haas wrote:
> On Sat, Apr 28, 2012 at 11:06 AM, Tom Lane wrote:
> > Simon Riggs writes:
> >> Translating WAL is a very hard task.
> >
> > No kidding. I would think it's impossible on its face. Just for
> > starters, where will you get table and column n
On Sat, Apr 28, 2012 at 11:06 AM, Tom Lane wrote:
> Simon Riggs writes:
>> Translating WAL is a very hard task.
>
> No kidding. I would think it's impossible on its face. Just for
> starters, where will you get table and column names from? (Looking at
> the system catalogs is cheating, and wil
On Sun, Apr 29, 2012 at 7:36 PM, Kevin Grittner
wrote:
> Simon Riggs wrote:
>
>> Though it isn't a given that logical change records (LCRs) will
>> require more bandwidth than physical WAL.
>
> It would help if you could share a little more of what you have in
> mind. It's not yet clear to me wh
Simon Riggs wrote:
> Though it isn't a given that logical change records (LCRs) will
> require more bandwidth than physical WAL.
It would help if you could share a little more of what you have in
mind. It's not yet clear to me whether you're talking about adding
logical records to the WAL str
On Sun, Apr 29, 2012 at 3:27 PM, Kevin Grittner
wrote:
>> 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.
>
> Not when the consumers are across a WAN, a
Tom Lane wrote:
> "Kevin Grittner" writes:
>> 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
On Sat, Apr 28, 2012 at 4:43 PM, Tom Lane wrote:
> "Kevin Grittner" 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
>>
Hello Tom,
> I'm not sure I
> get the point of logical replication that requires a physical replica as
> a prerequisite.
> 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
"Kevin Grittner" 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 interpr
Tom Lane wrote:
> Simon Riggs writes:
>> Translating WAL is a very hard task.
>
> No kidding. I would think it's impossible on its face. Just for
> starters, where will you get table and column names from? (Looking
> at the system catalogs is cheating, and will not work reliably
> anyway.)
Wel
Simon Riggs writes:
> Translating WAL is a very hard task.
No kidding. I would think it's impossible on its face. Just for
starters, where will you get table and column names from? (Looking at
the system catalogs is cheating, and will not work reliably anyway.)
IMO, if we want non-physical re
Hello Andres,
>> The xReader design was based on the idea that it would be nice not
>> to cause load on the master machine, and that by proxying the WAL
>> stream to the HS, using synchronous replication style to write from
>> xReader to the HS, you could use the HS for a source for that data
>> w
> Aakash, when you get a chance, could you fill in the "inch-stones"
> from the GSoC proposal page onto the Wiki page?
Sure, http://wiki.postgresql.org/wiki/XReader updated.
On Sat, Apr 28, 2012 at 3:48 AM, Kevin Grittner wrote:
> Andres Freund wrote:
>
> > In the current, prototypal, state th
On Fri, Apr 27, 2012 at 11:18 PM, Kevin Grittner
wrote:
> Andres Freund wrote:
> I'm not convinced that I would rather see the logic fixed inside the
> master as opposed to being deployable on the master's machine, the
> slave machine, or even on its own machine in between.
There are use cases
Andres Freund wrote:
> Something like registering/deregistering also doesn't fit that
> well with the way walsender works as far as I understand it.
If you look at the diagrams on the xReader Wiki page, the lines
labeled "XLOG stream" are the ones using walsender/walreceiver. The
green arrows
Hi Kevin, Hi Aakash,
On Saturday, April 28, 2012 12:18:38 AM Kevin Grittner wrote:
> Andres Freund wrote:
> > In the current, prototypal, state there is one component thats
> > integrated into the server (because it needs information thats
> > only available there).
> The xReader design was based
Andres Freund wrote:
> In the current, prototypal, state there is one component thats
> integrated into the server (because it needs information thats
> only available there).
The xReader design was based on the idea that it would be nice not
to cause load on the master machine, and that by pr
On Friday, April 27, 2012 11:04:04 PM Kevin Grittner wrote:
> [replaced bad email address for Josh (which was my fault)]
>
> Aakash Goel wrote:
> > All, the wiki page is now up at
> >
> > http://wiki.postgresql.org/wiki/XReader.
>
> Note that the approach Aakash is taking doesn't involve chang
26 matches
Mail list logo
