Re: logical changeset generation v6.8

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Andres Freund <andres(at)2ndquadrant(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 14:32:13
Message-ID: CA+TgmoY9PngFT1jD0xs57N0hWCffoQq_6ORhp9yehT86JZW48w@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Tue, Dec 17, 2013 at 7:48 AM, Andres Freund <andres(at)2ndquadrant(dot)com> wrote:
> 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...

pg_replslot? pg_replication_slot?

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2013-12-17 14:33:36 Re: Why no INSTEAD OF triggers on tables?
Previous Message Robert Haas 2013-12-17 14:30:54 Re: Changeset Extraction Interfaces