Re: [HACKERS] Command Triggers, patch v11

2012-02-27 Thread anara...@anarazel.de


Tom Lane t...@sss.pgh.pa.us schrieb:

Andres Freund and...@anarazel.de writes:
 I refreshed the patch so it works again on current HEAD. Basically
some 
 trivial fixes and dfd26f9c5f371437f243249025863ea9911aacaa. The
latter doesn't 
 seem necessary to me after the changes, so I simply ditched it. Am I
missing 
 something?

No, that was only needed because execMain.c was overriding somebody
else's tuple receiver.  If you're putting the right receiver into the
QueryDesc to start with, it shouldn't be necessary.

I'm confused by this though:

 This basically includes a revert of
d8fb1f9adbddd1eef123d66a89a9fc0ecd96f60b

I don't find that commit ID anywhere.
That should have been the aforementioned commit. Must have screwed up the 
copypaste buffer. Sorry for that.

Andres

Please excuse the brevity and formatting - I am writing this on my mobile phone.

-- 
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] Command Triggers, patch v11

2012-03-02 Thread anara...@anarazel.de


anara...@anarazel.de and...@anarazel.de schrieb:



Thom Brown t...@linux.com schrieb:

On 2 March 2012 23:33, Thom Brown t...@linux.com wrote:
 On 2 March 2012 22:32, Dimitri Fontaine dimi...@2ndquadrant.fr
wrote:
 test=# CREATE TABLE badname (id int, a int, b text);
 ERROR:  invalid relation name: badname
 test=# CREATE TABLE badname AS SELECT 1::int id, 1::int a,
''::text b;
 SELECT 1

 This doesn't even get picked up by ANY COMMAND.

 I think Andres should add an entry for his patch on the commitfest.
 Is
 it ok?

 I'll try Andres' patch this weekend while I test yours.

Actually no matter which patch I apply first, they cause the other to
fail to apply.
I will try to fix that on the plain tomorrow (to NYC) but I am not yet
sure when/where I will have internet access again.
One more try: To the list.

Andres

Please excuse the brevity and formatting - I am writing this on my mobile phone.

-- 
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] logical decoding - GetOldestXmin

2012-12-18 Thread anara...@anarazel.de
Hi,

Robert Haas robertmh...@gmail.com schrieb:

On Fri, Dec 14, 2012 at 7:19 PM, Andres Freund and...@2ndquadrant.com
wrote:
 On 2012-12-14 14:01:30 -0500, Robert Haas wrote:
 On Fri, Dec 14, 2012 at 6:46 AM, Andres Freund
and...@2ndquadrant.com wrote:
  Just moving that tidbit inside the lock seems to be the pragmatic
  choice. GetOldestXmin is called
 
  * once per checkpoint
  * one per index build
  * once in analyze
  * twice per vacuum
  * once for HS feedback messages
 
  Nothing of that occurs frequently enough that 5 instructions will
make a
  difference. I would be happy to go an alternative path, but right
now I
  don't see any nice one. A already_locked parameter to
GetOldestXmin
  seems to be a cure worse than the disease.

 I'm not sure that would be so bad, but I guess I question the need
to
 do it this way at all.  Most of the time, if you need to advertise
 your global xmin, you use GetSnapshotData(), not GetOldestXmin(),
and
 I guess I'm not seeing why that wouldn't also work here.  Am I dumb?

 I wondered upthread whether that would be better:

 On 2012-12-13 21:03:44 +0100, Andres Freund wrote:
 Another alternative to this would be to get a snapshot with
 GetSnapshotData(), copy the xmin to the logical slot, then call
 ProcArrayEndTransaction(). But that doesn't really seem to be nicer
to
 me.

 Not sure why I considered it ugly anymore, but it actually has a
 noticeable disadvantage. GetOldestXmin is nicer is than
GetSnapshotData
 as the latter set a fairly new xid as xmin whereas GetOldestXmin
returns
 the actual current xmin horizon. Thats preferrable because it allows
us
 to start up more quickly. snapbuild.c can only start building a
snapshot
 once it has seen a xl_running_xact with oldestRunningXid =
 own_xmin. Otherwise we cannot be sure that no relevant catalog tuples
 have been removed.

I'm a bit confused.  Are you talking about the difference between
RecentGlobalXmin and RecentXmin?  I think GetSnapshotData() updates
both.

The problem is that at the time GetSnapshotData returns the xmin horizon might 
have gone upwards and tuples required for decoding might get removed by other 
backends. That needs to be prevented while holding the  procarray lock 
exclusively.

Does it make more sense now?

Andres

--- 
Please excuse the brevity and formatting - I am writing this on my mobile phone.


-- 
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] buffer assertion tripping under repeat pgbench load

2012-12-26 Thread anara...@anarazel.de


Tom Lane t...@sss.pgh.pa.us schrieb:

Greg Smith g...@2ndquadrant.com writes:
 To try and speed up replicating this problem I switched to a smaller 
 database scale, 100, and I was able to get a crash there.  Here's the

 latest:

 2012-12-26 00:01:19 EST [2278]: WARNING:  refcount of
base/16384/57610 
 blockNum=118571, flags=0x106 is 1073741824 should be 0, globally: 0
 2012-12-26 00:01:19 EST [2278]: WARNING:  buffers with non-zero
refcount 
 is 1
 TRAP: FailedAssertion(!(RefCountErrors == 0), File: bufmgr.c,
Line: 
 1720)

 That's the same weird 1073741824 count as before.  I was planning to 
 dump some index info, but then I saw this:

 $ psql -d pgbench -c select relname,relkind,relfilenode from
pg_class 
 where relfilenode=57610
   relname  | relkind | relfilenode
 --+-+-
   pgbench_accounts | r   |   57610

 Making me think this isn't isolated to being an index problem.

Yeah, that destroys my theory that there's something broken about index
management specifically.  Now we're looking for something that can
affect any buffer's refcount, which more than likely means it has
nothing to do with the buffer's contents ...

 I tried 
 to soldier on with pg_filedump anyway.  It looks like the last
version I 
 saw there (9.2.0 from November) doesn't compile anymore:

Meh, looks like it needs fixes for Heikki's int64-xlogrecoff patch.
I haven't gotten around to doing that yet, but would gladly take a
patch if anyone wants to do it.  However, I now doubt that examining
the buffer content will help much on this problem.

Now that we know the bug's reproducible on smaller instances, could you
put together an exact description of what you're doing to trigger
it?  What is the DB configuration, pgbench parameters, etc?

Also, it'd be worthwhile to just repeat the test a few more times
to see if there's any sort of pattern in which buffers get affected.
I'm now suspicious that it might not always be just one buffer,
for example.

I don't think its necessarily only one buffer - if I read the above output 
correctly Greg used the suggested debug output which just put the elog(WARN) 
before the Assert...

Greg, could you output all bad buffers and only assert after the loop if 
there was at least one refcounted buffer?

Andres

--- 
Please excuse the brevity and formatting - I am writing this on my mobile phone.


-- 
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] fix bgworkers in EXEC_BACKEND

2012-12-27 Thread anara...@anarazel.de


Tom Lane t...@sss.pgh.pa.us schrieb:

Andres Freund and...@2ndquadrant.com writes:
 I am still worried about the following scenario in the EXEC_BACKEND
case:

 1) postmaster starts
 2) reads config
 3) executes _PG_init for shared_preload_libraries
 4) library 'abc' gets config value 'abc.num_workers = 2' and
registers as many workers
 5) some time goes by, workers, backends start
 6) abc.num_workers gets changed to 3, SIGHUP

This is broken whether it's EXEC_BACKEND or not: you don't get to
change
anything that determines the number of workers post-startup.
num_workers should have been declared PGC_POSTMASTER.

BTW, I think it happens not to be broken in the non EXEC_BACKEND case because 
the registration point for bgworkers is _PG_init which will only be called once 
without EXEC_BACKEND, so config changes to SIGHUP'able variables won't change a 
thing dangerous as the bgworker stuff is all set up.

Andres


--- 
Please excuse the brevity and formatting - I am writing this on my mobile phone.


-- 
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] enhanced error fields

2013-01-04 Thread anara...@anarazel.de


Robert Haas robertmh...@gmail.com schrieb:

On Sat, Dec 29, 2012 at 4:30 PM, Peter Geoghegan
pe...@2ndquadrant.com wrote:
 Ascertaining the identity of the object in question perfectly
 unambiguously, so that you can safely do something like lookup a
 comment on the object, seems like something way beyond what I'd
 envisioned for this feature. Why should the comment be useful in an
 error handler anyway? At best, that seems like a nice-to-have extra
to
 me. The vast majority are not even going to think about the ambiguity
 that may exist. They'll just write:

 if (constraint_name == upc)
 MessageBox(That is not a valid barcode.);

The people who are content to do that don't need this patch at all.
They can just apply a regexp to the message that comes back from the
server and then set constraint_name based on what pops out of the
regex.  And then do just what you did there.

Easier said than done if you're dealing with pg installations with different 
lc_messages...

Andres

--- 
Please excuse the brevity and formatting - I am writing this on my mobile phone.


-- 
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] Re: [PATCH 1/2] Provide a common malloc wrappers and palloc et al. emulation for frontend'ish environs

2013-01-09 Thread anara...@anarazel.de


Tom Lane t...@sss.pgh.pa.us schrieb:

Andres Freund and...@2ndquadrant.com writes:
 On 2013-01-09 11:27:46 -0500, Tom Lane wrote:
 I'd prefer posting a single message with the discussion and the
 patch(es).  If you think it's helpful to split a patch into separate
 parts for reviewing, add multiple attachments.  But my experience is
 that such separation isn't nearly as useful as you seem to think.

 Well, would it have been better if xlog reading, ilist, binaryheap,
this
 cleanup, etc. have been in the same patch? They have originated out
of
 the same work...
 Even the splitup in this thread seems to have helped as youve jumped
on
 the patches where you could give rather quick input (static
 relpathbackend(), central Assert definitions), probably without
having
 read the xlogreader patch itself...

No, I agree that global-impact things like this palloc rearrangement
are
much better proposed and debated separately than as part of something
like xlogreader.  What I was reacting to was the specific patch set
associated with this thread.  I don't see the point of breaking out a
two-line sub-patch such as you did in
http://archives.postgresql.org/message-id/1357730830-25999-3-git-send-email-and...@2ndquadrant.com

Ah, yes. I See your point. The not all that good reasoning I had in mind was 
that that one should be uncontroversial as it seemed to be the only unchecked 
malloc call in src/bin. So it could be committed independent from the more 
controversial stuff... Same with the single whitespace removal patch upthread...

Andres

--- 
Please excuse brevity and formatting - I am writing this on my mobile phone.


-- 
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] logical changeset generation v4

2013-01-14 Thread anara...@anarazel.de


Josh Berkus j...@agliodbs.com schrieb:

Andreas,

Is there a git fork for logical replication somewhere?

Check the bottom of the email ;)

--- 
Please excuse brevity and formatting - I am writing this on my mobile phone.


-- 
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] Proof of concept: standalone backend with full FE/BE protocol

2012-09-05 Thread anara...@anarazel.de


Tom Lane t...@sss.pgh.pa.us schrieb:

Andres Freund and...@2ndquadrant.com writes:
 I don't find that a convincing comparison. Normally don't need to
shutdown the 
 server between two pg_dump commands. Which very well might be
scripted.

 Especially as for now, without a background writer/checkpointer
writing stuff 
 beforehand, the shutdown checkpoint won't be fast. IO isn't unlikely
if youre 
 doing a pg_dump because of hint bits...

I still think this is a straw-man argument.  There is no expectation
that a standalone PG implementation would provide performance for a
series of standalone sessions that is equivalent to what you'd get from
a persistent server.  If that scenario is what's important to you,
you'd
use a persistent server.  The case where this sort of thing would be
interesting is where minimizing administration complexity (by not
having
a server) is more important than performance.  People currently use,
eg,
SQLite for that type of application, and it's not because of
performance.
I am not saying its bad that it is slower, that's absolutely OK. Just that it 
will take a variable amount of time till you can run pgdump again and its not 
easily detectable without looping and trying again.

Andres


--- 
Please excuse the brevity and formatting - I am writing this on my mobile phone.


-- 
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] overlapping strncpy/memcpy errors via valgrind

2013-02-17 Thread anara...@anarazel.de


Tom Lane t...@sss.pgh.pa.us schrieb:

Andres Freund and...@2ndquadrant.com writes:
 On 2013-02-17 15:10:35 +, Greg Stark wrote:
 Peter G is sitting near me and reminded me that this issue came up
in the
 past. Iirc the conclusion then is that we're calling memcpy where
the
 source and destination pointers are sometimes identical. Tom decided
there
 was really no realistic architecture where that wouldn't work. 

 I am not so convinced that that is safe if libc turns that into some
 optimized string instructions or even PCMPSTR...

What would you envision happening that would be bad?

Afair some of the optimized instructions (like movdqa) don't necessarily work 
if source an target are in the same location. Not sure about it bit I wouldn't 
want to depend on it.

Andres


--- 
Please excuse brevity and formatting - I am writing this on my mobile phone.


-- 
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] overlapping strncpy/memcpy errors via valgrind

2013-02-17 Thread anara...@anarazel.de


Tom Lane t...@sss.pgh.pa.us schrieb:

Boszormenyi Zoltan z...@cybertec.at writes:
 Then, why isn't memcpy() skipped if the source and dest are the same?
 It would be a micro-optimization but a valid one.

No, it'd be more like a micro-pessimization, because the test would be
wasted effort in the vast majority of calls.  The *only* reason to do
this would be to shut up valgrind, and that seems annoying.

I wonder if anyone's tried filing a bug against valgrind to say that it
shouldn't complain about this case.

You already need a suppression file to use valgrind sensibly, its easy enough 
to add it there. Perhaps we should add one to the tree?

--- 
Please excuse brevity and formatting - I am writing this on my mobile phone.


-- 
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] overlapping strncpy/memcpy errors via valgrind

2013-02-17 Thread anara...@anarazel.de


Peter Geoghegan peter.geoghega...@gmail.com schrieb:

On 17 February 2013 18:52, anara...@anarazel.de and...@anarazel.de
wrote:
 You already need a suppression file to use valgrind sensibly, its
easy enough to add it there. Perhaps we should add one to the tree?

Perhaps you should take the time to submit a proper Valgrind patch
first. The current approach of applying the patch that Noah Misch
originally wrote (but did not publicly submit, iirc) on an ad-hoc
basis isn't great. That is what you've done here, right?

What patch are you talking about? I have no knowledge about any pending 
valgrind patches except one I made upstream apply to make pg inside valgrind 
work on amd64.

Andres

--- 
Please excuse brevity and formatting - I am writing this on my mobile phone.


-- 
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] Support for REINDEX CONCURRENTLY

2013-02-27 Thread anara...@anarazel.de
Hi,

Michael Paquier michael.paqu...@gmail.com schrieb:

Andres, Masao, do you need an extra round or review or do you think
this is
ready to be marked as committer?
On my side I have nothing more to add to the existing patches.

I think they do need review before that - I won't be able to do another review 
before the weekend though.

Andres

--- 
Please excuse brevity and formatting - I am writing this on my mobile phone.


-- 
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] REFRESH MATERIALIZED VIEW locklevel

2013-03-07 Thread anara...@anarazel.de


Kevin Grittner kgri...@ymail.com schrieb:

Andres Freund and...@2ndquadrant.com wrote:

 if I understand things correctly REFRESH MATERIALIZED VIEW locks
 the materialized view with an AcessExclusiveLock even if the view
 already contains data.

Yeah.  At the time I had to make a decision on that, REINDEX
CONCURRENTLY did not seem reliable with a weaker lock, and REFRESH
MATERIALIZED VIEW has to rebuild indexes (among other things).  If
we have all the issues sorted out with REINDEX CONCURRENTLY then
the same techniques will probably apply to RMV without too much
difficulty.  It's a bit late to think about that for 9.3, though.

 I am pretty sure that will - understandably - confuse users, so I
 vote for at least including a note about that in the docs.

Will see about working that in.

In the ride home I realized that unless - not that unlikely - you thought about 
something I didtn't  REFRESH will behave similar to TRUNCATE for repeatable 
read+ transactions that only access it after REFRESH finished. That is, they 
will appear empty. If that's the case, it needs to be documented prominently as 
well.

It would be possible to get different behaviour by immediately freezing all 
tuples, but that would also result in violations of visibility by showing  
tuples that are not yet visible.

Andres

--- 
Please excuse brevity and formatting - I am writing this on my mobile phone.


-- 
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] Ignore invalid indexes in pg_dump.

2013-03-28 Thread anara...@anarazel.de


Tom Lane t...@sss.pgh.pa.us schrieb:

Bruce Momjian br...@momjian.us writes:
 Should I just patch pg_upgrade to remove the indisvalid, skip
 indisvalid indexes, and backpatch it?  Users should be using the
 version of pg_upgrade to match new pg_dump.  Is there any case where
 they don't match?  Do I still need to check for indisready?

Yeah, if you can just ignore !indisvalid indexes that should work fine.
I see no need to look at indisready if you're doing that.

You need to look at inisready in 9.2 since thats used for about to be dropped 
indexes. No?

Andres

--- 
Please excuse brevity and formatting - I am writing this on my mobile phone.


-- 
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] Ignore invalid indexes in pg_dump.

2013-03-28 Thread anara...@anarazel.de


Tom Lane t...@sss.pgh.pa.us schrieb:

anara...@anarazel.de and...@anarazel.de writes:
 Tom Lane t...@sss.pgh.pa.us schrieb:
 Yeah, if you can just ignore !indisvalid indexes that should work
fine.
 I see no need to look at indisready if you're doing that.

 You need to look at inisready in 9.2 since thats used for about to be
dropped indexes. No?

No, he doesn't need to look at indisready/indislive; if either of those
flags are off then indisvalid should certainly be off too.  (If it
isn't, queries against the table are already in trouble.)

9.2 represents inisdead as live  !ready, doesn't it? So just looking at 
indislive will include about to be dropped or partially dropped indexes?

Andres

--- 
Please excuse brevity and formatting - I am writing this on my mobile phone.


-- 
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] Why are JSON extraction functions STABLE and not IMMUTABLE?

2013-04-15 Thread anara...@anarazel.de


Andrew Dunstan and...@dunslane.net schrieb:


On 04/15/2013 11:46 AM, Andres Freund wrote:

 Me either. It's an oversight, really. Unless there is any objection
I'll
 change them toot sweet. What about the existing (as of 9.2)
functions?
 ISTM json_in, out, recv, send should also be immutable.
array_to_json,
 row_to_json et all can't be tho.


OK, although these have been like this since 9.2. I'm not sure why 
json_out is immutable but json_in isn't.

Does changing these require a catalog version bump?

Well, you could get away without one since a more permissive value should only 
influence performance and not correctness. But there doesn't yet seem much 
reason to avoid it that much yet. It could cause confusion for someone at some 
point.

Andres

--- 
Please excuse brevity and formatting - I am writing this on my mobile phone.


-- 
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] [ADMIN] Simultaneous index creates on different schemas cause deadlock?

2013-04-25 Thread anara...@anarazel.de


Tom Lane t...@sss.pgh.pa.us schrieb:

Andres Freund and...@2ndquadrant.com writes:
 On 2013-04-25 13:17:31 -0400, Tom Lane wrote:
 Since we know that C.I.C. executes in its own transaction, and there
 can't be more than one on the same table due to locking, it seems to
me
 that it'd be safe to drop our own snapshot before waiting for other
 xacts to end.  That is, we could just rearrange the last few steps
in
 DefineIndex(), taking care to save snapshot-xmin before we destroy
the
 snapshot so that we still have that value to pass to
 GetCurrentVirtualXIDs().
 
 Anybody see a flaw in that solution?

 Except that it still will unnecessarily wait for other CICs, just not
 deadlock, I don't see a problem. We could have a PROC_IN_CIC flag or
 something so we can ignore other index creations, but I am not sure
if
 its worth the complication.

I'm not sure it's a good idea to ignore other CICs altogether --- they
could be executing user-defined index functions that do strange things
like consult other tables.  Since this seems to me to be a bit outside
the intended use-case for CIC anyway, I think it's good enough if they
just don't deadlock

Fine with me, especially as nobody seems to have complained so far other than 
the OP, so it doesn't seem to be to common. 
I don't have access to the code ATM an I wonder whether DROP CONCURRENTLY has a 
similar problem? Depends a bit on how the waiting is done...

Andres

--- 
Please excuse brevity and formatting - I am writing this on my mobile phone.


-- 
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] libpq, PQdescribePrepared - PQftype, PQfmod, no PQnullable

2011-10-06 Thread anara...@anarazel.de


Alex Goncharov alex-goncha...@comcast.net schrieb:

,--- You/Andres (Fri, 7 Oct 2011 02:28:30 +0200) *
|   a lot of cases where the database could deduce (quite easily) that
a
|   result column cannot be null
| Could you quickly explain what exactly you want that information for?
Just 
| because it has been done before doesn't necessarily mean its a good
idea...

I am not writing a database application here (i.e. I am not storing
the data).  I am responding to a client requirement, basically:

  Given a SELECT (or possibly, simpler, a table name), tell me which
  columns are non-nullable?
That doesnt explain why it's  needed. To get community buyin into a feature the 
community - or at least parts of it - need to understand why its needed.

Greetings, Andres



-- 
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] testing ProcArrayLock patches

2011-11-18 Thread anara...@anarazel.de


Kevin Grittner kevin.gritt...@wicourts.gov schrieb:

Robert Haas robertmh...@gmail.com wrote:
 
 Any chance you can run oprofile (on either branch, don't really
 care) against the 32 client test and post the results?
 
Besides the other changes we discussed, I boosted scale to 150 and
ran at READ COMMITTED isolation level (because all threads promptly
crashed and burned at REPEATABLE READ -- we desperately need a
pgbench option to retry a transaction on serialization failure). 
The oprofile hot spots at half a percent or higher:
 
CPU: Intel Core/i7, speed 2262 MHz (estimated)
Counted CPU_CLK_UNHALTED events (Clock cycles when not halted) with
a unit mask of 0x00 (No unit mask) count 10
samples  %image name  symbol name
9333944.9651  postgresAllocSetAlloc
8484764.5134  postgresbase_yyparse
7195153.8274  postgresSearchCatCache
4612752.4537  postgreshash_search_with_hash_value
4264112.2682  postgresGetSnapshotData
3229381.7178  postgresLWLockAcquire
3222361.7141  postgrescore_yylex
3054711.6249  postgresMemoryContextAllocZeroAligned
2815431.4976  postgresexpression_tree_walker
2702411.4375  postgresXLogInsert
2348991.2495  postgresMemoryContextAlloc
2101371.1178  postgresScanKeywordLookup
1848570.9833  postgresheap_page_prune
1736080.9235  postgreshash_any
1530110.8139  postgres_bt_compare
1445380.7689  postgresnocachegetattr
1314660.6993  postgresfmgr_info_cxt_security
1310010.6968  postgresgrouping_planner
1308080.6958  postgresLWLockRelease
1241120.6602  postgresPinBuffer
1207450.6423  postgresLockAcquireExtended
1129920.6010  postgresExecInitExpr
1128300.6002  postgreslappend
1123110.5974  postgresnew_list
1103680.5871  postgrescheck_stack_depth
1060360.5640  postgresAllocSetFree
1025650.5456  postgresMemoryContextAllocZero
94689 0.5037  postgresSearchSysCache
That profile looks like you ran pgbench with -m simple. How does it look with 
prepared instead?

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



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