On Wed, 8 Sep 2004, Tom Lane wrote:
> I wrote:
> > Actually, I'd really like to get it back down to the 7.4 size, which was
> > already too big :-(. That might be a vain hope though.
>
> As long as we're talking about hack-slash-and-burn on this data
> structure ...
>
> The cases where people get
I wrote:
> Actually, I'd really like to get it back down to the 7.4 size, which was
> already too big :-(. That might be a vain hope though.
As long as we're talking about hack-slash-and-burn on this data
structure ...
The cases where people get annoyed by the size of the deferred trigger
list a
Stephan Szabo <[EMAIL PROTECTED]> writes:
> On Wed, 8 Sep 2004, Tom Lane wrote:
>> Yeah, I had come to the same conclusion after more thought. But we
>> could certainly aggregate all the similar events generated by a single
>> query into a common status structure.
> Definately. The ~20 byte/row
Stephan Szabo <[EMAIL PROTECTED]> writes:
> On Wed, 8 Sep 2004, Tom Lane wrote:
>> It wouldn't quite work to use just transaction ID as the marker, since
>> the inner SET CONSTRAINTS is very possibly done without using a
>> subtransaction. But command ID or query nesting level or some such
>> woul
Stephan Szabo <[EMAIL PROTECTED]> writes:
> Definately. The ~20 byte/row gain for large updates/insert/delete is
> worth it. I think it'd actually increase the size for the single row case
> since we'd have the pointer to deal with (we could use a flag that tells
> us whether this item actually ha
On Wed, 8 Sep 2004, Tom Lane wrote:
> Stephan Szabo <[EMAIL PROTECTED]> writes:
> > On Wed, 8 Sep 2004, Tom Lane wrote:
> >> As long as we're talking about hack-slash-and-burn on this data
> >> structure ...
>
> > Where the OtherInformation could be shared within the statement (for
> > identical e
Stephan Szabo <[EMAIL PROTECTED]> writes:
> On Wed, 8 Sep 2004, Tom Lane wrote:
>> As long as we're talking about hack-slash-and-burn on this data
>> structure ...
> Where the OtherInformation could be shared within the statement (for
> identical events)? I think it'd be problematic to try sharing
Stephan Szabo <[EMAIL PROTECTED]> writes:
> On Wed, 8 Sep 2004, Tom Lane wrote:
>> I think the main concern here would be the space cost of
>> adding still another field to the trigger records ... is it worth it?
> Would it be possible to basically alias the space for dte_done_xid to hold
> either
On Wed, 8 Sep 2004, Tom Lane wrote:
> Hmm. Here's a slightly off the wall idea: following SET CONSTRAINTS,
> scan the pending-triggers list twice. The first time, you determine
> which triggers you need to fire, and mark them "in progress" by your
> transaction. The second time through, you act
Stephan Szabo <[EMAIL PROTECTED]> writes:
> Okay. The former seems odd to me, especially for exception handling since
> Trigger D is making Trigger C immediate, but it could receive exceptions
> for Trigger B, so it couldn't assume it knows the source of the exception
> (C or something done due to
On Wed, 8 Sep 2004, Tom Lane wrote:
> Stephan Szabo <[EMAIL PROTECTED]> writes:
> > Right, but if we search the entire trigger queue from the beginning
> > looking for all triggers now immediate and fire them in the EndQuery of
> > the set constraints statement contained in D, we'd potentially ge
Stephan Szabo <[EMAIL PROTECTED]> writes:
> Right, but if we search the entire trigger queue from the beginning
> looking for all triggers now immediate and fire them in the EndQuery of
> the set constraints statement contained in D, we'd potentially get an
> ordering like:
> Trigger A start
> Tr
On Tue, 7 Sep 2004, Tom Lane wrote:
> Stephan Szabo <[EMAIL PROTECTED]> writes:
> > Hmm, if our current state of deferred triggers look like (in order)
> > Trigger A
> > Trigger B
> > Trigger C
>
> > and triggers A and B are made immediate and scanning begins at the
> > beginning of the queue
Stephan Szabo <[EMAIL PROTECTED]> writes:
> Hmm, if our current state of deferred triggers look like (in order)
> Trigger A
> Trigger B
> Trigger C
> and triggers A and B are made immediate and scanning begins at the
> beginning of the queue again, during the execution of the Trigger A
> trigge
On Tue, 7 Sep 2004, Tom Lane wrote:
> Stephan Szabo <[EMAIL PROTECTED]> writes:
> > I misread then. I thought that you were proposing that EndQuery look only
> > at the per-query list and then add the deferred items that weren't fired
> > to the main list but never go over that list.
>
> It will
Stephan Szabo <[EMAIL PROTECTED]> writes:
> I misread then. I thought that you were proposing that EndQuery look only
> at the per-query list and then add the deferred items that weren't fired
> to the main list but never go over that list.
It will have to re-examine the tail of the main list, as
On Tue, 7 Sep 2004, Tom Lane wrote:
> Stephan Szabo <[EMAIL PROTECTED]> writes:
> > If I'm reading the above correctly, I think DeferredTriggerSetState may
> > need to change a little if EndQuery works on a separate list of triggers
> > because I believe set constraints immediate currently depends
Stephan Szabo <[EMAIL PROTECTED]> writes:
> If I'm reading the above correctly, I think DeferredTriggerSetState may
> need to change a little if EndQuery works on a separate list of triggers
> because I believe set constraints immediate currently depends on EndQuery
> going over the entire list of
On Tue, 7 Sep 2004, Tom Lane wrote:
> * EndQuery processes and discards immediate-mode AFTER trigger events for the
> current query. Any remaining events (ie, DEFERRED triggers) are appended
> to the current (sub)transaction's list of pending deferred triggers.
> Note that even inside a subtrans
Here's another thing that I think it would be good to fix in 8.0.
We've had numerous complaints before about RI constraints not firing
inside PL functions; a recent one is
http://archives.postgresql.org/pgsql-bugs/2004-09/msg00020.php
I think also that the current behavior violates the SQL spec.
S
20 matches
Mail list logo
