On Tue, 12 Jan 2010, Bob Dusek wrote:
> Each of the concurrent clients does a series of selects, inserts, updates,
> and deletes. The requests would generally never update or delete the same
> rows in a table. However, the requests do generally write to the same
> tables. And, they are all reading from the same tables that they're writing
> to. For the inserts, I imagine they are blocking on access to the sequence
> that controls the primary keys for the insert tables.
I'm going to have to bow out at this stage, and let someone else who knows
more about what gets locked in a transaction help instead. The sequence
may be significant, but I would have thought it would have to be something
a bit bigger that is gumming up the works.
> I'm really sorry. I'm using gmail's interface.
Actually, you weren't doing anything particularly wrong as it turns out.
It is partly a case of alpine being too clever for its own good, just as
Kevin pointed out. My mail reader is taking the "most preferred" mime
alternative, which is the HTML version, and interpreting it to its best
ability, which isn't very well. It is the email that says which
alternative is preferred, by the way. I have just forced alpine to view
the plain text version instead, and it is much better.
> I just saw the "<< Plain Text" formatter at the top of this compose
> message. But, if I convert it to Plain Text now, I may lose my portion
> of the message. I'll use the Plain Text when posting future messages.
To be honest, that's always a good idea, although you didn't actually do
wrong. I do know people whose spam filters immediately discard emails that
contain a HTML alternative - that's taking it to the extreme!
Matthew
--
Beware of bugs in the above code; I have only proved it correct, not
tried it. --Donald Knuth