Re: [HACKERS] literature on write-ahead logging

2011-06-08 Thread Merlin Moncure 
On Wed, Jun 8, 2011 at 11:24 PM, Robert Haas robertmh...@gmail.com wrote:
 I did a brief literature search for papers on breaking the
 WAL-serialization bottleneck today and hit upon this:

 Aether: A Scalable Approach to Logging, Ryan Johnson, Ippokratis Pandis, et 
 al.
 http://infoscience.epfl.ch/record/149436/files/vldb10aether.pdf

 Section 5 appears to be the most relevant to our problems with WALInsertLock.

 They reject the approach that I proposed, wherein WAL is generated by
 individual backends in their own queues and serialized later: While a
 total ordering is not technically required for correctness, valid
 partial orders tend to be too complex and interdependent to be worth
 pursuing as a performance optimization; see also appendix A.5, which
 may be succinctly summarized as no one does that.

heh -- makes total sense.  great stuff.

merlin

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] smallserial / serial2

2011-06-08 Thread Brar Piening 
On Wed, 8 Jun 2011 19:29:42 -0400, Robert Haas 
robertmh...@gmail.com wrote:

You should also change the status to either Waiting on Author or
Ready for Committer based on the content of the review.  I think the
latter would be appropriate since your review seems to have been
favorable.
Well - not being a review profi I was thinking that the appropriate 
status would be waiting for some more on list discussion about whether 
to include this or waiting for a more experienced reviewer  to see if 
my review is ok (which could admittedly be the commiter).


I've changed it.

Regards,

Brar


--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] Error in PQsetvalue

2011-06-08 Thread Pavel Golub 
Hello, Merlin.

You wrote:

MM On Wed, Jun 8, 2011 at 11:03 AM, Tom Lane t...@sss.pgh.pa.us wrote:
 Merlin Moncure mmonc...@gmail.com writes:
 On Wed, Jun 8, 2011 at 10:18 AM, Tom Lane t...@sss.pgh.pa.us wrote:
 Merlin Moncure mmonc...@gmail.com writes:
 I went ahead and tested andrew's second patch -- can we get this
 reviewed and committed?

 Add it to the upcoming commitfest.

 It's a client crashing bug in PQsetvalue that goes back to 9.0 :(.

 I was under the impression that this was extending PQsetvalue to let it
 be used in previously unsupported ways, ie, to modify a server-returned
 PGresult.  That's a feature addition, not a bug fix.

MM It's neither -- it's documented libpq behavior: The function will
MM automatically grow the result's internal tuples array as needed.
MM However, the tup_num argument must be less than or equal to PQntuples,
MM meaning this function can only grow the tuples array one tuple at a
MM time. But any field of any existing tuple can be modified in any
MM order. 

MM Andrew was briefly flirting with a proposal to tweak this behavior,
MM but withdrew the idea.

 it's a feature addition I approve of.  I think serious consideration
 ought to be given to locking down returned results so PQsetvalue refuses
 to touch them, instead.  Otherwise we're likely to find ourselves unable
 to make future optimizations because we have to support this
 barely-used-by-anybody corner case.

Do I understand correctly that there is no any chance at all to have function
like PQdeleteTuple in libpq? (see my message PQdeleteTuple
function in libpq on Wed, 1 Jun 2011)

MM I think that's debatable, but I'm not going to argue this yea or nea.
MM But I will say that maybe we shouldn't confuse behavior issues with
MM bug fix either way...patch the bug, and we can work up a patch to lock
MM down the behavior and the docs if you want it that way, but maybe we
MM could bikeshed a bit on that point.

MM merlin



-- 
With best wishes,
 Pavel  mailto:pa...@gf.microolap.com


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

<    1   2