On 12/13/06, Andrew Sullivan <ajs at crankycanuck.ca> wrote:
>
> What _used_ to happen is that, if the bit of memory that would
> correspond to that data had some other Postgres-shaped data in it,
> you'd get that instead.  This was a simple memory-bounds problem.
> I'm not looking at the code right now, but I think what happens now
> is that the trigger bails out if it discovers that it can't write its
> data safely (so the bound of the memory allocated is not enough for
> the data you have).  Since your additional data might fit in the size
> the trigger has allocated, you might get lucky.  But if your row gets
> wider, it'll stop working then.


that's one hell of a good answer. really - this is something i was hoping to
get.
i will of course investigate it further - possibly using my inhouse things.
question is - do you have any estimates at what kind of change does it
break?
i mean - if i have a table like this:
create table test (id bigserial primary key, some_value timestamptz);
should it break closer to (add another 10 bytes in fields) or (add another
6kilobytes in fields) ?

What Jan _refused_ to do was check to see, every time, that the
> trigger had an accurate picture of what it was replicating, precisely
> because that would be slow and it would be the result of operators
> abusing the system.


of course. that would not be good approach.

If you really want to understand this, you need to look at the
> trigger code.
>

we did, but (as it appears) not close enough. though i'm not sure if i will
be able to dig it further this week :(

The second thing.  It is, as I said, deterministic, but a function of
> a large number of variables.
>

that's not good  - i was rather hoping that there is a well-known
simple(let's say up to 15 steps) procedure which show how and when it
breaks.
bad luck though.

thanks again - the information about preallocated memory size makes perfect
sense, and i will definitelly investigate it further.

best regards,

depesz

-- 
http://www.depesz.com/ - nowy, lepszy depesz
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://gborg.postgresql.org/pipermail/slony1-general/attachments/20061213/89ed50a1/attachment.html