On Mon, Aug 25, 2014 at 4:06 PM, Heikki Linnakangas
wrote:
> I didn't understand this one. But it seems like the obvious solution is to
> not use the consumer's system identifier as the slot name. Or rename it
> afterwards.
You can't use the consumer's system identifier as the slot name,
because
On 08/25/2014 10:45 PM, Tom Lane wrote:
Heikki Linnakangas writes:
It would not need to have the capability to set the
system ID to a particular value, only a randomly assigned one (setting
it to a particular value could be added to pg_resetxlog, where other
dangerous options are).
I'm less c
On August 25, 2014 9:45:50 PM CEST, Tom Lane wrote:
>Heikki Linnakangas writes:
>> In summary, I think we want this feature in some form, but we'll
>somehow
>> need to be make the distinction to the dangerous pg_resetxlog usage.
>It
>> might be best, after all, to make this a separate utility,
Heikki Linnakangas writes:
> In summary, I think we want this feature in some form, but we'll somehow
> need to be make the distinction to the dangerous pg_resetxlog usage. It
> might be best, after all, to make this a separate utility,
> pg_resetsystemid.
That sounds fairly reasonable given y
On 06/18/2014 09:17 PM, Josh Berkus wrote:
On 06/18/2014 11:03 AM, Andres Freund wrote:
Well, all those actually do write to the xlog (to write a new
checkpoint, containing the updated control file). Since pg_resetxlog has
done all this pretty much since forever renaming it now seems to be a
big
On 18/07/14 13:18, Andres Freund wrote:
On 2014-07-18 13:08:24 +0200, Petr Jelinek wrote:
On 18/07/14 00:41, Andres Freund wrote:
Wouldn't it be better to use sscanf()? That should work with large
inputs across platforms.
Well, sscanf does not do much validation and silently truncates too bi
On 2014-07-18 13:08:24 +0200, Petr Jelinek wrote:
> On 18/07/14 00:41, Andres Freund wrote:
> >On 2014-06-27 00:51:02 +0200, Petr Jelinek wrote:
> >>{
> >>switch (c)
> >>{
> >>@@ -227,6 +229,33 @@ main(int argc, char *argv[])
> >>XLogFromFileN
On 18/07/14 00:41, Andres Freund wrote:
On 2014-06-27 00:51:02 +0200, Petr Jelinek wrote:
{
switch (c)
{
@@ -227,6 +229,33 @@ main(int argc, char *argv[])
XLogFromFileName(optarg, &minXlogTli,
&minXlogSegNo);
On 06/30/2014 09:46 AM, Alvaro Herrera wrote:
> If we only had bricks and mortar, I think we would have a tool to
> display and tweak pg_control separately from emptying pg_xlog, rather
> than this odd separation between pg_controldata and pg_resetxlog, each
> of which do a mixture of those things.
On 2014-07-18 00:41:05 +0200, Andres Freund wrote:
> On 2014-06-27 00:51:02 +0200, Petr Jelinek wrote:
> > - while ((c = getopt(argc, argv, "fl:m:no:O:x:e:")) != -1)
> > + while ((c = getopt(argc, argv, "fl:m:no:O:x:e:s::")) != -1)
>
> Why two :?
Obviously strike that, wanted to delete the pa
On 2014-06-27 00:51:02 +0200, Petr Jelinek wrote:
> - while ((c = getopt(argc, argv, "fl:m:no:O:x:e:")) != -1)
> + while ((c = getopt(argc, argv, "fl:m:no:O:x:e:s::")) != -1)
Why two :?
> {
> switch (c)
> {
> @@ -227,6 +229,33 @@ main(int argc, char *argv
On Tue, Jul 1, 2014 at 11:19 AM, Andres Freund wrote:
>> I am, however, kind of frustrated, still, that the pg_computemaxlsn
>> patch, which I thought was rather a good idea, was scuttled by the
>> essentially that same objection: let's not extend pg_resetxlog &
>> friends because people might use
Robert Haas wrote:
> On Mon, Jun 30, 2014 at 12:46 PM, Alvaro Herrera
> wrote:
> > I think it's pretty much a given that pg_resetxlog is a tool that can
> > have disastrous effects if used lightly. If people changes their sysid
> > wrongly, they're not any worse than if they change their multixac
On 2014-07-01 11:11:12 -0400, Robert Haas wrote:
> On Mon, Jun 30, 2014 at 12:46 PM, Alvaro Herrera
> wrote:
> > I think it's pretty much a given that pg_resetxlog is a tool that can
> > have disastrous effects if used lightly. If people changes their sysid
> > wrongly, they're not any worse than
On Mon, Jun 30, 2014 at 12:46 PM, Alvaro Herrera
wrote:
> I think it's pretty much a given that pg_resetxlog is a tool that can
> have disastrous effects if used lightly. If people changes their sysid
> wrongly, they're not any worse than if they change their multixact
> counters and start gettin
Andres Freund wrote:
> c) We already allow to set pretty much all aspects of the control file
>via resetxlog - there seems little point of not having the ability to
>change the system identifier.
I think it's pretty much a given that pg_resetxlog is a tool that can
have disastrous effects
On 2014-06-30 19:57:58 +0900, Fujii Masao wrote:
> On Sun, Jun 29, 2014 at 11:18 PM, Andres Freund
> wrote:
> > On 2014-06-29 19:44:21 +0530, Abhijit Menon-Sen wrote:
> >> At 2014-06-27 00:51:02 +0200, p...@2ndquadrant.com wrote:
> >> >
> >> > Also based on Alvaro's comment, I replaced the scanf
On Sun, Jun 29, 2014 at 11:18 PM, Andres Freund wrote:
> On 2014-06-29 19:44:21 +0530, Abhijit Menon-Sen wrote:
>> At 2014-06-27 00:51:02 +0200, p...@2ndquadrant.com wrote:
>> >
>> > Also based on Alvaro's comment, I replaced the scanf parsing code with
>> > strtoul(l) function.
>>
>> As far as I
On 2014-06-29 19:44:21 +0530, Abhijit Menon-Sen wrote:
> At 2014-06-27 00:51:02 +0200, p...@2ndquadrant.com wrote:
> >
> > Also based on Alvaro's comment, I replaced the scanf parsing code with
> > strtoul(l) function.
>
> As far as I can tell (from the thread and a quick look at the patch),
> you
At 2014-06-27 00:51:02 +0200, p...@2ndquadrant.com wrote:
>
> Also based on Alvaro's comment, I replaced the scanf parsing code with
> strtoul(l) function.
As far as I can tell (from the thread and a quick look at the patch),
your latest version of the patch addresses all the review comments.
Sho
On 26/06/14 19:57, Sawada Masahiko wrote:
$ pg_resetxlog -s0 data
Transaction log reset
$ pg_controldata data | grep "Database system identifier"
Database system identifier: 6029284919152642525
this patch dose not works fine with -s0.
Yes, this is a bug, 0 input should throw error,
Thank you for updating the patch.
I think that the following behaviour of pg_resetxlog is bug.
$ pg_controldata data | grep "Database system identifier"
Database system identifier: 6029284919152642525
--
$ pg_resetxlog -s0 -n data
Current pg_control values:
pg_control version number:
On 25/06/14 19:43, Sawada Masahiko wrote:
Hi,
I send you review comment about thie patch.
Hello, thanks.
--
$ pg_resetxlog -s -n data | grep "Database system identifier"
Database system identifier: 6028907917695471865
The -s option does not worksfine with -n option.
Fixed.
--
On Thu, Jun 26, 2014 at 2:43 AM, Sawada Masahiko
wrote:
> Hi,
>
> I send you review comment about thie patch.
>
> I found no error/warning with compling and installation.
> I have executed pg_resetxlog with some input pattern.
>
> $ initdb -D data -E UTF8 --no-locale
> $ pg_controldata data | gre
Hi,
I send you review comment about thie patch.
I found no error/warning with compling and installation.
I have executed pg_resetxlog with some input pattern.
$ initdb -D data -E UTF8 --no-locale
$ pg_controldata data | grep "Database system identifier"
Database system identifier: 6028
On 06/18/2014 11:03 AM, Andres Freund wrote:
> Well, all those actually do write to the xlog (to write a new
> checkpoint, containing the updated control file). Since pg_resetxlog has
> done all this pretty much since forever renaming it now seems to be a
> big hassle for users for pretty much no b
On 2014-06-18 10:59:59 -0700, Josh Berkus wrote:
> On 06/18/2014 10:48 AM, Abhijit Menon-Sen wrote:
> > At 2014-06-18 10:44:56 -0700, j...@agliodbs.com wrote:
> >>
> >> I'm unclear on why we would overload pg_resetxlog for this.
> >
> > Because pg_resetxlog already does something very similar, so
On 06/18/2014 10:48 AM, Abhijit Menon-Sen wrote:
> At 2014-06-18 10:44:56 -0700, j...@agliodbs.com wrote:
>>
>> I'm unclear on why we would overload pg_resetxlog for this.
>
> Because pg_resetxlog already does something very similar, so the patch
> is small. If it were independent, it would have
At 2014-06-18 10:44:56 -0700, j...@agliodbs.com wrote:
>
> I'm unclear on why we would overload pg_resetxlog for this.
Because pg_resetxlog already does something very similar, so the patch
is small. If it were independent, it would have to copy quite some code
from pg_resetxlog.
> Wouldn't it b
On 2014-06-18 10:44:56 -0700, Josh Berkus wrote:
> On 06/13/2014 05:31 PM, Petr Jelinek wrote:
> > Hello,
> >
> > attached is a simple patch which makes it possible to change the system
> > identifier of the cluster in pg_control. This is useful for
> > individualization of the instance that is st
Josh Berkus wrote:
> On 06/13/2014 05:31 PM, Petr Jelinek wrote:
> > Hello,
> >
> > attached is a simple patch which makes it possible to change the system
> > identifier of the cluster in pg_control. This is useful for
> > individualization of the instance that is started on top of data
> > direc
On 06/13/2014 05:31 PM, Petr Jelinek wrote:
> Hello,
>
> attached is a simple patch which makes it possible to change the system
> identifier of the cluster in pg_control. This is useful for
> individualization of the instance that is started on top of data
> directory produced by pg_basebackup -
On 2014-06-18 13:26:37 -0400, Robert Haas wrote:
> My vote is to hold off on this until we've talked about replication
> identifiers and other related topics in more depth.
I really don't understand this. We're *NOT* proposing this patch as an
underhanded way of preempting the discussion of whethe
On 18/06/14 19:26, Robert Haas wrote:
On Wed, Jun 18, 2014 at 12:54 PM, Andres Freund wrote:
I don't see how the proposed ability makes it more dangerous. It
*already* has the ability to reset the timelineid. That's the case where
users are much more likely to think about resetting it because t
On Wed, Jun 18, 2014 at 12:54 PM, Andres Freund wrote:
>> Well, I think it *does* make pg_resetxlog more dangerous; see previous
>> discussion of pg_computemaxlsn.
>
> Wasn't the thing around pg_computemaxlsn that there's actually no case
> where it could be used safely? And that experienced peopl
On 2014-06-18 18:54:05 +0200, Andres Freund wrote:
> On 2014-06-18 12:36:13 -0400, Robert Haas wrote:
> > Sure, but that only requires being able to reset the ID randomly, not
> > to a particular value.
>
> I can definitely see a point in a version of the option that generates
> the id randomly.
On 2014-06-18 12:36:13 -0400, Robert Haas wrote:
> On Tue, Jun 17, 2014 at 12:50 PM, Andres Freund
> wrote:
> >> >> I can clearly understand the utility of being able to reset the system
> >> >> ID to a new, randomly-generated system ID - but giving the user the
> >> >> ability to set a particula
On Tue, Jun 17, 2014 at 12:50 PM, Andres Freund wrote:
>> >> I can clearly understand the utility of being able to reset the system
>> >> ID to a new, randomly-generated system ID - but giving the user the
>> >> ability to set a particular value of their own choosing seems like a
>> >> pretty shar
On 2014-06-17 12:07:04 -0400, Robert Haas wrote:
> On Tue, Jun 17, 2014 at 10:33 AM, Petr Jelinek wrote:
> > On 17/06/14 16:18, Robert Haas wrote:
> >> On Fri, Jun 13, 2014 at 8:31 PM, Petr Jelinek
> >> wrote:
> >>> attached is a simple patch which makes it possible to change the system
> >>> ide
On Tue, Jun 17, 2014 at 10:33 AM, Petr Jelinek wrote:
> On 17/06/14 16:18, Robert Haas wrote:
>> On Fri, Jun 13, 2014 at 8:31 PM, Petr Jelinek
>> wrote:
>>> attached is a simple patch which makes it possible to change the system
>>> identifier of the cluster in pg_control. This is useful for
>>>
On 17/06/14 16:18, Robert Haas wrote:
On Fri, Jun 13, 2014 at 8:31 PM, Petr Jelinek wrote:
attached is a simple patch which makes it possible to change the system
identifier of the cluster in pg_control. This is useful for
individualization of the instance that is started on top of data directo
On Fri, Jun 13, 2014 at 8:31 PM, Petr Jelinek wrote:
> attached is a simple patch which makes it possible to change the system
> identifier of the cluster in pg_control. This is useful for
> individualization of the instance that is started on top of data directory
> produced by pg_basebackup - so
Hello,
attached is a simple patch which makes it possible to change the system
identifier of the cluster in pg_control. This is useful for
individualization of the instance that is started on top of data
directory produced by pg_basebackup - something that's helpful for
logical replication se
43 matches
Mail list logo
