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
> 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 co
On Wed, Jan 1, 2014 at 10:14 PM, Peter Eisentraut 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 PostgreSQL Compa
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
Date: Wed, 1 Jan 2014 22:09:21 -0500
Subject: [PATCH] Add more use of
On Sat, Dec 28, 2013 at 11:32 PM, Andreas Karlsson 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 PlannedStmt
n
On Sun, Dec 29, 2013 at 12:25 AM, Tom Lane 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 check_ok(), and
On Fri, Dec 27, 2013 at 9:24 PM, Stephen Frost 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 mean, "it
On Fri, Dec 27, 2013 at 1:47 AM, Etsuro Fujita
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 stored i
On Thu, Jan 2, 2014 at 10:21 AM, Robert Haas wrote:
> On Tue, Dec 24, 2013 at 7:31 PM, Michael Paquier
> 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_h
On Tue, Dec 24, 2013 at 7:31 PM, Michael Paquier
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 than wal_log
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 TABLESPACE
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
On 31 December 2013 17:06, Simon Riggs wrote:
> On 31 December 2013 16:36, Tom Lane wrote:
>> Simon Riggs writes:
>>> On 31 December 2013 09:12, Christian Kruse
>>> wrote:
Output with patch:
LOG: process 24774 acquired ShareLock on transaction 696 after 11688.720
ms
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 sh
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
15 matches
Mail list logo
