Dne 17. 9. 2013 17:01 "Andres Freund" napsal(a):
>
> On 2013-09-17 10:57:46 -0400, Robert Haas wrote:
> > On Mon, Sep 16, 2013 at 1:25 AM, Satoshi Nagayasu
wrote:
> > > How about adding new system view with new function which returns
> > > a single pg_controldata value in text type, and using a c
On Tue, Sep 17, 2013 at 11:43 AM, Robert Haas wrote:
> On Tue, Sep 17, 2013 at 10:59 AM, Andres Freund
> wrote:
>> On 2013-09-17 10:57:46 -0400, Robert Haas wrote:
>>> On Mon, Sep 16, 2013 at 1:25 AM, Satoshi Nagayasu wrote:
>>> > How about adding new system view with new function which returns
On Tue, Sep 17, 2013 at 10:59 AM, Andres Freund wrote:
> On 2013-09-17 10:57:46 -0400, Robert Haas wrote:
>> On Mon, Sep 16, 2013 at 1:25 AM, Satoshi Nagayasu wrote:
>> > How about adding new system view with new function which returns
>> > a single pg_controldata value in text type, and using a
On Mon, Sep 16, 2013 at 1:25 AM, Satoshi Nagayasu wrote:
> How about adding new system view with new function which returns
> a single pg_controldata value in text type, and using a cast for
> each column in the view definition?
>
> CREATE VIEW pg_catalog.pg_controldata AS
> SELECT pg_controldat
On 2013-09-17 10:57:46 -0400, Robert Haas wrote:
> On Mon, Sep 16, 2013 at 1:25 AM, Satoshi Nagayasu wrote:
> > How about adding new system view with new function which returns
> > a single pg_controldata value in text type, and using a cast for
> > each column in the view definition?
> >
> > CREA
Hi,
I'm catching up with the discussion as a reviewer...
(2013/08/27 5:35), Tom Lane wrote:
> Andres Freund writes:
>> On 2013-08-26 10:10:54 -0700, Josh Berkus wrote:
>>> I'm going to reverse my vote, and vote against this patch. The reason
>>> why is that I think we should instead have a func
On 8/26/13 8:48 AM, Fujii Masao wrote:
I think it's also noteworthy that Slony and londiste both rely on the user
>>specifying node identifiers. They don't try to be magic about it. I think
>>there's 2 advantages there:
>>
>>- Code is simpler
>>- Users can choose a naming schema that makes sense
On 08/26/2013 01:50 PM, Andres Freund wrote:
> All the other variables are either already exposed, don't seem to be all
> that interesting or not necessary accurate for a running cluster.
>
> I'd vote for doing things piecemal here, otherwise it seems to be too
> likely that we never get anywhere.
On 2013-08-26 16:35:57 -0400, Tom Lane wrote:
> Andres Freund writes:
> > On 2013-08-26 10:10:54 -0700, Josh Berkus wrote:
> >> I'm going to reverse my vote, and vote against this patch. The reason
> >> why is that I think we should instead have a function:
> >>
> >> pg_controldata(parameter tex
Andres Freund writes:
> On 2013-08-26 10:10:54 -0700, Josh Berkus wrote:
>> I'm going to reverse my vote, and vote against this patch. The reason
>> why is that I think we should instead have a function:
>>
>> pg_controldata(parameter text)
>>
>> ... which would report *all* strings in pg_contr
On 2013-08-26 21:13:49 +0200, Dimitri Fontaine wrote:
> Andres Freund writes:
> > If anything but the proposed feature, it should be an SRF - passing in
> > text parameters isn't very discoverable. And I can't imagine where an
> > SRF would have too high overhead.
>
> The two existing extensions
Andres Freund writes:
> If anything but the proposed feature, it should be an SRF - passing in
> text parameters isn't very discoverable. And I can't imagine where an
> SRF would have too high overhead.
The two existing extensions doing that are SRFs, yes. One of them has
been made by our committ
Hi,
On 2013-08-26 10:10:54 -0700, Josh Berkus wrote:
> I think we've gotten a bit off the track of the proposed patch, which is
> designed to report the system_identifier string currently in
> pg_controldata, nothing more.
Agreed.
> I'm going to reverse my vote, and vote against this patch. The
All,
I think we've gotten a bit off the track of the proposed patch, which is
designed to report the system_identifier string currently in
pg_controldata, nothing more.
I'm going to reverse my vote, and vote against this patch. The reason
why is that I think we should instead have a function:
p
On Mon, Aug 26, 2013 at 1:12 PM, Michael Paquier
wrote:
> On Mon, Aug 26, 2013 at 7:47 AM, Jim Nasby wrote:
>> On 8/23/13 11:23 AM, Greg Stark wrote:
>>>
>>> This doesn't generate a unique id. You could back up a standby and restore
>>> it and point it at the original master and end up with two s
On 08/26/2013 12:47 AM, Jim Nasby wrote:
> On 8/23/13 11:23 AM, Greg Stark wrote:
>> This doesn't generate a unique id. You could back up a standby and
>> restore it and point it at the original master and end up with two
>> standbies with the same id.
Yeah, not as easy as I imagined. It will fix i
On Mon, Aug 26, 2013 at 7:47 AM, Jim Nasby wrote:
> On 8/23/13 11:23 AM, Greg Stark wrote:
>>
>> This doesn't generate a unique id. You could back up a standby and restore
>> it and point it at the original master and end up with two standbies with
>> the same id.
>
>
> If you want to enforce some
On 8/23/13 11:23 AM, Greg Stark wrote:
This doesn't generate a unique id. You could back up a standby and restore it
and point it at the original master and end up with two standbies with the same
id.
If you want to enforce something unique throughout a cluster, I think we're
stuck with havi
Christopher Browne writes:
> On Fri, Aug 23, 2013 at 3:10 AM, Fabien COELHO wrote:
>> Would it make sense for such identifiers be standard UUID
>> (http://en.wikipedia.org/wiki/UUID)?
> There is sense to this, sure.
That ship's already sailed, though. As was pointed out upthread, we don't
real
On Fri, Aug 23, 2013 at 3:10 AM, Fabien COELHO wrote:
>
>> After someone in IRC asked if there was an equivalent to MySQL's
>> server_id, it was noted that we do have a system identifier but it's not
>> very accessible.
>>
>> The attached patch implements a pg_system_identifier() function that
>>
This doesn't generate a unique id. You could back up a standby and restore
it and point it at the original master and end up with two standbies with
the same id.
On Fri, Aug 23, 2013 at 4:08 PM, Hannu Krosing wrote:
> On 08/22/2013 06:37 PM, Tom Lane wrote:
> > A
> > Do we have a reliable way of
On 08/22/2013 06:37 PM, Tom Lane wrote:
> A
> Do we have a reliable way of generating a unique identifier for each slave
> (independently of how that might be exposed)?
Probably we could just generate an unique UUID when we first detect
that we are replicating from the master with same UUID.
This
Vik Fearing writes:
>>> The attached patch implements a pg_system_identifier() function that
>>> exposes it.
>
> It's information about the server that's only accessible through
> pg_controldata. I don't know if that's justification enough, which is
> why I didn't add it to the commitfest yet.
W
After someone in IRC asked if there was an equivalent to MySQL's
server_id, it was noted that we do have a system identifier but it's not
very accessible.
The attached patch implements a pg_system_identifier() function that
exposes it.
Would it make sense for such identifiers be standard UUID
On 2013-08-22 12:37:36 -0400, Tom Lane wrote:
> Do we have a reliable way of generating a unique identifier for each slave
> (independently of how that might be exposed)?
I'd like one, but it's not easy. The best I can think of is to mash
together:
* system_identifier
* mac address of primary inte
Andres Freund writes:
> On 2013-08-22 12:20:19 -0400, Alvaro Herrera wrote:
>> We could split the value; make sure that the first, way, 96 bits are
>> identical in master and slaves (and change the code to only compare
>> those bits); but the last 32 bits are system specific and cannot appear
>> t
On 2013-08-22 12:20:19 -0400, Alvaro Herrera wrote:
> Andres Freund wrote:
> > On 2013-08-22 12:06:03 -0400, Tom Lane wrote:
>
> > > I agree that if we have a function named pg_system_identifier(), it ought
> > > to return the same value that pg_controldata prints under that name.
> > > But that d
On 2013-08-22 12:18:41 -0400, Bruce Momjian wrote:
> On Thu, Aug 22, 2013 at 06:18:39PM +0200, Andres Freund wrote:
> > But essentially we already have something like that by the combination
> > of system identifier and timeline id. Admittedly there's the weakness
> > that the timelineid can increa
Andres Freund wrote:
> On 2013-08-22 12:06:03 -0400, Tom Lane wrote:
> > I agree that if we have a function named pg_system_identifier(), it ought
> > to return the same value that pg_controldata prints under that name.
> > But that doesn't really answer any questions about how that value is
> > o
On Thu, Aug 22, 2013 at 06:18:39PM +0200, Andres Freund wrote:
> But essentially we already have something like that by the combination
> of system identifier and timeline id. Admittedly there's the weakness
> that the timelineid can increase the same on several machines in the
> cluster but that's
On 2013-08-22 12:06:03 -0400, Tom Lane wrote:
> Andres Freund writes:
> > On 2013-08-22 08:45:38 -0700, Josh Berkus wrote:
> >> However, given that the value is the same for all servers in a
> >> replication set, are we sure we want to call it system_identifier? Is
> >> there a better name?
>
>
Andres Freund writes:
> On 2013-08-22 08:45:38 -0700, Josh Berkus wrote:
>> However, given that the value is the same for all servers in a
>> replication set, are we sure we want to call it system_identifier? Is
>> there a better name?
> Given it's been named that and visible via pg_controldata
Josh Berkus writes:
> Vik's feature would be useful for detecting an accidental split in a
> replication cluster. That is, it would be another tool for detecting if
> you've made a mistake and created two masters. So +1 from me.
We don't change the ID when promoting a slave to master, do we?
So
On 2013-08-22 08:45:38 -0700, Josh Berkus wrote:
> All,
>
> Vik's feature would be useful for detecting an accidental split in a
> replication cluster. That is, it would be another tool for detecting if
> you've made a mistake and created two masters. So +1 from me.
>
> It will also be useful f
bricklen writes:
> On Thu, Aug 22, 2013 at 6:42 AM, Andres Freund wrote:
>> FWIW I've wished for that function repeatedly. Mostly just to make sure
>> I am actually connected to the same "network" of replicas and not some
>> other.
>> It's also useful if you're providing support for a limited numb
All,
Vik's feature would be useful for detecting an accidental split in a
replication cluster. That is, it would be another tool for detecting if
you've made a mistake and created two masters. So +1 from me.
It will also be useful for me for sharding. Right now, I'm doing a
hackish version of
On Thu, Aug 22, 2013 at 6:42 AM, Andres Freund wrote:
>
> FWIW I've wished for that function repeatedly. Mostly just to make sure
> I am actually connected to the same "network" of replicas and not some
> other.
> It's also useful if you're providing support for a limited number of
> machines and
On 2013-08-22 21:51:22 +0900, Fujii Masao wrote:
> On Thu, Aug 22, 2013 at 6:43 AM, Vik Fearing wrote:
> > After someone in IRC asked if there was an equivalent to MySQL's
> > server_id, it was noted that we do have a system identifier but it's not
> > very accessible.
> >
> > The attached patch i
On 08/22/2013 03:21 PM, Fujii Masao wrote:
>> > I don't know if that's justification enough, which is
>> > why I didn't add it to the commitfest yet.
> You can add the patch to CF, and then hear the opinions from other people
> during CF.
Added.
--
Vik
--
Sent via pgsql-hackers mailing list
On Thu, Aug 22, 2013 at 9:53 PM, Vik Fearing wrote:
> On 08/22/2013 02:51 PM, Fujii Masao wrote:
>> On Thu, Aug 22, 2013 at 6:43 AM, Vik Fearing wrote:
>>> After someone in IRC asked if there was an equivalent to MySQL's
>>> server_id, it was noted that we do have a system identifier but it's not
On 08/22/2013 02:51 PM, Fujii Masao wrote:
> On Thu, Aug 22, 2013 at 6:43 AM, Vik Fearing wrote:
>> After someone in IRC asked if there was an equivalent to MySQL's
>> server_id, it was noted that we do have a system identifier but it's not
>> very accessible.
>>
>> The attached patch implements a
On Thu, Aug 22, 2013 at 6:43 AM, Vik Fearing wrote:
> After someone in IRC asked if there was an equivalent to MySQL's
> server_id, it was noted that we do have a system identifier but it's not
> very accessible.
>
> The attached patch implements a pg_system_identifier() function that
> exposes it
After someone in IRC asked if there was an equivalent to MySQL's
server_id, it was noted that we do have a system identifier but it's not
very accessible.
The attached patch implements a pg_system_identifier() function that
exposes it.
Shall I add this to the next commitfest?
--
Vik
*** a/doc/
43 matches
Mail list logo
