From: | Andres Freund <andres(at)2ndquadrant(dot)com> |
---|---|
To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
Cc: | "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: logical changeset generation v6.8 |
Date: | 2013-12-17 12:48:05 |
Message-ID: | 20131217124805.GH6019@awork2.anarazel.de |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 2013-12-16 00:53:10 -0500, Robert Haas wrote:
> > Yes, I think we could mostly reuse it, we'd probably want to add a field
> > or two more (application_name, sync_prio?). I have been wondering
> > whether some of the code in replication/logical/logical.c shouldn't be
> > in replication/slot.c or similar. So far I've opted for leaving it in
> > its current place since it would have to change a bit for a more general
> > role.
>
> I strongly favor moving the slot-related code to someplace with "slot"
> in the name, and replication/slot.c seems about right. Even if we
> don't extend them to cover non-logical replication in this release,
> we'll probably do it eventually, and it'd be better if that didn't
> require moving large amounts of code between files.
Any opinion on the storage location of the slot files? It's currently
pg_llog/$slotname/state[.tmp]. It's a directory so we have a location
during logical decoding to spill data to...
Greetings,
Andres Freund
--
Andres Freund http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
From | Date | Subject | |
---|---|---|---|
Next Message | Bruce Momjian | 2013-12-17 14:10:21 | Re: BUG #8676: Bug Money JSON |
Previous Message | Simon Riggs | 2013-12-17 12:29:34 | Re: Optimize kernel readahead using buffer access strategy |