2013-02-24 15:03 keltezéssel, Stephen Frost írta:
* Boszormenyi Zoltan (z...@cybertec.at) wrote:
2013-02-24 03:23 keltezéssel, Stephen Frost írta:
No, it isn't. Patches posted to the list should be in context diff
format (and uncompressed unless it's too large) for easier reading.
That avoids having to download it, apply it to a git tree and then
create the diff ourselves. Indeed, the move to git had impact on this
at all.
I remembered this mail from The Master(tm):
http://www.postgresql.org/message-id/21555.1339866...@sss.pgh.pa.us
Which matches exactly what I was saying- context diff provides easier
readind for review purposes, which is presumably what you were looking
to have happen when you posted this patch to the mailing list. And it's
still the documented expectation and project policy, regardless of any
individual's email. If we're going to change it, then the
documentation, et al, should be updated as well.
For my 2c, I still prefer context diffs posted to the mailing lists,
but would also like to see more people posting pull requests. That
doesn't make it project policy though.
So, more than halfof the recently posted patches come
directly from "git diff". The preference has changed.
No, more people have ignored the project policy than not- that doesn't
say anything about the preference or what the policy is.
lock_timeout_wait and lock_timeout_stmt_wait ?
Hm. How about without the "_wait" suffix?
Or lock_timeout vs statement_lock_timeout?
I could live without the _wait suffix, but it occurs to me that none of
these really indicate that statement_lock_timeout is an accumulated
timeout. Perhaps it should say 'total lock wait timeout' or similar?
statement_timeout is the legacy behaviour, it should be kept.
It's behaviour is well understood: the statement finishes under
the specified time or it throws an error. The problem from the
application point of view is that the error can happen while
the tuples are being transferred to the client, so the recordset
can be cut in half.
"lock_timeout_stmt" (or lock_timeout_option = per_statement)
is somewhat extending the statement_timeout as only the
time waiting on locks are counted, so SELECT FOR UPDATE/etc.
may throw an error but if all rows are collected already, or
plain SELECT is run, the application gets them all.
This seems to follow the Microsoft SQL Server semantics:
http://msdn.microsoft.com/en-us/library/ms189470.aspx
The documentation at that link appears to match what 'lock_timeout'
would do. Note that it says 'a lock' here: "When a wait for a lock
exceeds the time-out value, an error is returned.", or have you tested
the actual behavior and seen it treat this value as an accumulated
time across all lock waits for an entire statement?
(Note to myself: don't read with headache.)
I may have misread the MSDN link.
The per-lock lock_timeout was the result of a big Informix
project ported to PostgreSQL, this follows Informix semantics:
http://publib.boulder.ibm.com/infocenter/idshelp/v10/index.jsp?topic=/com.ibm.sqls.doc/sqls788.htm
I agree that the Informix command looks to be per-lock, but based on my
simple reading of both documentation links, I think they're actually the
same behavior and neither is about an accumulated time.
You seem to be right.
Because Timestamp[Tz] is microsecond resolution, and the timeout
GUCs are in milliseconds. Adding up time differences (and rounding
or truncating them to millisecond in the process) would make the
per-statement lock timeout lose precision...
Removing the accumulation-based option would fix that.. :D
To call out the wrath of Tom? No, thanks. :-D
IIRC, he was the one who didn't like the per-lock behaviour
the first time he looked at this patch in an earlier form
back in 2010/2011 and he proposed this use case instead.
If not him, then someone else. I got the idea from this list...
Best regards,
Zoltán Böszörményi
--
----------------------------------
Zoltán Böszörményi
Cybertec Schönig & Schönig GmbH
Gröhrmühlgasse 26
A-2700 Wiener Neustadt, Austria
Web: http://www.postgresql-support.de
http://www.postgresql.at/
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
