Robert Haas escribió:
On Mon, Jul 1, 2013 at 3:57 PM, Magnus Hagander mag...@hagander.net wrote:
I still think a better option to that would be to get psql to provide
a link to the full documentation there.
It seems like clutter to me, but I'll defer to whatever the consensus is.
I
On Mon, Jul 1, 2013 at 3:49 PM, Andres Freund and...@2ndquadrant.com wrote:
I must be missing something. At that point, yes, you'd like to avoid
re-toasting unnecessarily, but ISTM you've already bought the farm.
Unless I'm misunderstanding the code as written, you'd just end up
writing the
On Mon, Jul 1, 2013 at 4:31 PM, Claudio Freire klaussfre...@gmail.com wrote:
What?
A median of medians algorithm will guarantee floor(N/2) elements on
the smaller. That's the definition of median.
Note that I'm referring to picking the actual median of all tuples,
not just a sample. That's
On 26 June 2013 02:26, Robins Tharakan thara...@gmail.com wrote:
So technically I hope this regression patch I submitted could go through
since this feedback isn't towards that patch, but in my part I am quite
intrigued about this test (and how it passes) and probably I'd get back on
this
Hi all,
Claudio Freire wrote:
On Mon, Jul 1, 2013 at 2:29 AM, james ja...@mansionfamily.plus.com wrote:
On 01/07/2013 02:43, Claudio Freire wrote:
In essence, you'd have to use another implementation. CPython guys
have left it very clear they don't intend to fix that, as they don't
pg_get_viewdef() needs to be updated
Ah, good catch - I've fixed this in the attached. I also discovered that
there's a parent-child hierarchy of WindowDefs (using relname-name), so
instead of cloning the WindowDef (in parse_agg.c) if the frameOptions are
different (e.g. by adding the
On Tue, Jul 2, 2013 at 1:43 AM, Bruce Momjian br...@momjian.us wrote:
Agreed --- attached patch applied. I also noticed that we sometimes
test for -? then --help, but other times do things in the opposite
order, and the same for -V/--version, so I made that consistent.
However, I also
On Mon, Jul 1, 2013 at 9:31 AM, Michael Paquier
michael.paqu...@gmail.com wrote:
Hi all,
Please find attached an updated version of the patch removing
reltoastidxid (with and w/o context diffs), patch fixing the vacuum
full issue. With this fix, all the comments are addressed.
Thanks for
On Tue, Jul 2, 2013 at 7:36 AM, Fujii Masao masao.fu...@gmail.com wrote:
On Mon, Jul 1, 2013 at 9:31 AM, Michael Paquier
michael.paqu...@gmail.com wrote:
Hi all,
Please find attached an updated version of the patch removing
reltoastidxid (with and w/o context diffs), patch fixing the vacuum
On Mon, 2013-07-01 at 18:15 -0400, Luis Carvalho wrote:
The project is maintained -- I don't know how to say when something is
well-maintained, but small frequency of code updates is not one of my
criteria;
The bug tracker contains bugs about build problems with PG 8.4, 9.2, and
9.3, which
On 07/01/2013 12:05 AM, ian link wrote:
Definitely not this week. Hopefully for next commit fest.
OK, marked Returned with Feedback. It'll be up to you to add it to
the next commitfest if you think it's ready by then.
--
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com
--
Sent
Hi all,
When we run...
./configure --enable-converage
make coverage-html
...the output is generated into /coverage/ directory. The attached patch
add /converage/ to .gitignore.
Regards,
--
Fabrízio de Royes Mello
Consultoria/Coaching PostgreSQL
Blog sobre TI:
Robert Haas robertmh...@gmail.com writes:
On Mon, Jul 1, 2013 at 3:28 PM, Alvaro Herrera alvhe...@2ndquadrant.com
wrote:
Currently, all operator classes are tied to access methods. Since
nobody seems to have any great idea about creating an access method that
requires addition and
Peter Eisentraut wrote:
On Mon, 2013-07-01 at 18:15 -0400, Luis Carvalho wrote:
The project is maintained -- I don't know how to say when something is
well-maintained, but small frequency of code updates is not one of my
criteria;
The bug tracker contains bugs about build problems with
On 07/02/2013 01:54 AM, Luis Carvalho wrote:
Peter Eisentraut wrote:
On Mon, 2013-07-01 at 18:15 -0400, Luis Carvalho wrote:
The project is maintained -- I don't know how to say when something is
well-maintained, but small frequency of code updates is not one of my
criteria;
The bug tracker
On Thu, Jun 27, 2013 at 11:47 AM, Fujii Masao masao.fu...@gmail.com wrote:
On Thu, Jun 27, 2013 at 10:36 AM, Josh Kupershmidt schmi...@gmail.com wrote:
On Wed, Jun 26, 2013 at 12:22 PM, Fujii Masao masao.fu...@gmail.com wrote:
Though this is a corner case, the patch doesn't seem to handle
On Mon, 2013-07-01 at 16:05 -0400, Robert Haas wrote:
The other concern I remember being expressed (and not just by me, but
by a number of people) is that your patch turns loss of a visibility
map bit into a data corruption scenario, which it currently isn't.
Right now, if your visibility map
On 07/02/2013 02:39 AM, Robert Haas wrote:
I'm actually
not clear that it would be all that bad to assume fixed operator
names, as we apparently do in a few places despite the existence of
operator classes. But if that is bad, then I don't know how using @+
and @- instead helps anything.
On Mon, Jul 1, 2013 at 8:23 PM, Jeff Davis pg...@j-davis.com wrote:
Can you point me to that criticism? Why can't you just drop the VM
completely if it becomes corrupted?
(You might be referring to another idea of mine that was related to
Andres's proposal for getting rid of freezing.)
One
On Mon, 2013-07-01 at 20:59 -0400, Robert Haas wrote:
One of several relevant emails is at:
http://www.postgresql.org/message-id/51a7473c.6070...@vmware.com
It is definitely possible that I am mixing up two different things.
But if I am, I don't know what the other one is.
I believe you
On Mon, 2013-07-01 at 16:05 -0400, Robert Haas wrote:
Well, I don't believe there's any way to really eliminate the
contention concern completely. There's no way around the fact that it
means more access to the visibility map, and I've seen recent (albeit
circumstantial thus far) evidence
Now that we have COPY FREEZE, I'm thinking about adding similar option
to creating large objects. In 9.3 the maximum size of large objects
are increased. That means, the first access to a large object will
trigger more writes because of hint bit updation. Also subsequent
VACUUM may trigger that as
Craig Ringer cr...@2ndquadrant.com writes:
On 07/02/2013 02:39 AM, Robert Haas wrote:
I'm actually
not clear that it would be all that bad to assume fixed operator
names, as we apparently do in a few places despite the existence of
operator classes. But if that is bad, then I don't know how
Hey All,
This patch request grew from this post (of mine) to pgsql-general:
http://www.postgresql.org/message-id/cabuevezouae-g1_oejagujjmem675dnystwybp4d_wz6om+...@mail.gmail.com
The patch adds another available LDAP option (ldapnochaseref) for
search+bind mode in the pg_hba.conf fil. If set
On Tue, Jul 2, 2013 at 1:02 AM, Robert Haas robertmh...@gmail.com wrote:
On Sun, Jun 30, 2013 at 8:30 AM, Atri Sharma atri.j...@gmail.com wrote:
I have been reading the recent discussion and was researching a bit, and I
think that we should really go with the idea of randomising the input
On Friday, June 28, 2013 10:41 AM Sawada Masahiko wrote:
On Wed, Jun 26, 2013 at 1:40 PM, Amit Kapila amit.kap...@huawei.com
wrote:
On Tuesday, June 25, 2013 10:23 AM Amit Langote wrote:
Hi,
So our proposal on this problem is that we must ensure that
master
should
not make any
101 - 126 of 126 matches
Mail list logo
