On 29/03/13 13:12, Brendan Jurd wrote:
On 28 March 2013 20:34, Dean Rasheed dean.a.rash...@gmail.com 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
On 2 April 2013 02:53, Jeff Davis pg...@j-davis.com 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
On 2013-04-01 19:51:19 -0700, Jeff Janes wrote:
On Mon, Apr 1, 2013 at 10:37 AM, Jeff Janes jeff.ja...@gmail.com wrote:
On Tue, Mar 26, 2013 at 4:23 PM, Jeff Davis pg...@j-davis.com wrote:
Patch attached. Only brief testing done, so I might have missed
something. I will look more
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 knew it
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 idea
Peter Eisentraut pete...@gmx.net 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
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
On Tue, Apr 2, 2013 at 6:32 AM, Andres Freund and...@2ndquadrant.com 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
On Tue, Apr 2, 2013 at 1:53 AM, Merlin Moncure mmonc...@gmail.com 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
Peter Eisentraut pete...@gmx.net 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
On Tue, Apr 2, 2013 at 9:55 AM, Robert Haas robertmh...@gmail.com wrote:
On Tue, Apr 2, 2013 at 1:53 AM, Merlin Moncure mmonc...@gmail.com 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
On Tue, Apr 2, 2013 at 11:32 AM, Merlin Moncure mmonc...@gmail.com 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
On Apr 2, 2013, at 8:03 AM, Tom Lane t...@sss.pgh.pa.us 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
On Monday, April 1, 2013, Tom Lane wrote:
Jeff Janes jeff.ja...@gmail.com 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.
Heikki Linnakangas hlinnakan...@vmware.com 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
I'm going to ignore most of the discussion that led up to this and give
this patch a fresh look.
+ screen
+ SET PERSISTENT max_connections To 10;
+ /screen
The To should probably be capitalized.
I doubt this example actually works because changing max_connections
requires a restart. Try to
Robert Haas robertmh...@gmail.com 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.
On 2013-04-02 11:54:32 -0400, Robert Haas wrote:
On Tue, Apr 2, 2013 at 11:32 AM, Merlin Moncure mmonc...@gmail.com 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
On 2013-04-02 12:22:03 -0400, Tom Lane wrote:
Robert Haas robertmh...@gmail.com 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
Andres Freund and...@2ndquadrant.com 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
On 2013-04-02 12:56:56 -0400, Tom Lane wrote:
Andres Freund and...@2ndquadrant.com 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
David E. Wheeler da...@kineticode.com writes:
On Apr 2, 2013, at 8:03 AM, Tom Lane t...@sss.pgh.pa.us 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
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
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
On Apr 2, 2013, at 10:16 AM, Tom Lane t...@sss.pgh.pa.us 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
On Tue, Apr 2, 2013 at 9:24 PM, Robert Haas robertmh...@gmail.com 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
On Tue, Apr 2, 2013 at 12:50 PM, Atri Sharma atri.j...@gmail.com wrote:
On Tue, Apr 2, 2013 at 9:24 PM, Robert Haas robertmh...@gmail.com 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
Tom Lane t...@sss.pgh.pa.us wrote:
Kevin Grittner kgri...@ymail.com writes:
Tom Lane t...@sss.pgh.pa.us 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
Sent from my iPad
On 02-Apr-2013, at 23:41, Merlin Moncure mmonc...@gmail.com wrote:
On Tue, Apr 2, 2013 at 12:50 PM, Atri Sharma atri.j...@gmail.com wrote:
On Tue, Apr 2, 2013 at 9:24 PM, Robert Haas robertmh...@gmail.com wrote:
One thought I had for fiddling with usage_count is to make
Kevin Grittner kgri...@ymail.com wrote:
Tom Lane t...@sss.pgh.pa.us 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;
On Tue, 2 Apr 2013 09:01:36 -0700
Jeff Janes jeff.ja...@gmail.com 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
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 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.
On 29 March 2013 15:05, Tom Lane t...@sss.pgh.pa.us wrote:
Bruce Momjian br...@momjian.us 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
On Wed, Apr 3, 2013 at 12:36 AM, Erikjan Rijkers e...@xs4all.nl 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
Stefan Kaltenbrunner ste...@kaltenbrunner.cc 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
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
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 BSDen
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
This commit introduced a problem with wal_keep_segments:
commit dfda6ebaec6763090fb78b458a979b558c50b39b
Author: Heikki Linnakangas heikki.linnakan...@iki.fi
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
40 matches
Mail list logo
