On Sun, Aug 21, 2011 at 3:14 AM, Magnus Hagander wrote:
> On Sun, Aug 21, 2011 at 08:23, Dondi Michael Stroma wrote:
>> So how would one "feed" incrementally copied partial WAL file data to
>> a standby
>
> Pad it with zeroes up to the normal segment limit (16Mb), and feed
> that. PostgreSQL will
On Sun, Aug 21, 2011 at 7:23 AM, Dondi Michael Stroma wrote:
> Hello,
>
> I have a question about log shipping. The documentation from
> PostgreSQL 8.4, in section 24.4.4, describes how to archive partial
> WAL files by using the pg_xlogfile_name_offset() function, which it
> calls "record-based l
On Sun, Aug 21, 2011 at 08:23, Dondi Michael Stroma wrote:
> Hello,
>
> I have a question about log shipping. The documentation from
> PostgreSQL 8.4, in section 24.4.4, describes how to archive partial
> WAL files by using the pg_xlogfile_name_offset() function, which it
> calls "record-based log
Alex Vinogradovs wrote:
Now you're pointing out obvious problems. My company deals with data
warehouses, we don't really need to delete/update stuff, only
insert/select ;) But seriously, those issues can be handled if one
doesn't just send plain tuples, but also includes the information
about wha
On Fri, 7 Dec 2007, Alex Vinogradovs wrote:
P.S. DDL is never a subject for replication (in normal RDBMS'es).
But it is passed along by PITR replication schemes like the record-based
log shipping that started this thread off; that's the main reason I
specifically pointed out that limitation
Now you're pointing out obvious problems. My company deals with data
warehouses, we don't really need to delete/update stuff, only
insert/select ;) But seriously, those issues can be handled if one
doesn't just send plain tuples, but also includes the information
about what kind of operations were
On Fri, 7 Dec 2007, Alex Vinogradovs wrote:
The documents highlights possible problems with _SQL_ query intercepts.
I am talking about the actual tuples... i.e. row data rather than the
SQL requests.
The first two issues that come to mind are how to deal with a) deletions,
and b) changes to D
The documents highlights possible problems with _SQL_ query intercepts.
I am talking about the actual tuples... i.e. row data rather than the
SQL requests. Please advise if you see any other problems with suggested
approach. Thanks!
Alex.
On Fri, 2007-12-07 at 22:44 -0500, Greg Smith wrote:
> O
On Fri, 7 Dec 2007, Alex Vinogradovs wrote:
How about writing a C function (invoked from a trigger) that will send
the serialized tuple using say UDP protocol (considering you're syncing
on a reliable LAN), and then a simple UDP-listening daemon that will
perform the insert into the slave one. I
How about writing a C function (invoked from a trigger) that will send
the serialized tuple using say UDP protocol (considering you're syncing
on a reliable LAN), and then a simple UDP-listening daemon that will
perform the insert into the slave one. If you have multiple slaves, can
use that with b
On Thu, 6 Dec 2007, SHARMILA JOTHIRAJAH wrote:
Have anyone implemented or tried record-based log shipping? If so is
there any other materials in the web other than the documentation (it
has very few details about this)
There is an implementation of that as part of the Skytools WalMgr code:
ht
Thanks
> Have anyone implemented or tried record-based log shipping?
> If so is there any other materials in the web other than the
> documentation (it has very few details about this)
>
>>I don't know exactly what you mean by "record-based log shipping", but
>>perhaps you're looking for somethin
On Thu, 2007-12-06 at 09:30 -0800, SHARMILA JOTHIRAJAH wrote:
> Hi,
> Have anyone implemented or tried record-based log shipping?
> If so is there any other materials in the web other than the
> documentation (it has very few details about this)
> Thanks
> sharmila
>
I don't know exactly what yo
13 matches
Mail list logo
