On Sat, Jan 25, 2014 at 5:25 PM, Andres Freund wrote:
>> I'm also wondering about
>> whether we've got the right naming here. AFAICT, it's not the case
>> that we're going to use the "catalog xmin" for catalogs and the "data
>> xmin" for non-catalogs. Rather, the "catalog xmin" is going to alway
On Sat, Jan 25, 2014 at 5:25 PM, Andres Freund wrote:
>> Looking over patch 0002, I see that there's code to allow a walsender
>> to create or drop a physical replication slot. Also, if we've
>> acquired a replication slot, there's code to update it, and code to
>> make sure we disconnect from it
Hi Robert, all,
On 2014-01-24 20:38:11 -0500, Robert Haas wrote:
> On Fri, Jan 24, 2014 at 12:49 PM, Andres Freund
> wrote:
> >> But this code is riddled with places where you track a catalog xmin
> >> and a data xmin separately. The only point of doing it that way is to
> >> support a division
On Fri, Jan 24, 2014 at 12:49 PM, Andres Freund wrote:
>> But this code is riddled with places where you track a catalog xmin
>> and a data xmin separately. The only point of doing it that way is to
>> support a division that hasn't been made yet.
>
> If you think it will make stuff more manageab
On 2014-01-24 12:10:50 -0500, Robert Haas wrote:
> > Unfortunately not. Inside the walsender there's currently no
> > LWLockReleaseAll() for ERRORs since commands aren't run inside a
> > transaction command...
> >
> > But maybe I should have fixed this by adding the release to
> > WalSndErrorCleanu
On Thu, Jan 23, 2014 at 6:32 PM, Andres Freund wrote:
>> I also wonder if we should use the
>> terminology "attach" instead of "acquire"; that pairs more naturally
>> with "release". Then the message, if we want more than an assert,
>> might be "this backend is already attached to a replication
Hi,
On 2014-01-23 16:04:10 -0500, Robert Haas wrote:
> Patch 0001:
>
> +errmsg("could not find free replication
> slot"),
>
> Suggest: all replication slots are in use
That sounds better indeed.
> + elog(ERROR, "cannot aquire a slot while another
> I wonder if it wouldn't be better to get rid of the subdirectories for
> the individual slots, and just have a file pg_replslot/$SLOTNAME, or
> not. I know there are later patches that need subdirectories for
> their own private data, but they could just create
> pg_replslot/$SLOTNAME.dir and pu
Patch 0001:
+errmsg("could not find free replication slot"),
Suggest: all replication slots are in use
+ elog(ERROR, "cannot aquire a slot while another slot
has been acquired");
Suggest: this backend has already acquired a replication slot
Or demo
