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 doe
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
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 a
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
> >>
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
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
> trigger
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
"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.
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 b
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 b
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 trigg
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 fr
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 relc
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
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
thr
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 ru
On Wed, 9 Oct 2002, Tom Lane wrote:
> Laurette Cisneros <[EMAIL PROTECTED]> writes:
> > A core file was found in /base/326602604
> > and a backtrace shows:
> > (gdb) bt
> > #0 DeferredTriggerSaveEvent (relinfo=0x83335f0, event=0, oldtup=0x0,
> > newtup=0x8348150) at trigger.c:2056
>
> Hm.
Laurette Cisneros <[EMAIL PROTECTED]> writes:
> A core file was found in /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 < ntriggers
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 (upda
19 matches
Mail list logo
