Neil Conway said:
> On 2-Apr-04, at 5:16 PM, Andrew Dunstan wrote:
>> If' we're going to have this shouldn't it be a proper command?
>
> Why? What benefit would this offer over implementing this feature as a
> function?
>
psql help
cheers
andrew
---(end of broadcast)--
Tom Lane wrote:
Josh Berkus <[EMAIL PROTECTED]> writes:
Killing backends with runaway queries is a routine administrative
task.
Cancelling runaway queries is a routine task. I'm less convinced that a
remote kill (ie SIGTERM) facility is such a great idea.
Of course, cancelling runaway queries
Tom Lane wrote:
If you really want the trigger API for PL/R to be indistinguishable from
the function-call API, then I think you will need to copy the passed
tuple and insert type information. This is more or less what
ExecEvalVar does now in the whole-tuple case (the critical code is
actually in
Josh Berkus <[EMAIL PROTECTED]> writes:
> Killing backends with runaway queries is a routine administrative
> task.
Cancelling runaway queries is a routine task. I'm less convinced that a
remote kill (ie SIGTERM) facility is such a great idea.
regards, tom lane
-
Tom Lane wrote:
Joe Conway <[EMAIL PROTECTED]> writes:
For triggers, I was previously building up the arguments thus:
slot = TupleDescGetSlot(tupdesc);
slot->val = trigdata->tg_trigtuple;
arg[7] = PointerGetDatum(slot);
I suppose now I should do this instead?
arg[7] = PointerGet
Joe Conway <[EMAIL PROTECTED]> writes:
>> Any ideas why the trigger tuple type isn't registered, or what I'm doing
>> wrong?
> A little more info on this. It appears that the tuple type is set to
> either 2249 (RECORDOID) or 0.
After further thought, we could possibly make it work for BEFORE
tr
Joe Conway <[EMAIL PROTECTED]> writes:
> For triggers, I was previously building up the arguments thus:
> slot = TupleDescGetSlot(tupdesc);
> slot->val = trigdata->tg_trigtuple;
> arg[7] = PointerGetDatum(slot);
> I suppose now I should do this instead?
> arg[7] = PointerGetDat
On 2-Apr-04, at 5:16 PM, Andrew Dunstan wrote:
If' we're going to have this shouldn't it be a proper command?
Why? What benefit would this offer over implementing this feature as a
function?
-Neil
---(end of broadcast)---
TIP 1: subscribe and unsub
This is a commonly requested feature by DBA's migrating from SQL Server and
Oracle.In those databases, there is a GUI to monitor database requests,
and potentially kill them to resolve deadlocks or runaway queries (though, in
the case of SQL server, it does not work). Right now, it is very
Tom,
> > Seems like useful functionality. Right now, how does an administrator
> > kill another backend from psql? They can't.
>
> The question to ask is "should they be able to?"
And the answer is, "Yes".
This is a commonly requested feature by DBA's migrating from SQL Server and
Oracle.
Joe Conway wrote:
Given the above changes, it's almost working now -- only problem left is
with triggers:
insert into foo values(11,'cat99',1.89);
+ ERROR: record type has not been registered
+ CONTEXT: In PL/R function rejectfoo
delete from foo;
+ ERROR: cache lookup failed for type 0
+ C
Greg Stark wrote:
Joe Conway <[EMAIL PROTECTED]> writes:
I agree. I had always envisioned something exactly like that once we supported
NULL elements. As far as the implementation goes, I think it would be very
similar to tuples -- a null bitmask that would exist if any elements are NULL.
Well you
Tom Lane wrote:
No, it's a HeapTupleHeader pointer. You need to reconstruct a
HeapTuple on top of that to work with heap_getattr and most other
core backend routines.
Thanks.
For triggers, I was previously building up the arguments thus:
slot = TupleDescGetSlot(tupdesc);
slot->val = trig
Joe Conway <[EMAIL PROTECTED]> writes:
> Greg Stark wrote:
> > This really ought to work, it obviously shouldn't allow you to set a[5] and
> > then surreptitiously move it to a[1]. But nor should it generate an error,
> > since I may well have a specific meaning for a[5] and may be planning to fi
Tom Lane wrote:
It's the oldest xmin of any transaction that's local to your database,
but those xmin values themselves were computed globally --- so what
matters is the oldest transaction that was running when any local
transaction started. In this case I expect it's the VACUUM's own
transaction
> Tom Lane wrote:
>>> it would definitely need to be a lot more constrained than
>>> send-any-signal-to-any-postgres-process ... even for a superuser,
>>> that's a mighty fat-gauge foot-gun.
>
>> What sort of constraints do you have in mind?
>
>I'd limit it to SIGINT (query cancel) and SIGTERM (fas
16 matches
Mail list logo
