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 drop our own snapshot before
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.
>array
Tom Lane schrieb:
>"anara...@anarazel.de" 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 loo
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? Do I still need to che
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 that, REINDEX
>CONCURRENTLY did n
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 another review
before the
Peter Geoghegan schrieb:
>On 17 February 2013 18:52, anara...@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
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 vast majority of calls. T
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 destination pointers are sometime
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 (pgsql-hackers@postgresql.org)
To make changes
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 multiple attachments. But my expe
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 way beyond what I'd
>> envisioned f
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 'abc.num_workers = 2' and
>registers as
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
>base/16384/57610
>> blockNum=118571,
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 seems to be the pragmatic
>>> > choice. GetOldestXmin is
Bruce Momjian schrieb:
>On Thu, Oct 11, 2012 at 12:02:26AM +0100, Peter Geoghegan wrote:
>> On 15 September 2012 01:39, Andres Freund
>wrote:
>> > (0008-Introduce-wal-decoding-via-catalog-timetravel.patch)
>>
>> This patch is the 8th of 8 in a patch series that covers different
>> aspects of
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 writer/checkpointer
>writing stuff
>> befor
"anara...@anarazel.de" 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);
>>>
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 it. Am I
>missing
>> somethi
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 READ COMMITTED isolation level (because all
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
>| because it has been d
21 matches
Mail list logo
