Re: [HACKERS] pgsql 7.2.3 crash

2002-12-09 Thread SEGUERRA FRANCIS TED ARANAS
how do i port from mysql to postgresql?... thanks bruce, francis -- ov3rr|d3r ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html

Re: Disabling triggers (was Re: [HACKERS] pgsql 7.2.3 crash)

2002-12-09 Thread Kevin Brown
Joe Conway wrote: The second case is usually something like an insert into the employee table fires off an email to IT to create a login and security to make a badge. Commonly we turn off workflows (by disabling their related triggers) in our development and test databases so someone

Re: Disabling triggers (was Re: [HACKERS] pgsql 7.2.3 crash)

2002-10-22 Thread Andrew Sullivan
On Mon, Oct 14, 2002 at 12:04:14AM -0400, Tom Lane wrote: implication is that its effects would be global to all backends. But the uses that I've seen for suspending trigger invocations would be happier with a local, temporary setting that only affects the current backend. Any thoughts

Re: Disabling triggers (was Re: [HACKERS] pgsql 7.2.3 crash)

2002-10-15 Thread Gavin Sherry
On Mon, 14 Oct 2002, Tom Lane wrote: Gavin Sherry [EMAIL PROTECTED] writes: On Sat, 12 Oct 2002, Joe Conway wrote: Tom Lane wrote: Hackers: we might reasonably fix this by doing a deep copy of the relcache's trigger info during initResultRelInfo(); or we could fix it by getting rid of

Re: [HACKERS] pgsql 7.2.3 crash

2002-10-14 Thread Laurette Cisneros
Yeah I think that could have happened since I was running it several times and had cancelled it (ctrl-c) it a couple of those times. Could be the backend of one cancelled run hadn't finished what it was doing and if that was renabling triggers it could have walked on it. Thanks. L. On Sat, 12

Re: [HACKERS] pgsql 7.2.3 crash

2002-10-14 Thread Tom Lane
Laurette Cisneros [EMAIL PROTECTED] writes: Yeah I think that could have happened since I was running it several times and had cancelled it (ctrl-c) it a couple of those times. Could be the backend of one cancelled run hadn't finished what it was doing and if that was renabling triggers it

Re: [HACKERS] pgsql 7.2.3 crash

2002-10-14 Thread Laurette Cisneros
Great. I am working my way toward 7.3 anyway... Thanks! L. On Mon, 14 Oct 2002, Tom Lane wrote: Laurette Cisneros [EMAIL PROTECTED] writes: Yeah I think that could have happened since I was running it several times and had cancelled it (ctrl-c) it a couple of those times. Could be the

Re: [HACKERS] pgsql 7.2.3 crash

2002-10-13 Thread Bruce Momjian
Gavin Sherry wrote: On Sat, 12 Oct 2002, Joe Conway wrote: Tom Lane wrote: Hackers: we might reasonably fix this by doing a deep copy of the relcache's trigger info during initResultRelInfo(); or we could fix it by getting rid of ri_TrigDesc and re-fetching from the relcache every

Disabling triggers (was Re: [HACKERS] pgsql 7.2.3 crash)

2002-10-13 Thread Tom Lane
Gavin Sherry [EMAIL PROTECTED] writes: On Sat, 12 Oct 2002, Joe Conway wrote: Tom Lane wrote: Hackers: we might reasonably fix this by doing a deep copy of the relcache's trigger info during initResultRelInfo(); or we could fix it by getting rid of ri_TrigDesc and re-fetching from the

Re: Disabling triggers (was Re: [HACKERS] pgsql 7.2.3 crash)

2002-10-13 Thread Marc G. Fournier
On Mon, 14 Oct 2002, Tom Lane wrote: I was wondering whether an ALTER TABLE command is really the right way to approach this. If we had an ALTER-type command, presumably the implication is that its effects would be global to all backends. But the uses that I've seen for suspending trigger

Re: Disabling triggers (was Re: [HACKERS] pgsql 7.2.3 crash)

2002-10-13 Thread Bruce Momjian
Tom Lane wrote: I was wondering whether an ALTER TABLE command is really the right way to approach this. If we had an ALTER-type command, presumably the implication is that its effects would be global to all backends. But the uses that I've seen for suspending trigger invocations would be

Re: Disabling triggers (was Re: [HACKERS] pgsql 7.2.3 crash)

2002-10-13 Thread Joe Conway
Tom Lane wrote: I was wondering whether an ALTER TABLE command is really the right way to approach this. If we had an ALTER-type command, presumably the implication is that its effects would be global to all backends. But the uses that I've seen for suspending trigger invocations would be

Re: Disabling triggers (was Re: [HACKERS] pgsql 7.2.3 crash)

2002-10-13 Thread Tom Lane
Marc G. Fournier [EMAIL PROTECTED] writes: On Mon, 14 Oct 2002, Tom Lane wrote: I was wondering whether an ALTER TABLE command is really the right way to approach this. If we had an ALTER-type command, presumably the implication is that its effects would be global to all backends. But the

Re: [HACKERS] pgsql 7.2.3 crash

2002-10-12 Thread Tom Lane
Laurette Cisneros [EMAIL PROTECTED] writes: I see triggers referenced here and it should be noted that for one of the tables the triggers were first disabled (update pg_class) and re-enabled after the inserts are done (or it takes forever). Did that happen while this backend was running?

Re: [HACKERS] pgsql 7.2.3 crash

2002-10-12 Thread Joe Conway
Tom Lane wrote: Hackers: we might reasonably fix this by doing a deep copy of the relcache's trigger info during initResultRelInfo(); or we could fix it by getting rid of ri_TrigDesc and re-fetching from the relcache every time. The former would imply that trigger state would remain unchanged

Re: [HACKERS] pgsql 7.2.3 crash

2002-10-12 Thread Gavin Sherry
On Sat, 12 Oct 2002, Joe Conway wrote: Tom Lane wrote: Hackers: we might reasonably fix this by doing a deep copy of the relcache's trigger info during initResultRelInfo(); or we could fix it by getting rid of ri_TrigDesc and re-fetching from the relcache every time. The former would

Re: [HACKERS] pgsql 7.2.3 crash

2002-10-09 Thread Tom Lane
Laurette Cisneros [EMAIL PROTECTED] writes: A core file was found in datadir/base/326602604 and a backtrace shows: (gdb) bt #0 DeferredTriggerSaveEvent (relinfo=0x83335f0, event=0, oldtup=0x0, newtup=0x8348150) at trigger.c:2056 Hm. Line 2056 is this: for (i = 0; i

Re: [HACKERS] pgsql 7.2.3 crash

2002-10-09 Thread Laurette Cisneros
On Wed, 9 Oct 2002, Tom Lane wrote: Laurette Cisneros [EMAIL PROTECTED] writes: A core file was found in datadir/base/326602604 and a backtrace shows: (gdb) bt #0 DeferredTriggerSaveEvent (relinfo=0x83335f0, event=0, oldtup=0x0, newtup=0x8348150) at trigger.c:2056 Hm. Line

[HACKERS] pgsql 7.2.3 crash

2002-10-08 Thread Laurette Cisneros
A lot of different things going on but my perl program (whose backend crashed) was doing a lot of insert into table as select * from another table for a lot of different tables. I see triggers referenced here and it should be noted that for one of the tables the triggers were first disabled