Re: [HACKERS] Changeset Extraction v7.3

2014-01-29 Thread Christian Convey
It seems to me that the terms "physical", "logical", and "binary" are
always relative to the perspective of the component being worked on.

"Physical" often means "one level of abstraction below mine, and upon which
my work builds".  "Logical" means "my work's level of abstraction".  And
"Binary" means "data which I'm not going to pretend I know or care how to
interpret."

So I'd suggest "block" and "tuple", perhaps.


On Wed, Jan 29, 2014 at 4:25 AM, Albe Laurenz wrote:

> Andreas Karlsson wrote:
> > On 01/28/2014 10:56 PM, Andres Freund wrote:
> >> On 2014-01-28 21:48:09 +, Thom Brown wrote:
> >>> On 28 January 2014 21:37, Robert Haas  wrote:
>  On Tue, Jan 28, 2014 at 11:53 AM, Robert Haas 
> wrote:
>  The point of Andres's patch set is to introduce a new technology
>  called logical decoding; that is, the ability to get a replication
>  stream that is based on changes to tuples rather than changes to
>  blocks.  It could also be called logical replication.  In these
>  patches, our existing replication is referred to as "physical"
>  replication, which sounds kind of funny to me.  Anyone have another
>  suggestion?
> >>>
> >>> Logical and Binary replication?
> >>
> >> Unfortunately changeset extraction output's can be binary data...
> >
> > I think "physical" and "logical" are fine and they seem to be well known
> > terminology. Oracle uses those words and I have also seen many places
> > use "physical backup" and "logical backup", for example on Barman's
> > homepage.
>
> +1
>
> I think it also fits well with the well-known terms "physical [database]
> design" and "logical design".  Not that it is the same thing, but I
> believe that every database person, when faced with the distiction
> "physical" versus "logical", will conclude that the former refers to
> data placement or block structure, while the latter refers to the
> semantics of the data being stored.
>
> Yours,
> Laurenz Albe
>
> --
> Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-hackers
>


Re: [HACKERS] Changeset Extraction v7.3

2014-01-29 Thread Albe Laurenz
Andreas Karlsson wrote:
> On 01/28/2014 10:56 PM, Andres Freund wrote:
>> On 2014-01-28 21:48:09 +, Thom Brown wrote:
>>> On 28 January 2014 21:37, Robert Haas  wrote:
 On Tue, Jan 28, 2014 at 11:53 AM, Robert Haas  
 wrote:
 The point of Andres's patch set is to introduce a new technology
 called logical decoding; that is, the ability to get a replication
 stream that is based on changes to tuples rather than changes to
 blocks.  It could also be called logical replication.  In these
 patches, our existing replication is referred to as "physical"
 replication, which sounds kind of funny to me.  Anyone have another
 suggestion?
>>>
>>> Logical and Binary replication?
>>
>> Unfortunately changeset extraction output's can be binary data...
> 
> I think "physical" and "logical" are fine and they seem to be well known
> terminology. Oracle uses those words and I have also seen many places
> use "physical backup" and "logical backup", for example on Barman's
> homepage.

+1

I think it also fits well with the well-known terms "physical [database]
design" and "logical design".  Not that it is the same thing, but I
believe that every database person, when faced with the distiction
"physical" versus "logical", will conclude that the former refers to
data placement or block structure, while the latter refers to the
semantics of the data being stored.

Yours,
Laurenz Albe

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


Re: [HACKERS] Changeset Extraction v7.3

2014-01-28 Thread Robert Haas
On Tue, Jan 28, 2014 at 7:43 PM, Andreas Karlsson  wrote:
> I think "physical" and "logical" are fine and they seem to be well known
> terminology. Oracle uses those words and I have also seen many places use
> "physical backup" and "logical backup", for example on Barman's homepage.

There's certainly something to be said for this.

Another idea I had this evening was "logical replication" and
"WAL-based replication", but that's a bit confusing too since logical
rep. is going to use WAL as an underlying technology.

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


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


Re: [HACKERS] Changeset Extraction v7.3

2014-01-28 Thread Andreas Karlsson

On 01/28/2014 10:56 PM, Andres Freund wrote:

On 2014-01-28 21:48:09 +, Thom Brown wrote:

On 28 January 2014 21:37, Robert Haas  wrote:

On Tue, Jan 28, 2014 at 11:53 AM, Robert Haas  wrote:
The point of Andres's patch set is to introduce a new technology
called logical decoding; that is, the ability to get a replication
stream that is based on changes to tuples rather than changes to
blocks.  It could also be called logical replication.  In these
patches, our existing replication is referred to as "physical"
replication, which sounds kind of funny to me.  Anyone have another
suggestion?


Logical and Binary replication?


Unfortunately changeset extraction output's can be binary data...


I think "physical" and "logical" are fine and they seem to be well known 
terminology. Oracle uses those words and I have also seen many places 
use "physical backup" and "logical backup", for example on Barman's 
homepage.


--
Andreas Karlsson


--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


Re: [HACKERS] Changeset Extraction v7.3

2014-01-28 Thread David Fetter
On Tue, Jan 28, 2014 at 05:31:25PM -0500, Rod Taylor wrote:
> On Tue, Jan 28, 2014 at 4:56 PM, Andres Freund wrote:
> 
> > On 2014-01-28 21:48:09 +, Thom Brown wrote:
> > > On 28 January 2014 21:37, Robert Haas  wrote:
> > > > On Tue, Jan 28, 2014 at 11:53 AM, Robert Haas 
> > wrote:
> > > >> I've rebased it here and am hacking on it still.
> > > >
> > > > Andres and I are going back and forth between our respective git repos
> > > > hacking on this, and I think we're getting there, but I have a
> > > > terminological question which I'd like to submit to a wider audience:
> > > >
> > > > The point of Andres's patch set is to introduce a new technology
> > > > called logical decoding; that is, the ability to get a replication
> > > > stream that is based on changes to tuples rather than changes to
> > > > blocks.  It could also be called logical replication.  In these
> > > > patches, our existing replication is referred to as "physical"
> > > > replication, which sounds kind of funny to me.  Anyone have another
> > > > suggestion?
> > >
> > > Logical and Binary replication?
> >
> > Unfortunately changeset extraction output's can be binary data...
> >
> 
> Perhaps Logical and Block?
> 
> The existing replication mechanism is similar to block-based disk backups.
> It's the whole thing (not parts) and doesn't have any concept of
> database/directory.

+1 for this terminology.  It's descriptive.

Cheers,
David.
-- 
David Fetter  http://fetter.org/
Phone: +1 415 235 3778  AIM: dfetter666  Yahoo!: dfetter
Skype: davidfetter  XMPP: david.fet...@gmail.com
iCal: webcal://www.tripit.com/feed/ical/people/david74/tripit.ics

Remember to vote!
Consider donating to Postgres: http://www.postgresql.org/about/donate


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


Re: [HACKERS] Changeset Extraction v7.3

2014-01-28 Thread Rod Taylor
On Tue, Jan 28, 2014 at 4:56 PM, Andres Freund wrote:

> On 2014-01-28 21:48:09 +, Thom Brown wrote:
> > On 28 January 2014 21:37, Robert Haas  wrote:
> > > On Tue, Jan 28, 2014 at 11:53 AM, Robert Haas 
> wrote:
> > >> I've rebased it here and am hacking on it still.
> > >
> > > Andres and I are going back and forth between our respective git repos
> > > hacking on this, and I think we're getting there, but I have a
> > > terminological question which I'd like to submit to a wider audience:
> > >
> > > The point of Andres's patch set is to introduce a new technology
> > > called logical decoding; that is, the ability to get a replication
> > > stream that is based on changes to tuples rather than changes to
> > > blocks.  It could also be called logical replication.  In these
> > > patches, our existing replication is referred to as "physical"
> > > replication, which sounds kind of funny to me.  Anyone have another
> > > suggestion?
> >
> > Logical and Binary replication?
>
> Unfortunately changeset extraction output's can be binary data...
>

Perhaps Logical and Block?

The existing replication mechanism is similar to block-based disk backups.
It's the whole thing (not parts) and doesn't have any concept of
database/directory.


Re: [HACKERS] Changeset Extraction v7.3

2014-01-28 Thread Thom Brown
On 28 January 2014 21:56, Andres Freund  wrote:
> On 2014-01-28 21:48:09 +, Thom Brown wrote:
>> On 28 January 2014 21:37, Robert Haas  wrote:
>> > On Tue, Jan 28, 2014 at 11:53 AM, Robert Haas  
>> > wrote:
>> >> I've rebased it here and am hacking on it still.
>> >
>> > Andres and I are going back and forth between our respective git repos
>> > hacking on this, and I think we're getting there, but I have a
>> > terminological question which I'd like to submit to a wider audience:
>> >
>> > The point of Andres's patch set is to introduce a new technology
>> > called logical decoding; that is, the ability to get a replication
>> > stream that is based on changes to tuples rather than changes to
>> > blocks.  It could also be called logical replication.  In these
>> > patches, our existing replication is referred to as "physical"
>> > replication, which sounds kind of funny to me.  Anyone have another
>> > suggestion?
>>
>> Logical and Binary replication?
>
> Unfortunately changeset extraction output's can be binary data...

"system"?
"cluster"?
"full"?
"complete"?

-- 
Thom


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


Re: [HACKERS] Changeset Extraction v7.3

2014-01-28 Thread Andres Freund
On 2014-01-28 21:48:09 +, Thom Brown wrote:
> On 28 January 2014 21:37, Robert Haas  wrote:
> > On Tue, Jan 28, 2014 at 11:53 AM, Robert Haas  wrote:
> >> I've rebased it here and am hacking on it still.
> >
> > Andres and I are going back and forth between our respective git repos
> > hacking on this, and I think we're getting there, but I have a
> > terminological question which I'd like to submit to a wider audience:
> >
> > The point of Andres's patch set is to introduce a new technology
> > called logical decoding; that is, the ability to get a replication
> > stream that is based on changes to tuples rather than changes to
> > blocks.  It could also be called logical replication.  In these
> > patches, our existing replication is referred to as "physical"
> > replication, which sounds kind of funny to me.  Anyone have another
> > suggestion?
> 
> Logical and Binary replication?

Unfortunately changeset extraction output's can be binary data...

Greetings,

Andres Freund

-- 
 Andres Freund http://www.2ndQuadrant.com/
 PostgreSQL Development, 24x7 Support, Training & Services


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


Re: [HACKERS] Changeset Extraction v7.3

2014-01-28 Thread Thom Brown
On 28 January 2014 21:37, Robert Haas  wrote:
> On Tue, Jan 28, 2014 at 11:53 AM, Robert Haas  wrote:
>> I've rebased it here and am hacking on it still.
>
> Andres and I are going back and forth between our respective git repos
> hacking on this, and I think we're getting there, but I have a
> terminological question which I'd like to submit to a wider audience:
>
> The point of Andres's patch set is to introduce a new technology
> called logical decoding; that is, the ability to get a replication
> stream that is based on changes to tuples rather than changes to
> blocks.  It could also be called logical replication.  In these
> patches, our existing replication is referred to as "physical"
> replication, which sounds kind of funny to me.  Anyone have another
> suggestion?

Logical and Binary replication?

-- 
Thom


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


Re: [HACKERS] Changeset Extraction v7.3

2014-01-28 Thread Robert Haas
On Tue, Jan 28, 2014 at 11:53 AM, Robert Haas  wrote:
> I've rebased it here and am hacking on it still.

Andres and I are going back and forth between our respective git repos
hacking on this, and I think we're getting there, but I have a
terminological question which I'd like to submit to a wider audience:

The point of Andres's patch set is to introduce a new technology
called logical decoding; that is, the ability to get a replication
stream that is based on changes to tuples rather than changes to
blocks.  It could also be called logical replication.  In these
patches, our existing replication is referred to as "physical"
replication, which sounds kind of funny to me.  Anyone have another
suggestion?

There are a lot of ways to slice the space of possible replication
solutions.  We currently talk about "streaming replication" (as
opposed to "archiving") and "synchronous replication" (as opposed to
asynchronous), but this is a new distinction.  At least in theory,
whether replication is "physical" or logical is independent of whether
it's based on streaming or archiving and also of whether it's
synchronous or asynchronous.  So we can't for example talk about
"logical replication" in opposition to "streaming replication"; that's
comparing apples and oranges.  We need a pair of new terms, and I
can't immediately think of anything better than physical/logical, but
it still sounds somewhat awkward to me so ... anyone else have an
idea?

Thanks,

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


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


Re: [HACKERS] Changeset Extraction v7.3

2014-01-28 Thread Robert Haas
On Tue, Jan 28, 2014 at 11:49 AM, Thom Brown  wrote:
> On 27 January 2014 16:20, Andres Freund  wrote:
>> Hi,
>>
>> Here's the next version of the patchset. The following changes have been
>> made:
>> * move xmin pegging and more logic responsibility to procarray.c
>> * split all support for changeset extraction from the initial slot patch
>> * always register an before_shmem_exit handler when
>>   max_replication_slots is registered, not just while a slot is acquired
>> * move some patch hunks to earlier patches, especially the
>>   ReplicationSlotAcquire() call for physical rep that accidentally
>>   slipped and the SQL accessible slot manipulation functions
>> * minor stuff
>
> 0001 doesn't apply cleanly due to commit
> ea9df812d8502fff74e7bc37d61bdc7d66d77a7f.
>
> The rest are fine.

I've rebased it here and am hacking on it still.

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


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


Re: [HACKERS] Changeset Extraction v7.3

2014-01-28 Thread Thom Brown
On 27 January 2014 16:20, Andres Freund  wrote:
> Hi,
>
> Here's the next version of the patchset. The following changes have been
> made:
> * move xmin pegging and more logic responsibility to procarray.c
> * split all support for changeset extraction from the initial slot patch
> * always register an before_shmem_exit handler when
>   max_replication_slots is registered, not just while a slot is acquired
> * move some patch hunks to earlier patches, especially the
>   ReplicationSlotAcquire() call for physical rep that accidentally
>   slipped and the SQL accessible slot manipulation functions
> * minor stuff

0001 doesn't apply cleanly due to commit
ea9df812d8502fff74e7bc37d61bdc7d66d77a7f.

The rest are fine.

-- 
Thom


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers