Re: logical changeset generation v3 - Mailing list pgsql-hackers

From Andres Freund
Subject Re: logical changeset generation v3
Date
Msg-id 20121119085030.GA5653@awork2.anarazel.de
Whole thread Raw
In response to Re: logical changeset generation v3  (Michael Paquier <michael.paquier@gmail.com>)
Responses Re: logical changeset generation v3  (Michael Paquier <michael.paquier@gmail.com>)
Re: logical changeset generation v3  (Andres Freund <andres@2ndquadrant.com>)
List pgsql-hackers
Hi Michael,


On 2012-11-19 16:28:55 +0900, Michael Paquier wrote:
> I have been able to fetch your code (thanks Andrea!) and some it. For the
> time being I am spending some time reading the code and understanding the
> whole set of features you are trying to implement inside core, even if I
> got some background from what you presented at PGCon and from the hackers
> ML.

Cool.

> Btw, as a first approach, I tried to run the logical log receiver plugged
> on a postgres server, and I am not able to make it work.

> Well, I am using settings similar to yours.
> # Run master
> rm -r ~/bin/pgsql/master/
> initdb -D ~/bin/pgsql/master/
> echo "local replication $USER trust" >> ~/bin/pgsql/master/pg_hba.conf
> postgres -D ~/bin/pgsql/master \
>           -c wal_level=logical \
>           -c max_wal_senders=10 \
>           -c max_logical_slots=10 \
>           -c wal_keep_segments=100 \
>           -c log_line_prefix="[%p %x] "
> # Logical log receiver
> pg_receivellog -f $HOME/output.txt -d postgres -v
>
> After launching some SQLs, the logical receiver is stuck just after sending
> INIT_LOGICAL_REPLICATION, please see bt of process waiting:

Its waiting till it sees initial an initial xl_running_xacts record. The
easiest way to do that is manually issue a checkpoint. Sorry, should
have included that in the description.
Otherwise you can wait till the next routine checkpoint comes arround...

I plan to cause more xl_running_xacts record to be logged in the
future. I think the timing of those currently is non-optimal, you have
the same problem as here in normal streaming replication as well :(

> > -- wrapped in a transaction
> > BEGIN;
> > INSERT INTO replication_example(somedata, text) VALUES (1, 1);
> > UPDATE replication_example SET somedate = - somedata WHERE id = (SELECT
> > currval('replication_example_id_seq'));
> >
> In SET clause, the column name is *somedata* and not *somedate*

Crap. Sorry for that. I wrote the example in the mailclient and then
executed it and I seem to have forgot to put back some of the fixes...


> I am just looking at this patch and will provide some comments.
> By the way, you forgot the installation part of pg_receivellog, please see
> patch attached.

That actually was somewhat intended, I thought people wouldn't like the
name and I didn't want a binary thats going to be replaced anyway lying
arround ;)

Greetings,

Andres

-- Andres Freund                       http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training &
Services



pgsql-hackers by date:

Previous
From: "Albe Laurenz"
Date:
Subject: Re: Materialized views WIP patch
Next
From: Alexander Korotkov
Date:
Subject: Re: pg_trgm partial-match