Robert,
On 08/25/2011 04:48 PM, Robert Haas wrote:
> What's a typical message size for imessages?
Most message types in Postgres-R are just a couple bytes in size.
Others, especially change sets, can be up to 8k.
However, I think you'll have an easier job guaranteeing that backends
"consume" their portions of the ring-buffer in time. Plus wrap-around
isn't that much of a problem in your case. (I couldn't drop imessage,
but had to let senders wait).
> Well, one long-running transaction that only has a single XID is not
> really a problem: the snapshot is still small. But one very old
> transaction that also happens to have a large number of
> subtransactions all of which have XIDs assigned might be a good way to
> stress the system.
Ah, right, that's why its a list of transactions in progress and not a
list of completed transactions in SnapshotData... good.
> Each reader decides which data he needs to copy from the buffer, and
> then copies it, and then checks whether any of it got overwritten
> before the copy was completed. So there's a lively possibility that
> the snapshot that was current when the reader began copying it will no
> longer be current by the time he finishes copying it, because a commit
> has intervened. That's OK: it just means that, effectively, the
> snapshot is taken at the moment the start and stop pointers are read,
> and won't take into account any commits that happen later, which is
> exactly what a snapshot is supposed to do anyway.
Agreed, that makes sense. Thanks for explaining.
> There is a hopefully quite small possibility that by the time the
> reader finishes copying it so much new data will have been written to
> the buffer that it will have wrapped around and clobbered the portion
> the reader was interested in. That needs to be rare.
Yeah.
Regards
Markus Wanner