Re: [HACKERS] [ADMIN] Simultaneous index creates on different schemas cause deadlock?

2013-04-25 Thread
Tom Lane schrieb: Andres Freund 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

Re: [HACKERS] Why are JSON extraction functions STABLE and not IMMUTABLE?

2013-04-15 Thread
Andrew Dunstan 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.

Re: [HACKERS] Ignore invalid indexes in pg_dump.

2013-03-28 Thread
Tom Lane schrieb: Bruce Momjian 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?

Re: [HACKERS] Ignore invalid indexes in pg_dump.

2013-03-28 Thread
Tom Lane schrieb: writes: Tom Lane 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


2013-03-07 Thread
Kevin Grittner schrieb: Andres Freund 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


2013-02-27 Thread
Hi, Michael Paquier 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

Re: [HACKERS] overlapping strncpy/memcpy errors via valgrind

2013-02-17 Thread
Tom Lane schrieb: Andres Freund 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

Re: [HACKERS] overlapping strncpy/memcpy errors via valgrind

2013-02-17 Thread
Tom Lane schrieb: Boszormenyi Zoltan 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

Re: [HACKERS] overlapping strncpy/memcpy errors via valgrind

2013-02-17 Thread
Peter Geoghegan schrieb: On 17 February 2013 18:52, 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

Re: [HACKERS] logical changeset generation v4

2013-01-14 Thread
Josh Berkus 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 (

Re: [HACKERS] Re: [PATCH 1/2] Provide a common malloc wrappers and palloc et al. emulation for frontend'ish environs

2013-01-09 Thread
Tom Lane schrieb: Andres Freund 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

Re: [HACKERS] enhanced error fields

2013-01-04 Thread
Robert Haas schrieb: On Sat, Dec 29, 2012 at 4:30 PM, Peter Geoghegan 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

Re: [HACKERS] fix bgworkers in EXEC_BACKEND

2012-12-27 Thread
Tom Lane schrieb: Andres Freund 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

Re: [HACKERS] buffer assertion tripping under repeat pgbench load

2012-12-26 Thread
Tom Lane schrieb: Greg Smith 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

Re: [HACKERS] logical decoding - GetOldestXmin

2012-12-18 Thread
Hi, Robert Haas schrieb: On Fri, Dec 14, 2012 at 7:19 PM, Andres Freund wrote: On 2012-12-14 14:01:30 -0500, Robert Haas wrote: On Fri, Dec 14, 2012 at 6:46 AM, Andres Freund wrote: Just moving that tidbit inside the lock

Re: [HACKERS] Proof of concept: standalone backend with full FE/BE protocol

2012-09-05 Thread
Tom Lane schrieb: Andres Freund 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

Re: [HACKERS] Command Triggers, patch v11

2012-03-02 Thread schrieb: Thom Brown schrieb: On 2 March 2012 23:33, Thom Brown wrote: On 2 March 2012 22:32, Dimitri Fontaine wrote: test=# CREATE TABLE badname (id int, a int, b text); ERROR:  invalid relation

Re: [HACKERS] Command Triggers, patch v11

2012-02-27 Thread
Tom Lane schrieb: Andres Freund 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

Re: [HACKERS] testing ProcArrayLock patches

2011-11-18 Thread
Kevin Grittner schrieb: Robert Haas 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

Re: [HACKERS] libpq, PQdescribePrepared - PQftype, PQfmod, no PQnullable

2011-10-06 Thread
Alex Goncharov 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 |