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
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.
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?
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
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
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
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
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
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
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)
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
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
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
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
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
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
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
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
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
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
|
20 matches
Mail list logo