On 12/13/06, Andrew Sullivan <[EMAIL PROTECTED]> 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
_______________________________________________ Slony1-general mailing list [email protected] http://gborg.postgresql.org/mailman/listinfo/slony1-general
