Craig Ringer wrote:
[snip]
> If you really want to make somebody cry, I guess you could do it with
> dblink - connect back to your own database from dblink and use a short
> transaction to commit a log record, using table-based (rather than
> sequence) ID generation to ensure that records were inserted in ID
> order. That'd restrict the "critical section" in which your various
> transactions were unable to run concurrently to a much shorter period,
> but would result in a log message being saved even if the transaction
> later aborted. It'd also be eye-bleedingly horrible, to the point where
> even the "send a message from a C function" approach would be nicer.
This will not work for the problem the TS has. Let a single transaction
hang for a long enough time before commit, while others succeed. It will
keep ordering of changes, but commits might come unordered.
The issue is, you don't really have the critical section as you
describe, there is no SINGLE lock you are 'fighting' for.
It will work with an added table write lock (or up), that will be the
lock for your critical section.
In my opinion I would just forget about this one rather quickly as you
more or less proposed...
- Joris