On 04/03/2013 12:59 AM, Tom Lane wrote:
> I wrote:
>> I think the simplest fix is to insert "PG_SETMASK(&UnBlockSig)" into
>> StatementCancelHandler() and any other handlers that might exit via
>> longjmp. I'm a bit inclined to only do this on platforms where a
>> problem is demonstrable, which so
On Wednesday, April 03, 2013 2:23 AM Greg Smith wrote:
> On 4/1/13 5:44 AM, Amit Kapila wrote:
>
> > I think in that case we can have 3 separate patches
> > 1. Memory growth defect fix
> > 2. Default postgresql.conf to include config directory and SET
> Persistent
> > into single file implementati
On Tuesday, April 02, 2013 9:49 PM Peter Eisentraut wrote:
> I'm going to ignore most of the discussion that led up to this and give
> this patch a fresh look.
Thank you.
> +
> + SET PERSISTENT max_connections To 10;
> +
>
> The To should probably be capitalized.
Okay, shall fix it.
> I dou
This commit introduced a problem with wal_keep_segments:
commit dfda6ebaec6763090fb78b458a979b558c50b39b
Author: Heikki Linnakangas
Date: Sun Jun 24 18:06:38 2012 +0300
Don't waste the last segment of each 4GB logical log file.
in a side window do: watch "ls -lrt /tmp/data/pg_xlog"
dfda
I found that psql will crash if given a PSQLRC value containing a tilde:
$ PSQLRC="~/x" psql test
*** glibc detected *** psql: free(): invalid pointer:
0x7fffb7c933ec ***
This is on Debian Squeeze 6.0.7. The fix is to pstrdup() the value
returned by getenv(), so it can be fr
I wrote:
> I think the simplest fix is to insert "PG_SETMASK(&UnBlockSig)" into
> StatementCancelHandler() and any other handlers that might exit via
> longjmp. I'm a bit inclined to only do this on platforms where a
> problem is demonstrable, which so far is only OpenBSD. (You'd
> think that all
Hackers,
I am working on scripts to copy data from Oracle via oracle_fdw. They each do
something like this:
CREATE SCHEMA migrate_stuff;
SET search_path TO migrate_stuff,public;
CREATE EXTENSION oracle_fdw SCHEMA migrate_rules;
CREATE SERVER oracle_stuff FOREIGN DATA WRAPPER ora
Stefan Kaltenbrunner writes:
> On 03/26/2013 11:30 PM, Tom Lane wrote:
>> A different line of thought is that the cancel was received by the
>> backend but didn't succeed in cancelling the query for some reason.
> I added the "pgcancel failed" codepath you suggested but it does not
> seem to get
On Wed, Apr 3, 2013 at 12:36 AM, Erikjan Rijkers wrote:
> On Mon, April 1, 2013 23:15, Alexander Korotkov wrote:
>
> [trgm-regexp-0.14.patch.gz]
>
> Hi Alexander,
>
Hi Erik!
> Something went wrong in this version of the patch: many (most) queries
> that were earlier
> spectacularly fast have b
On 29 March 2013 15:05, Tom Lane wrote:
> Bruce Momjian writes:
>> Our final 9.3 commit-fest has has exceeded the two-month mark, so it is
>> time to start targeting a date to close it and get to 9.3 beta. I see
>> 25 items will needing attention before we can close it:
>
>> https://commit
On 4/1/13 5:44 AM, Amit Kapila wrote:
I think in that case we can have 3 separate patches
1. Memory growth defect fix
2. Default postgresql.conf to include config directory and SET Persistent
into single file implementation
3. Rearrangement of GUC validation into validate_conf_option function.
re-head-13-14-20130402-2219.txt.bz2
Description: BZip2 compressed data
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Tue, 2 Apr 2013 09:01:36 -0700
Jeff Janes wrote:
> Sorry. I triple checked that the patch was there, but it seems like if you
> save a draft with an attachment, when you come back later to finish and
> send it, the attachment may not be there anymore. The Gmail Offline teams
> still has a wa
Kevin Grittner wrote:
> Tom Lane wrote:
>> Another reason why I don't like this code is that
>> pg_relation_is_scannable is broken by design:
>>
>> relid = PG_GETARG_OID(0);
>> relation = RelationIdGetRelation(relid);
>> result = relation->rd_isscannable;
>> RelationClose(rel
Sent from my iPad
On 02-Apr-2013, at 23:41, Merlin Moncure wrote:
> On Tue, Apr 2, 2013 at 12:50 PM, Atri Sharma wrote:
>> On Tue, Apr 2, 2013 at 9:24 PM, Robert Haas wrote:
>>
>>> One thought I had for fiddling with usage_count is to make it grow
>>> additively (x = x + 1) and decay expone
Tom Lane wrote:
> Kevin Grittner writes:
>> Tom Lane wrote:
>>> So maybe I'm nuts to care about the performance of an
>>> assert-enabled backend, but I don't really find a 4X runtime
>>> degradation acceptable, even for development work. Does anyone
>>> want to fess up to having caused this, or
On Tue, Apr 2, 2013 at 12:50 PM, Atri Sharma wrote:
> On Tue, Apr 2, 2013 at 9:24 PM, Robert Haas wrote:
>
>> One thought I had for fiddling with usage_count is to make it grow
>> additively (x = x + 1) and decay exponentially (x = x >> 1). I'm not
>> sure the idea is any good, but one problem w
On Tue, Apr 2, 2013 at 9:24 PM, Robert Haas wrote:
> One thought I had for fiddling with usage_count is to make it grow
> additively (x = x + 1) and decay exponentially (x = x >> 1). I'm not
> sure the idea is any good, but one problem with the current system is
> that it's pretty trivial for a
On Apr 2, 2013, at 10:16 AM, Tom Lane wrote:
>> Is this knowledge encapsulated in a to-do?
>
> I added an item to the "Indexes" section of the TODO page.
Great, thanks.
David
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://
On 2013-04-02 18:26:23 +0100, Greg Stark wrote:
> I'm confused by this thread. We *used* to maintain an LRU. The whole
> reason for the clock-sweep algorithm is precisely to avoid maintaining
> a linked list of least recently used buffers since the head of that
> list is a point of contention.
I d
I'm confused by this thread. We *used* to maintain an LRU. The whole
reason for the clock-sweep algorithm is precisely to avoid maintaining
a linked list of least recently used buffers since the head of that
list is a point of contention.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@pos
"David E. Wheeler" writes:
> On Apr 2, 2013, at 8:03 AM, Tom Lane wrote:
>>> Are there any widely known non-built-in cases besides citext?
>> Well, indxpath.c knows about text LIKE and network subset operators,
>> and it would be nice if it knew how to do the same type of optimization
>> for ran
On 2013-04-02 12:56:56 -0400, Tom Lane wrote:
> Andres Freund writes:
> > On 2013-04-02 12:22:03 -0400, Tom Lane wrote:
> >> I agree in general, though I'm not sure the bgwriter process can
> >> reasonably handle this need along with what it's already supposed to be
> >> doing. We may need anothe
Andres Freund writes:
> On 2013-04-02 12:22:03 -0400, Tom Lane wrote:
>> I agree in general, though I'm not sure the bgwriter process can
>> reasonably handle this need along with what it's already supposed to be
>> doing. We may need another background process that is just responsible
>> for kee
On 2013-04-02 12:22:03 -0400, Tom Lane wrote:
> Robert Haas writes:
> > But, having said that, I still think the best idea is what Andres
> > proposed, which pretty much matches my own thoughts: the bgwriter
> > needs to populate the free list, so that buffer allocations don't have
> > to wait for
On 2013-04-02 11:54:32 -0400, Robert Haas wrote:
> On Tue, Apr 2, 2013 at 11:32 AM, Merlin Moncure wrote:
> > That's a very fair point, although not being able to evict pinned
> > buffers is a highly mitigating aspect. Also CLOG is a different beast
> > entirely -- it's much more dense (2 bits!)
Robert Haas writes:
> But, having said that, I still think the best idea is what Andres
> proposed, which pretty much matches my own thoughts: the bgwriter
> needs to populate the free list, so that buffer allocations don't have
> to wait for linear scans of the buffer array. That's just plain to
I'm going to ignore most of the discussion that led up to this and give
this patch a fresh look.
+
+ SET PERSISTENT max_connections To 10;
+
The To should probably be capitalized.
I doubt this example actually works because changing max_connections
requires a restart. Try to find a better exa
Heikki Linnakangas writes:
> I'm quite worried about the security ramifications of this patch. Today, if
> you're not sure if a system has e.g sslinfo installed, you can safely just
> run "CREATE EXTENSION sslinfo". With this patch, that's no longer true,
> because "foo" might not be the extension
On Monday, April 1, 2013, Tom Lane wrote:
> Jeff Janes writes:
> > The problem is that the state is maintained only to an integer number of
> > milliseconds starting at 1, so it can take a number of attempts for the
> > random increment to jump from 1 to 2, and then from 2 to 3.
>
> Hm ... fair p
On Apr 2, 2013, at 8:03 AM, Tom Lane wrote:
>> Are there any widely known non-built-in cases besides citext?
>
> Well, indxpath.c knows about text LIKE and network subset operators,
> and it would be nice if it knew how to do the same type of optimization
> for range inclusion, ie btree_indexed_
On Tue, Apr 2, 2013 at 11:32 AM, Merlin Moncure wrote:
> That's a very fair point, although not being able to evict pinned
> buffers is a highly mitigating aspect. Also CLOG is a different beast
> entirely -- it's much more dense (2 bits!) vs a tuple so a single page
> can a lot of high priority
On Tue, Apr 2, 2013 at 9:55 AM, Robert Haas wrote:
> On Tue, Apr 2, 2013 at 1:53 AM, Merlin Moncure wrote:
>> That seems pretty unlikely because of A sheer luck of hitting that
>> page for the dropout (if your buffer count is N the chances of losing
>> it would seem to be 1/N at most) and B highl
Peter Eisentraut writes:
> On 4/2/13 10:26 AM, Tom Lane wrote:
>> The issue with the LIKE special case is that left-anchored patterns
>> are (to some extent) indexable with ordinary btree indexes, and so we
>> want to exploit that rather than tell people they have to have a whole
>> other index.
On Tue, Apr 2, 2013 at 1:53 AM, Merlin Moncure wrote:
> That seems pretty unlikely because of A sheer luck of hitting that
> page for the dropout (if your buffer count is N the chances of losing
> it would seem to be 1/N at most) and B highly used pages are much more
> likely to be pinned and thus
On Tue, Apr 2, 2013 at 6:32 AM, Andres Freund wrote:
> On 2013-04-01 17:56:19 -0500, Jim Nasby wrote:
>> On 3/23/13 7:41 AM, Ants Aasma wrote:
>> >Yes, having bgwriter do the actual cleaning up seems like a good idea.
>> >The whole bgwriter infrastructure will need some serious tuning. There
>> >a
On 4/2/13 10:26 AM, Tom Lane wrote:
> The issue with the LIKE special case is that left-anchored patterns
> are (to some extent) indexable with ordinary btree indexes, and so we
> want to exploit that rather than tell people they have to have a whole
> other index.
In practice, you need an index s
Peter Eisentraut writes:
> On 3/30/13 11:35 PM, Tom Lane wrote:
>> The LIKE index optimization is hard-wired into
>> match_special_index_operator(), which never heard of citext's ~~
>> operators.
>>
>> I've wanted for years to replace that mechanism with something that
>> would support plug-in ex
On 3/30/13 11:35 PM, Tom Lane wrote:
> The LIKE index optimization is hard-wired into
> match_special_index_operator(), which never heard of citext's ~~
> operators.
>
> I've wanted for years to replace that mechanism with something that
> would support plug-in extensions, but have no very good id
On 2013-04-01 17:56:19 -0500, Jim Nasby wrote:
> On 3/23/13 7:41 AM, Ants Aasma wrote:
> >Yes, having bgwriter do the actual cleaning up seems like a good idea.
> >The whole bgwriter infrastructure will need some serious tuning. There
> >are many things that could be shifted to background if we kne
On 2013-04-01 19:51:19 -0700, Jeff Janes wrote:
> On Mon, Apr 1, 2013 at 10:37 AM, Jeff Janes wrote:
>
> > On Tue, Mar 26, 2013 at 4:23 PM, Jeff Davis wrote:
> >
> >>
> >> Patch attached. Only brief testing done, so I might have missed
> >> something. I will look more closely later.
> >>
> >
> >
On 2 April 2013 02:53, Jeff Davis wrote:
>> Any idea
>> what is going on?
>
> Not right now.
Since I'm now responsible for the quality of this patch, I need to say
this before someone else does: we have until the end of the week to
fix this conclusively, or I will need to consider whether to rev
On 29/03/13 13:12, Brendan Jurd wrote:
On 28 March 2013 20:34, Dean Rasheed wrote:
Is the patch also going to allow empty arrays in higher dimensions
where not just the last dimension is empty?
It doesn't allow that at present.
It seems as though, if
it's allowing 1-by-0 arrays like '{{}}' a
43 matches
Mail list logo
