On Tue, Sep 17, 2013 at 11:43 AM, Robert Haas robertmh...@gmail.com wrote:
On Tue, Sep 17, 2013 at 10:59 AM, Andres Freund and...@2ndquadrant.com
wrote:
On 2013-09-17 10:57:46 -0400, Robert Haas wrote:
On Mon, Sep 16, 2013 at 1:25 AM, Satoshi Nagayasu sn...@uptime.jp wrote:
How about adding
Dne 17. 9. 2013 17:01 Andres Freund and...@2ndquadrant.com napsal(a):
On 2013-09-17 10:57:46 -0400, Robert Haas wrote:
On Mon, Sep 16, 2013 at 1:25 AM, Satoshi Nagayasu sn...@uptime.jp
wrote:
How about adding new system view with new function which returns
a single pg_controldata value
On 2013-09-17 10:57:46 -0400, Robert Haas wrote:
On Mon, Sep 16, 2013 at 1:25 AM, Satoshi Nagayasu sn...@uptime.jp 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?
On Mon, Sep 16, 2013 at 1:25 AM, Satoshi Nagayasu sn...@uptime.jp 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
On Tue, Sep 17, 2013 at 10:59 AM, Andres Freund and...@2ndquadrant.com wrote:
On 2013-09-17 10:57:46 -0400, Robert Haas wrote:
On Mon, Sep 16, 2013 at 1:25 AM, Satoshi Nagayasu sn...@uptime.jp wrote:
How about adding new system view with new function which returns
a single pg_controldata
Hi,
I'm catching up with the discussion as a reviewer...
(2013/08/27 5:35), Tom Lane wrote:
Andres Freund and...@2ndquadrant.com 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
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 for them
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 itself
On Mon, Aug 26, 2013 at 1:12 PM, Michael Paquier
michael.paqu...@gmail.com wrote:
On Mon, Aug 26, 2013 at 7:47 AM, Jim Nasby j...@nasby.net 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
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:
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
Andres Freund and...@2ndquadrant.com 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
On 2013-08-26 21:13:49 +0200, Dimitri Fontaine wrote:
Andres Freund and...@2ndquadrant.com 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
Andres Freund and...@2ndquadrant.com 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
On 2013-08-26 16:35:57 -0400, Tom Lane wrote:
Andres Freund and...@2ndquadrant.com 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:
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 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
On Mon, Aug 26, 2013 at 7:47 AM, Jim Nasby j...@nasby.net 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
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
Vik Fearing vik.fear...@dalibo.com 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
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 of
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 ha...@2ndquadrant.comwrote:
On 08/22/2013 06:37 PM, Tom Lane wrote:
A
Do we have
On Fri, Aug 23, 2013 at 3:10 AM, Fabien COELHO coe...@cri.ensmp.fr 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
Christopher Browne cbbro...@gmail.com writes:
On Fri, Aug 23, 2013 at 3:10 AM, Fabien COELHO coe...@cri.ensmp.fr 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
On Thu, Aug 22, 2013 at 6:43 AM, Vik Fearing vik.fear...@dalibo.com 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
On 08/22/2013 02:51 PM, Fujii Masao wrote:
On Thu, Aug 22, 2013 at 6:43 AM, Vik Fearing vik.fear...@dalibo.com 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
On Thu, Aug 22, 2013 at 9:53 PM, Vik Fearing vik.fear...@dalibo.com wrote:
On 08/22/2013 02:51 PM, Fujii Masao wrote:
On Thu, Aug 22, 2013 at 6:43 AM, Vik Fearing vik.fear...@dalibo.com wrote:
After someone in IRC asked if there was an equivalent to MySQL's
server_id, it was noted that we do
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 2013-08-22 21:51:22 +0900, Fujii Masao wrote:
On Thu, Aug 22, 2013 at 6:43 AM, Vik Fearing vik.fear...@dalibo.com 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
On Thu, Aug 22, 2013 at 6:42 AM, Andres Freund and...@2ndquadrant.comwrote:
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
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
bricklen brick...@gmail.com writes:
On Thu, Aug 22, 2013 at 6:42 AM, Andres Freund and...@2ndquadrant.comwrote:
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
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 for me
Josh Berkus j...@agliodbs.com 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
Andres Freund and...@2ndquadrant.com 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
On 2013-08-22 12:06:03 -0400, Tom Lane wrote:
Andres Freund and...@2ndquadrant.com 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
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 a
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
obtained.
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 increase the
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 doesn't
Andres Freund and...@2ndquadrant.com 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
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
42 matches
Mail list logo
