Обсуждение: pg_listener table errors with slony
Hi,<br /><br />I am using slony 2.06 on a pg 9.0.2 installation with pgadmin 12.2.2.<br />Whenever I click on certain elementsof the object browser associated with replication I get an error:<br /><br />ERROR: relation pg_listener does notexist<br /> LINE 1: SELECT listenerpid FROM pg_listener WHERE relname = '...<br /><br />This occur under Replication-><clustername> for example or when clicking on nodes under that. This also occurs on 12.2.1.<br /><br/>I believe this table no longer exists in 9.0 so I guess this is technically a bug. Should it be logged as such?<br/><br />cheers,<br /><br />B<br />
Le 14/01/2011 00:09, Ben Carbery a écrit : > [...] > I am using slony 2.06 on a pg 9.0.2 installation with pgadmin 12.2.2. > Whenever I click on certain elements of the object browser associated with > replication I get an error: > > ERROR: relation pg_listener does not exist > LINE 1: SELECT listenerpid FROM pg_listener WHERE relname = '... > > This occur under Replication-><cluster name> for example or when clicking on > nodes under that. This also occurs on 12.2.1. > > I believe this table no longer exists in 9.0 so I guess this is technically > a bug. Should it be logged as such? > Well, pgAdmin fires this query. As you say, this table no longer exists since the rework on the listen/notify mechanism done for 9.0. So, yeah, this is a bug in pgAdmin. I'll try to work on this tomorrow. Thanks for your report. -- Guillaumehttp://www.postgresql.frhttp://dalibo.com
Le 14/01/2011 00:27, Guillaume Lelarge a écrit : > Le 14/01/2011 00:09, Ben Carbery a écrit : >> [...] >> I am using slony 2.06 on a pg 9.0.2 installation with pgadmin 12.2.2. >> Whenever I click on certain elements of the object browser associated with >> replication I get an error: >> >> ERROR: relation pg_listener does not exist >> LINE 1: SELECT listenerpid FROM pg_listener WHERE relname = '... >> >> This occur under Replication-><cluster name> for example or when clicking on >> nodes under that. This also occurs on 12.2.1. >> >> I believe this table no longer exists in 9.0 so I guess this is technically >> a bug. Should it be logged as such? >> > > Well, pgAdmin fires this query. As you say, this table no longer exists > since the rework on the listen/notify mechanism done for 9.0. So, yeah, > this is a bug in pgAdmin. > > I'll try to work on this tomorrow. > Got a look at this, and I reproduce the error. I don't think we have any support of Slony 2.0. -- Guillaumehttp://www.postgresql.frhttp://dalibo.com
On Wed, Jan 19, 2011 at 8:20 PM, Guillaume Lelarge <guillaume@lelarge.info> wrote: > Le 14/01/2011 00:27, Guillaume Lelarge a écrit : >> Le 14/01/2011 00:09, Ben Carbery a écrit : >>> [...] >>> I am using slony 2.06 on a pg 9.0.2 installation with pgadmin 12.2.2. >>> Whenever I click on certain elements of the object browser associated with >>> replication I get an error: >>> >>> ERROR: relation pg_listener does not exist >>> LINE 1: SELECT listenerpid FROM pg_listener WHERE relname = '... >>> >>> This occur under Replication-><cluster name> for example or when clicking on >>> nodes under that. This also occurs on 12.2.1. >>> >>> I believe this table no longer exists in 9.0 so I guess this is technically >>> a bug. Should it be logged as such? >>> >> >> Well, pgAdmin fires this query. As you say, this table no longer exists >> since the rework on the listen/notify mechanism done for 9.0. So, yeah, >> this is a bug in pgAdmin. >> >> I'll try to work on this tomorrow. >> > > Got a look at this, and I reproduce the error. I don't think we have any > support of Slony 2.0. We did. -- Dave Page Blog: http://pgsnake.blogspot.com Twitter: @pgsnake EnterpriseDB UK: http://www.enterprisedb.com The Enterprise PostgreSQL Company
Le 19/01/2011 22:23, Dave Page a écrit : > On Wed, Jan 19, 2011 at 8:20 PM, Guillaume Lelarge > <guillaume@lelarge.info> wrote: >> Le 14/01/2011 00:27, Guillaume Lelarge a écrit : >>> Le 14/01/2011 00:09, Ben Carbery a écrit : >>>> [...] >>>> I am using slony 2.06 on a pg 9.0.2 installation with pgadmin 12.2.2. >>>> Whenever I click on certain elements of the object browser associated with >>>> replication I get an error: >>>> >>>> ERROR: relation pg_listener does not exist >>>> LINE 1: SELECT listenerpid FROM pg_listener WHERE relname = '... >>>> >>>> This occur under Replication-><cluster name> for example or when clicking on >>>> nodes under that. This also occurs on 12.2.1. >>>> >>>> I believe this table no longer exists in 9.0 so I guess this is technically >>>> a bug. Should it be logged as such? >>>> >>> >>> Well, pgAdmin fires this query. As you say, this table no longer exists >>> since the rework on the listen/notify mechanism done for 9.0. So, yeah, >>> this is a bug in pgAdmin. >>> >>> I'll try to work on this tomorrow. >>> >> >> Got a look at this, and I reproduce the error. I don't think we have any >> support of Slony 2.0. > > We did. > We had 1.2 support. To have 2.0, we would have to get rid of the sl_trigger checks. Or was it dropped along the way of 2.0? -- Guillaumehttp://www.postgresql.frhttp://dalibo.com
On Wed, Jan 19, 2011 at 9:30 PM, Guillaume Lelarge <guillaume@lelarge.info> wrote: > Le 19/01/2011 22:23, Dave Page a écrit : >> On Wed, Jan 19, 2011 at 8:20 PM, Guillaume Lelarge >> <guillaume@lelarge.info> wrote: >>> Le 14/01/2011 00:27, Guillaume Lelarge a écrit : >>>> Le 14/01/2011 00:09, Ben Carbery a écrit : >>>>> [...] >>>>> I am using slony 2.06 on a pg 9.0.2 installation with pgadmin 12.2.2. >>>>> Whenever I click on certain elements of the object browser associated with >>>>> replication I get an error: >>>>> >>>>> ERROR: relation pg_listener does not exist >>>>> LINE 1: SELECT listenerpid FROM pg_listener WHERE relname = '... >>>>> >>>>> This occur under Replication-><cluster name> for example or when clicking on >>>>> nodes under that. This also occurs on 12.2.1. >>>>> >>>>> I believe this table no longer exists in 9.0 so I guess this is technically >>>>> a bug. Should it be logged as such? >>>>> >>>> >>>> Well, pgAdmin fires this query. As you say, this table no longer exists >>>> since the rework on the listen/notify mechanism done for 9.0. So, yeah, >>>> this is a bug in pgAdmin. >>>> >>>> I'll try to work on this tomorrow. >>>> >>> >>> Got a look at this, and I reproduce the error. I don't think we have any >>> support of Slony 2.0. >> >> We did. >> > > We had 1.2 support. To have 2.0, we would have to get rid of the > sl_trigger checks. Or was it dropped along the way of 2.0? No idea - I just recall Sachin working on compatibility, and that was one of/the patch he came of with. FWIW, I'd be happy to drop support. I don't think many people use it, and it certainly doesn't get tested enough. Plus, it's just one of many replication engines. -- Dave Page Blog: http://pgsnake.blogspot.com Twitter: @pgsnake EnterpriseDB UK: http://www.enterprisedb.com The Enterprise PostgreSQL Company
Le 19/01/2011 22:33, Dave Page a écrit : > On Wed, Jan 19, 2011 at 9:30 PM, Guillaume Lelarge > <guillaume@lelarge.info> wrote: >> Le 19/01/2011 22:23, Dave Page a écrit : >>> On Wed, Jan 19, 2011 at 8:20 PM, Guillaume Lelarge >>> <guillaume@lelarge.info> wrote: >>>> Le 14/01/2011 00:27, Guillaume Lelarge a écrit : >>>>> Le 14/01/2011 00:09, Ben Carbery a écrit : >>>>>> [...] >>>>>> I am using slony 2.06 on a pg 9.0.2 installation with pgadmin 12.2.2. >>>>>> Whenever I click on certain elements of the object browser associated with >>>>>> replication I get an error: >>>>>> >>>>>> ERROR: relation pg_listener does not exist >>>>>> LINE 1: SELECT listenerpid FROM pg_listener WHERE relname = '... >>>>>> >>>>>> This occur under Replication-><cluster name> for example or when clicking on >>>>>> nodes under that. This also occurs on 12.2.1. >>>>>> >>>>>> I believe this table no longer exists in 9.0 so I guess this is technically >>>>>> a bug. Should it be logged as such? >>>>>> >>>>> >>>>> Well, pgAdmin fires this query. As you say, this table no longer exists >>>>> since the rework on the listen/notify mechanism done for 9.0. So, yeah, >>>>> this is a bug in pgAdmin. >>>>> >>>>> I'll try to work on this tomorrow. >>>>> >>>> >>>> Got a look at this, and I reproduce the error. I don't think we have any >>>> support of Slony 2.0. >>> >>> We did. >>> >> >> We had 1.2 support. To have 2.0, we would have to get rid of the >> sl_trigger checks. Or was it dropped along the way of 2.0? > > No idea - I just recall Sachin working on compatibility, and that was > one of/the patch he came of with. > Yeah, you're right. I now see the commit. Which means we have two bugs on 2.0 support. > FWIW, I'd be happy to drop support. I don't think many people use it, > and it certainly doesn't get tested enough. I kind of agree for it not being tested enough. > Plus, it's just one of many replication engines. > This isn't a good reason to me. I would like to see something alike for SR. -- Guillaumehttp://www.postgresql.frhttp://dalibo.com
On Wed, Jan 19, 2011 at 9:40 PM, Guillaume Lelarge <guillaume@lelarge.info> wrote: > Le 19/01/2011 22:33, Dave Page a écrit : > >> Plus, it's just one of many replication engines. >> > > This isn't a good reason to me. I would like to see something alike for SR. My point is, why should we support one external replication engine over another? Originally, it was because Slony was the only one worth considering, but that really isn't the case any more. I think SR is a different case - it's part of PostgreSQL, so certainly should be supported as makes sense. -- Dave Page Blog: http://pgsnake.blogspot.com Twitter: @pgsnake EnterpriseDB UK: http://www.enterprisedb.com The Enterprise PostgreSQL Company
Le 19/01/2011 22:47, Dave Page a écrit : > On Wed, Jan 19, 2011 at 9:40 PM, Guillaume Lelarge > <guillaume@lelarge.info> wrote: >> Le 19/01/2011 22:33, Dave Page a écrit : >> >>> Plus, it's just one of many replication engines. >>> >> >> This isn't a good reason to me. I would like to see something alike for SR. > > My point is, why should we support one external replication engine > over another? Originally, it was because Slony was the only one worth > considering, but that really isn't the case any more. > I don't see it that way. We don't support one over another. As you say, we support Slony because at the time, it was the only one worth it. We don't support the other ones because we don't have time to work on this. It isn't a case of "Slony is better, X is crap". It's just that we lack time (and perhaps motivation too) to add support for another one. Actually, I would have no problem adding another one, like Londiste for example. I don't have time to code this myself, but if someone does, I have no problem to see his work commited. > I think SR is a different case - it's part of PostgreSQL, so certainly > should be supported as makes sense. > Yeah, that makes sense. But it doesn't mean we should get rid of something working (apart from those two bugs). -- Guillaumehttp://www.postgresql.frhttp://dalibo.com
Hi Guillaume On Wed, Jan 19, 2011 at 9:40 PM, Guillaume Lelarge <guillaume@lelarge.info> wrote: > Le 19/01/2011 22:33, Dave Page a écrit : >> On Wed, Jan 19, 2011 at 9:30 PM, Guillaume Lelarge >> <guillaume@lelarge.info> wrote: >>> We had 1.2 support. To have 2.0, we would have to get rid of the >>> sl_trigger checks. Or was it dropped along the way of 2.0? >> >> No idea - I just recall Sachin working on compatibility, and that was >> one of/the patch he came of with. >> > > Yeah, you're right. I now see the commit. Which means we have two bugs > on 2.0 support. What happened with this in the end? I've just run into the pg_listener bug again. I see from the thread you said you were going to work on it, but then we got side-tracked into a discussion on whether we should have slony support at all. -- Dave Page Blog: http://pgsnake.blogspot.com Twitter: @pgsnake EnterpriseDB UK: http://www.enterprisedb.com The Enterprise PostgreSQL Company
On 11-06-01 05:58 AM, Dave Page wrote: > Hi Guillaume > > What happened with this in the end? I've just run into the pg_listener > bug again. I see from the thread you said you were going to work on > it, but then we got side-tracked into a discussion on whether we > should have slony support at all. > Since your discussing slony support I'll add my my personal thoughts (I can't say if the other Slony developers feel the same way). If your going to continue to have pgadmin change a slony cluster then I think pgadmin should be issuing commands by invoking slonik as a sub-process and not by calling the slony stored procedures directly. My thinking is 1) The API for the stored procedures has been known to change both between major releases and minor ones, while the syntax of slonik commands has mostly stayed the same. 2) In a number of cases slonik does more than just call a stored procedure (ie FAILOVER) and with 2.1 this has increased both because for most commands need to have obtained a lock on 'sl_event_lock' as the first command in a transaction (therefore before any stored procedures have been obtained) and to take advantage of the 'wait for' logic in 2.1
On Wed, Jun 1, 2011 at 2:35 PM, Steve Singer <ssinger@ca.afilias.info> wrote: > > Since your discussing slony support I'll add my my personal thoughts (I > can't say if the other Slony developers feel the same way). > > If your going to continue to have pgadmin change a slony cluster then I > think pgadmin should be issuing commands by invoking slonik as a sub-process > and not by calling the slony stored procedures directly. > > My thinking is > > 1) The API for the stored procedures has been known to change both between > major releases and minor ones, while the syntax of slonik commands has > mostly stayed the same. > > 2) In a number of cases slonik does more than just call a stored procedure > (ie FAILOVER) and with 2.1 this has increased both because for most commands > need to have obtained a lock on 'sl_event_lock' as the first command in a > transaction (therefore before any stored procedures have been obtained) and > to take advantage of the 'wait for' logic in 2.1 Hi Steve, Chris and I had a similar conversation at pgcon. Aside from the huge amount of rewriting that would involve, it would also mean we'd have to add a dependency on Slonik on the client, which could be a real pain for the user (for example, none of the Slony installers that I know of will currently install unless they can find a database server on the local machine). Given the lack of people complaining that it doesn't work on 9.0, I'm far more inclined to remove the Slony support altogether I'm afraid. It seems pretty clear noone is really using it. -- Dave Page Blog: http://pgsnake.blogspot.com Twitter: @pgsnake EnterpriseDB UK: http://www.enterprisedb.com The Enterprise PostgreSQL Company
On Wed, 2011-06-01 at 09:58 +0000, Dave Page wrote: > Hi Guillaume > > On Wed, Jan 19, 2011 at 9:40 PM, Guillaume Lelarge > <guillaume@lelarge.info> wrote: > > Le 19/01/2011 22:33, Dave Page a écrit : > >> On Wed, Jan 19, 2011 at 9:30 PM, Guillaume Lelarge > >> <guillaume@lelarge.info> wrote: > >>> We had 1.2 support. To have 2.0, we would have to get rid of the > >>> sl_trigger checks. Or was it dropped along the way of 2.0? > >> > >> No idea - I just recall Sachin working on compatibility, and that was > >> one of/the patch he came of with. > >> > > > > Yeah, you're right. I now see the commit. Which means we have two bugs > > on 2.0 support. > > What happened with this in the end? I've just run into the pg_listener > bug again. I see from the thread you said you were going to work on > it, but then we got side-tracked into a discussion on whether we > should have slony support at all. > I still have it on my todo list. -- Guillaume http://blog.guillaume.lelarge.info http://www.dalibo.com
On Wed, Jun 1, 2011 at 4:11 PM, Guillaume Lelarge <guillaume@lelarge.info> wrote: > On Wed, 2011-06-01 at 09:58 +0000, Dave Page wrote: >> Hi Guillaume >> >> On Wed, Jan 19, 2011 at 9:40 PM, Guillaume Lelarge >> <guillaume@lelarge.info> wrote: >> > Le 19/01/2011 22:33, Dave Page a écrit : >> >> On Wed, Jan 19, 2011 at 9:30 PM, Guillaume Lelarge >> >> <guillaume@lelarge.info> wrote: >> >>> We had 1.2 support. To have 2.0, we would have to get rid of the >> >>> sl_trigger checks. Or was it dropped along the way of 2.0? >> >> >> >> No idea - I just recall Sachin working on compatibility, and that was >> >> one of/the patch he came of with. >> >> >> > >> > Yeah, you're right. I now see the commit. Which means we have two bugs >> > on 2.0 support. >> >> What happened with this in the end? I've just run into the pg_listener >> bug again. I see from the thread you said you were going to work on >> it, but then we got side-tracked into a discussion on whether we >> should have slony support at all. >> > > I still have it on my todo list. OK, well I'm looking at the moment to see if we can do something with sl_nodelock as Steve suggested, in combination with pg_stat_activity. What was the other bug? I'm not sure I understand what that issue is. -- Dave Page Blog: http://pgsnake.blogspot.com Twitter: @pgsnake EnterpriseDB UK: http://www.enterprisedb.com The Enterprise PostgreSQL Company
On Wed, 2011-06-01 at 16:13 +0000, Dave Page wrote: > On Wed, Jun 1, 2011 at 4:11 PM, Guillaume Lelarge > <guillaume@lelarge.info> wrote: > > On Wed, 2011-06-01 at 09:58 +0000, Dave Page wrote: > >> Hi Guillaume > >> > >> On Wed, Jan 19, 2011 at 9:40 PM, Guillaume Lelarge > >> <guillaume@lelarge.info> wrote: > >> > Le 19/01/2011 22:33, Dave Page a écrit : > >> >> On Wed, Jan 19, 2011 at 9:30 PM, Guillaume Lelarge > >> >> <guillaume@lelarge.info> wrote: > >> >>> We had 1.2 support. To have 2.0, we would have to get rid of the > >> >>> sl_trigger checks. Or was it dropped along the way of 2.0? > >> >> > >> >> No idea - I just recall Sachin working on compatibility, and that was > >> >> one of/the patch he came of with. > >> >> > >> > > >> > Yeah, you're right. I now see the commit. Which means we have two bugs > >> > on 2.0 support. > >> > >> What happened with this in the end? I've just run into the pg_listener > >> bug again. I see from the thread you said you were going to work on > >> it, but then we got side-tracked into a discussion on whether we > >> should have slony support at all. > >> > > > > I still have it on my todo list. > > OK, well I'm looking at the moment to see if we can do something with > sl_nodelock as Steve suggested, in combination with pg_stat_activity. > > What was the other bug? I'm not sure I understand what that issue is. > The issue I wanted to work on is the pg_listener one. pg_listener is available till 9.0. With the rework on the LISTEN/NOTIFY implementation in 9.0, all calls to pg_listener fail because pg_listener isn't available anymore. So we need to find another way to get the listener PID. -- Guillaume http://blog.guillaume.lelarge.info http://www.dalibo.com
On Wed, Jun 1, 2011 at 7:39 PM, Guillaume Lelarge <guillaume@lelarge.info> wrote: > On Wed, 2011-06-01 at 16:13 +0000, Dave Page wrote: >> On Wed, Jun 1, 2011 at 4:11 PM, Guillaume Lelarge >> <guillaume@lelarge.info> wrote: >> > On Wed, 2011-06-01 at 09:58 +0000, Dave Page wrote: >> >> Hi Guillaume >> >> >> >> On Wed, Jan 19, 2011 at 9:40 PM, Guillaume Lelarge >> >> <guillaume@lelarge.info> wrote: >> >> > Le 19/01/2011 22:33, Dave Page a écrit : >> >> >> On Wed, Jan 19, 2011 at 9:30 PM, Guillaume Lelarge >> >> >> <guillaume@lelarge.info> wrote: >> >> >>> We had 1.2 support. To have 2.0, we would have to get rid of the >> >> >>> sl_trigger checks. Or was it dropped along the way of 2.0? >> >> >> >> >> >> No idea - I just recall Sachin working on compatibility, and that was >> >> >> one of/the patch he came of with. >> >> >> >> >> > >> >> > Yeah, you're right. I now see the commit. Which means we have two bugs >> >> > on 2.0 support. >> >> >> >> What happened with this in the end? I've just run into the pg_listener >> >> bug again. I see from the thread you said you were going to work on >> >> it, but then we got side-tracked into a discussion on whether we >> >> should have slony support at all. >> >> >> > >> > I still have it on my todo list. >> >> OK, well I'm looking at the moment to see if we can do something with >> sl_nodelock as Steve suggested, in combination with pg_stat_activity. >> >> What was the other bug? I'm not sure I understand what that issue is. >> > > The issue I wanted to work on is the pg_listener one. pg_listener is > available till 9.0. With the rework on the LISTEN/NOTIFY implementation > in 9.0, all calls to pg_listener fail because pg_listener isn't > available anymore. So we need to find another way to get the listener > PID. Yeah, that was the original issue reported, but you mentioned there was another one? -- Dave Page Blog: http://pgsnake.blogspot.com Twitter: @pgsnake EnterpriseDB UK: http://www.enterprisedb.com The Enterprise PostgreSQL Company
On Wed, 2011-06-01 at 19:45 +0000, Dave Page wrote: > On Wed, Jun 1, 2011 at 7:39 PM, Guillaume Lelarge > <guillaume@lelarge.info> wrote: > > On Wed, 2011-06-01 at 16:13 +0000, Dave Page wrote: > >> On Wed, Jun 1, 2011 at 4:11 PM, Guillaume Lelarge > >> <guillaume@lelarge.info> wrote: > >> > On Wed, 2011-06-01 at 09:58 +0000, Dave Page wrote: > >> >> Hi Guillaume > >> >> > >> >> On Wed, Jan 19, 2011 at 9:40 PM, Guillaume Lelarge > >> >> <guillaume@lelarge.info> wrote: > >> >> > Le 19/01/2011 22:33, Dave Page a écrit : > >> >> >> On Wed, Jan 19, 2011 at 9:30 PM, Guillaume Lelarge > >> >> >> <guillaume@lelarge.info> wrote: > >> >> >>> We had 1.2 support. To have 2.0, we would have to get rid of the > >> >> >>> sl_trigger checks. Or was it dropped along the way of 2.0? > >> >> >> > >> >> >> No idea - I just recall Sachin working on compatibility, and that was > >> >> >> one of/the patch he came of with. > >> >> >> > >> >> > > >> >> > Yeah, you're right. I now see the commit. Which means we have two bugs > >> >> > on 2.0 support. > >> >> > >> >> What happened with this in the end? I've just run into the pg_listener > >> >> bug again. I see from the thread you said you were going to work on > >> >> it, but then we got side-tracked into a discussion on whether we > >> >> should have slony support at all. > >> >> > >> > > >> > I still have it on my todo list. > >> > >> OK, well I'm looking at the moment to see if we can do something with > >> sl_nodelock as Steve suggested, in combination with pg_stat_activity. > >> > >> What was the other bug? I'm not sure I understand what that issue is. > >> > > > > The issue I wanted to work on is the pg_listener one. pg_listener is > > available till 9.0. With the rework on the LISTEN/NOTIFY implementation > > in 9.0, all calls to pg_listener fail because pg_listener isn't > > available anymore. So we need to find another way to get the listener > > PID. > > Yeah, that was the original issue reported, but you mentioned there > was another one? > Yes, we are still trying to scan the sl_trigger table which seems to have been dropped in Slony 2.0. See pgadmin/slony/dlgRepSet.cpp and pgadmin/slony/slTable.cpp. -- Guillaume http://blog.guillaume.lelarge.info http://www.dalibo.com
On 11-06-01 04:01 PM, Guillaume Lelarge wrote: > > Yes, we are still trying to scan the sl_trigger table which seems to > have been dropped in Slony 2.0. See pgadmin/slony/dlgRepSet.cpp and > pgadmin/slony/slTable.cpp. > In 2.0 slony no longer manages enabling triggers on slaves. The slony commands store trigger, drop trigger have gone away along with sl_trigger. users can use the ENABLE/DISABLE TRIGGER commands in PostgreSQL 8.3+ to get similar behaviour (running triggers on slaves).
On Wed, 2011-06-01 at 16:18 -0400, Steve Singer wrote: > On 11-06-01 04:01 PM, Guillaume Lelarge wrote: > > > > > Yes, we are still trying to scan the sl_trigger table which seems to > > have been dropped in Slony 2.0. See pgadmin/slony/dlgRepSet.cpp and > > pgadmin/slony/slTable.cpp. > > > > In 2.0 slony no longer manages enabling triggers on slaves. > The slony commands store trigger, drop trigger have gone away along with > sl_trigger. > Makes sense. I guess we only need to check Slony version, and use sl_trigger only with 1.2. It should be pretty easy on slTable at least. > users can use the ENABLE/DISABLE TRIGGER commands in PostgreSQL 8.3+ to > get similar behaviour (running triggers on slaves). > -- Guillaume http://blog.guillaume.lelarge.info http://www.dalibo.com
On Wed, Jun 1, 2011 at 9:31 PM, Guillaume Lelarge <guillaume@lelarge.info> wrote: > On Wed, 2011-06-01 at 16:18 -0400, Steve Singer wrote: >> On 11-06-01 04:01 PM, Guillaume Lelarge wrote: >> >> > >> > Yes, we are still trying to scan the sl_trigger table which seems to >> > have been dropped in Slony 2.0. See pgadmin/slony/dlgRepSet.cpp and >> > pgadmin/slony/slTable.cpp. >> > >> >> In 2.0 slony no longer manages enabling triggers on slaves. >> The slony commands store trigger, drop trigger have gone away along with >> sl_trigger. >> > > Makes sense. I guess we only need to check Slony version, and use > sl_trigger only with 1.2. It should be pretty easy on slTable at least. I've committed a bunch of changes to master that fix both the sl_trigger and pg_listener issues, as well as some other API changes we hadn't noticed. Just checking 1.12, then I'll push that too. -- Dave Page Blog: http://pgsnake.blogspot.com Twitter: @pgsnake EnterpriseDB UK: http://www.enterprisedb.com The Enterprise PostgreSQL Company
I'm the OP, thanks for continuing to support Slony in pgadmin. I can guarantee at least one person is using it extensively!<br/>