Re: [HACKERS] Postgres-R: primary key patches

Dimitri Fontaine <[EMAIL PROTECTED]> writes: > Note that while slony doesn't require a dump/restore to get activated, it > seems to me (as a non user of it) that it still plays with catalog, > preventing "normal" usage of pg_dump... As of 8.3 there are some new trigger features in core that were

Re: [HACKERS] Postgres-R: primary key patches

Hi, Dimitri Fontaine wrote: This part of Markus's mail makes me think the need may change if Postgres-R is ever integrated into -core: Yes, in that case, you'd have replication already compiled in and distributed with standard Postgres. However, ATM that's pipe dreaming and I'm pretty sure n

Re: [HACKERS] Postgres-R: primary key patches

Le mardi 22 juillet 2008, Christopher Browne a écrit : > A most pointed case where that will cause heartburn of the "I refuse > to use this" sort is if that disruption needs to take place when > recovering from the failure of a node. That sort of disruption is > certainly counterproductive to the

Re: [HACKERS] Postgres-R: primary key patches

Markus Wanner wrote: >> Ideally, we'd take an outage and add the primary key. But suppose we >> can't afford to do so? > > You are assuming that one doesn't need to take an outage to start > replication in the first place. As Postgres-R comes with system catalog > changes, that's not the case

Re: [HACKERS] Postgres-R: primary key patches

Hi, Christopher Browne wrote: Markus Wanner <[EMAIL PROTECTED]> writes: Thinking about index creation time doesn't make sense, as long as we still need a dump/restore cycle to setup replication. And even then, that operational issue has n

Re: [HACKERS] Postgres-R: primary key patches

Markus Wanner <[EMAIL PROTECTED]> writes: > Thinking about index creation time doesn't make sense, as long as we > still need a dump/restore cycle to setup replication. And even then, > that operational issue has nothing to do with the question

Re: [HACKERS] Postgres-R: primary key patches

Hi, chris wrote: I'll describe a scenario to suggest where it might happen. - A system is implemented, using the database, and, for some reason, no PRIMARY KEY is defined for a table. Someone forgot; it got misconfigured; a mistake was probably made. - The system then goes into production

Re: [HACKERS] Postgres-R: primary key patches

[EMAIL PROTECTED] (Markus Wanner) writes: > chris wrote: >> I agree with you that tables are *supposed* to have primary keys; >> that's proper design, and if tables are missing them, then something >> is definitely broken. > > Ah, I see, so you are not concerned about tables with a PRIMARY KEY > fo

Re: [HACKERS] Postgres-R: primary key patches

Hi, Alvaro Herrera wrote: Markus Wanner wrote: (Although, I'm still less than thrilled about the internal storage format of these tuple collections. That can certainly be improved and simplified.) Care to expand more on what it is? Well, what I really dislike is the overhead in code to f

Re: [HACKERS] Postgres-R: primary key patches

Markus Wanner wrote: > (Although, I'm still less than thrilled about the internal storage > format of these tuple collections. That can certainly be improved and > simplified.) Care to expand more on what it is? On Replicator we're using the binary send/recv routines to transmit tuples. (Ob

Re: [HACKERS] Postgres-R: primary key patches

Hi, chris wrote: You may want to have a chat with Jan; he's got some thoughts on a more general purpose mechanism that would be good for this as well as for (we think) extremely efficient bulk data loading. Jan, mind to share your thoughts? What use cases for such a general purpose mechanism

Re: [HACKERS] Postgres-R: primary key patches

Hi, chris wrote: I agree with you that tables are *supposed* to have primary keys; that's proper design, and if tables are missing them, then something is definitely broken. Ah, I see, so you are not concerned about tables with a PRIMARY KEY for which one wants another REPLICATION KEY, but on

Re: [HACKERS] Postgres-R: primary key patches

[EMAIL PROTECTED] (Markus Wanner) writes: > Hello Chris, > > chris wrote: >> Slony-I does the same, with the "variation" that it permits the option >> of using a "candidate primary key," namely an index that is unique+NOT >> NULL. >> >> If it is possible to support that broader notion, that might m

Re: [HACKERS] Postgres-R: primary key patches

Hi, Alvaro Herrera wrote: I think the point here is that you need to distinguish which tuple you need to update. For this, our Replicator uses the primary key only; there's no way to use another candidate key (unique not null). It would certainly be possible to use a different candidate key,

Re: [HACKERS] Postgres-R: primary key patches

Markus Wanner wrote: > Gregory Stark wrote: >> It would be nice if there was a way for Slony to express to the server that >> really, it only needs any UNIQUE NOT NULL combination of columns to match. >> Once the server has any such combination which matches it can skip checking >> the rest. I ca

Re: [HACKERS] Postgres-R: primary key patches

Hi, I realize that you are talk about Slony, let me answer for the Postgres-R case, anyway. Gregory Stark wrote: Hm, it occurs to me that really Slony should be saying WHERE (col1,col2,...) = ('x','y','z',...) Hm.. that would mean increasing the amount of work for the remote backend, whic

Re: [HACKERS] Postgres-R: primary key patches

Hi, Tom Lane wrote: It's the default foreign key reference column(s) for the table That's why I think it makes for a pretty good replication key as well. Regards Markus -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.pos

Re: [HACKERS] Postgres-R: primary key patches

Hi, sorry, some strange key-combination made my mail client send too early... I myself wrote: I was trying to say that Postgres-R internally relies only on a unique index with not null constraint. It doesn't care if you name it PRIMARY KEY or REPLICATION KEY or whatever. So, it's just a ques

Re: [HACKERS] Postgres-R: primary key patches

Hi, David Fetter wrote: While I'm a "chicken" rather than a "pig" on this project , I believe that covering the more general case right from the start would be a much better plan. I was trying to say that Postgres-R internally relies only o

Re: [HACKERS] Postgres-R: primary key patches

"David Fetter" <[EMAIL PROTECTED]> writes: > On Fri, Jul 18, 2008 at 03:04:08PM +0200, Markus Schiltknecht wrote: >> Hello Chris, >> >> chris wrote: >>> Slony-I does the same, with the "variation" that it permits the >>> option of using a "candidate primary key," namely an index that is >>> unique

Re: [HACKERS] Postgres-R: primary key patches

David Fetter <[EMAIL PROTECTED]> writes: > On Fri, Jul 18, 2008 at 03:04:08PM +0200, Markus Schiltknecht wrote: >> But what do we have primary keys for, in the first place? > We have them because people are used to thinking in terms of a > "PRIMARY KEY," not because that concept is actually distin

Re: [HACKERS] Postgres-R: primary key patches

On Fri, Jul 18, 2008 at 03:04:08PM +0200, Markus Schiltknecht wrote: > Hello Chris, > > chris wrote: >> Slony-I does the same, with the "variation" that it permits the >> option of using a "candidate primary key," namely an index that is >> unique+NOT NULL. >> >> If it is possible to support that b

Re: [HACKERS] Postgres-R: primary key patches

Hello Chris, chris wrote: Slony-I does the same, with the "variation" that it permits the option of using a "candidate primary key," namely an index that is unique+NOT NULL. If it is possible to support that broader notion, that might make addition of these sorts of logic more widely useful.

Re: [HACKERS] Postgres-R: primary key patches

[EMAIL PROTECTED] (Markus Wanner) writes: > as you might know, Postgres-R relies on primary keys to address tuples > of a table. It cannot replicate tables without a primary key. Slony-I does the same, with the "variation" that it permits the option of using a "candidate primary key," namely an in

[HACKERS] Postgres-R: primary key patches

Hi, as you might know, Postgres-R relies on primary keys to address tuples of a table. It cannot replicate tables without a primary key. Primary keys currently aren't really used within the executor, so I had to extended and modify Postgres here and there, to get the required information. To