Re: [HACKERS] Patch: show relation and tuple infos of a lock to acquire

2014-01-01 Thread Christian Kruse
Hi, On 31/12/13 13:56, Peter Geoghegan wrote: I think that this is a worthwhile effort, but like Tom I don't think that it's universally true that these waiters are waiting on a tuple lock. Most obviously, the XactLockTableWait() call you've modified within nbtinsert.c is not. This is why I

Re: [HACKERS] Patch: show relation and tuple infos of a lock to acquire

2014-01-01 Thread Christian Kruse
On 31/12/13 11:36, Tom Lane wrote: Christian's idea of a context line seems plausible to me. I don't care for this implementation too much --- a global variable? Ick. Make a wrapper function for XactLockTableWait instead, please. Point taken. You are right. And I'm not real sure that

Re: [HACKERS] Patch: show relation and tuple infos of a lock to acquire

2014-01-01 Thread Simon Riggs
On 31 December 2013 17:06, Simon Riggs si...@2ndquadrant.com wrote: On 31 December 2013 16:36, Tom Lane t...@sss.pgh.pa.us wrote: Simon Riggs si...@2ndquadrant.com writes: On 31 December 2013 09:12, Christian Kruse christ...@2ndquadrant.com wrote: Output with patch: LOG: process 24774

Re: [HACKERS] [bug fix] connection service file doesn't take effect with ECPG apps

2014-01-01 Thread Michael Meskes
On Sun, Dec 29, 2013 at 05:35:22AM +0900, MauMau wrote: Your test case seems different from my original mail. In my test As it turned out that wasn't the problem. It was simple typo on my side. Sorry for the hassle. However, I'd prefer to solve the problem slightly differently by not creating

[HACKERS] Fixing pg_basebackup with tablespaces found in $PGDATA

2014-01-01 Thread Dimitri Fontaine
Hi, As much as I've seen people frown upon $subject, it still happens in the wild, and Magnus seems to agree that the current failure mode of our pg_basebackup tool when confronted to the situation is a bug. So here's a fix, attached. To reproduce, mkdir -p $PGDATA/tbs/foo then CREATE

Re: [HACKERS] Logging WAL when updating hintbit

2014-01-01 Thread Robert Haas
On Tue, Dec 24, 2013 at 7:31 PM, Michael Paquier michael.paqu...@gmail.com wrote: Yep, finding all the code paths with a single keyword is usually a good thing. Attached is a purely-aesthetical patch that updates the internal variable name to wal_log_hints. There are many GUC parameters other

Re: [HACKERS] Logging WAL when updating hintbit

2014-01-01 Thread Michael Paquier
On Thu, Jan 2, 2014 at 10:21 AM, Robert Haas robertmh...@gmail.com wrote: On Tue, Dec 24, 2013 at 7:31 PM, Michael Paquier michael.paqu...@gmail.com wrote: Yep, finding all the code paths with a single keyword is usually a good thing. Attached is a purely-aesthetical patch that updates the

Re: [HACKERS] Show lossy heap block info in EXPLAIN ANALYZE for bitmap heap scan

2014-01-01 Thread Robert Haas
On Fri, Dec 27, 2013 at 1:47 AM, Etsuro Fujita fujita.ets...@lab.ntt.co.jp wrote: I wrote: Robert Haas wrote: I'd be wary of showing a desired value unless it's highly likely to be accurate. The desired value is accurately estimated based on (a) the total number of exact/lossy pages

Re: [HACKERS] preserving forensic information when we freeze

2014-01-01 Thread Robert Haas
On Fri, Dec 27, 2013 at 9:24 PM, Stephen Frost sfr...@snowman.net wrote: I'm not sure what you mean by doesn't work, because it clearly does work. I've already posted a patch. You may find it ugly, but that's not the same as not working. I meant *practically*, it doesn't work. By which, I

Re: [HACKERS] Bogus error handling in pg_upgrade

2014-01-01 Thread Robert Haas
On Sun, Dec 29, 2013 at 12:25 AM, Tom Lane t...@sss.pgh.pa.us wrote: check_ok() is particularly badly named, since it contains not one iota of error checking. misleadingly_claim_ok() would be a better name. That's pretty hilarious, actually. I think it probably started as a copy of initdb.c's

Re: [HACKERS] Planning time in explain/explain analyze

2014-01-01 Thread Robert Haas
On Sat, Dec 28, 2013 at 11:32 PM, Andreas Karlsson andr...@proxel.se wrote: New version of the patch with updated documentation and which does not display the planning time when the COSTS are off. I will add it to the next commitfest. I'm wondering whether the time should be stored inside the

[HACKERS] more psprintf() use

2014-01-01 Thread Peter Eisentraut
Here is a more or less straightforward patch to add more use of psprintf() in place of hardcoded palloc(N) + sprintf() and the like. From 4a476ed7a37222d87fed068972c88ed884cf25c3 Mon Sep 17 00:00:00 2001 From: Peter Eisentraut pete...@gmx.net Date: Wed, 1 Jan 2014 22:09:21 -0500 Subject: [PATCH]

Re: [HACKERS] more psprintf() use

2014-01-01 Thread Robert Haas
On Wed, Jan 1, 2014 at 10:14 PM, Peter Eisentraut pete...@gmx.net wrote: Here is a more or less straightforward patch to add more use of psprintf() in place of hardcoded palloc(N) + sprintf() and the like. Looks nifty. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise

Re: [HACKERS] preserving forensic information when we freeze

2014-01-01 Thread Greg Stark
I fail to see why. What is so ugly about this: select x.* from pgbench_accounts a, pg_tuple_header(a.tableoid, a.ctid) x; Two points: 1) it's a bit weird to go to this effort to eliminate system columns by using a scheme that depends on having a system column -- ctid 2) refetching a row

Re: [HACKERS] more psprintf() use

2014-01-01 Thread Heikki Linnakangas
On 01/02/2014 05:14 AM, Peter Eisentraut wrote: diff --git a/contrib/hstore/hstore_io.c b/contrib/hstore/hstore_io.c index 772a5ca..8331a56 100644 --- a/contrib/hstore/hstore_io.c +++ b/contrib/hstore/hstore_io.c @@ -1114,11 +1114,7 @@ HEntry *entries = ARRPTR(in); if (count