2013/3/21 Tom Lane t...@sss.pgh.pa.us:
Brendan Jurd dire...@gmail.com writes:
While I was working on my empty array patch I was frequently irritated
by the absence of an array_length(anyarray). The same goes for
array_upper and array_lower. Most of the time when I work with
arrays, they are
On 21 March 2013 17:08, Pavel Stehule pavel.steh...@gmail.com wrote:
2013/3/21 Tom Lane t...@sss.pgh.pa.us:
I'm not entirely convinced that this is a good idea, but if we're going
to allow it I would argue that array_length(a) should be defined as
array_length(a, 1). The other possibilities
2013/3/21 Brendan Jurd dire...@gmail.com:
On 21 March 2013 17:08, Pavel Stehule pavel.steh...@gmail.com wrote:
2013/3/21 Tom Lane t...@sss.pgh.pa.us:
I'm not entirely convinced that this is a good idea, but if we're going
to allow it I would argue that array_length(a) should be defined as
On 21 March 2013 17:32, Pavel Stehule pavel.steh...@gmail.com wrote:
If I though about it more, I like to more limit one parametric
array_length function just for only 1D array. So it is your A use
case. But I understand so this variant is not orthogonal. Hard to say,
what is better.
Yes,
2013/3/21 Brendan Jurd dire...@gmail.com:
On 21 March 2013 17:32, Pavel Stehule pavel.steh...@gmail.com wrote:
If I though about it more, I like to more limit one parametric
array_length function just for only 1D array. So it is your A use
case. But I understand so this variant is not
Hi all,
While playing with custom background workers, I noticed that postmaster
does not notify its registered bgworkers if it receives SIGHUP,
so you have to send a SIGHUP directly to the bgworker process to notify it.
Signal handling is correctly done for SIGQUIT and SIGTERM for shutdown only.
Magnus Hagander mag...@hagander.net writes:
I think mcron already implements it all and is made to be embedded into
a larger program.
As long as your larger program is gpl. Not even lgpl on that one. I'd think
that's a killer for that idea...
Oh, are we now talking about including a
On 20 March 2013 16:03, Thom Brown t...@linux.com wrote:
On 19 March 2013 17:42, Thom Brown t...@linux.com wrote:
On 14 February 2013 18:02, Josh Berkus j...@agliodbs.com wrote:
Folks,
Once again, Google is holding Summer of Code. We need to assess whether
we want to participate this year.
Atri Sharma atri.j...@gmail.com writes:
We can use a scheduling algorithm, and can define a pool of tasks as
well as
a time constraint for the amount of time which can be used for running
the
tasks.Then, a scheduling algorithm can pick tasks from the pool based on
priorities and the time
Is anyone looking at these?:
hstore_io.c: In function ‘hstore_to_json_loose’:
hstore_io.c:1312:5: warning: ignoring return value of ‘strtol’, declared with
attribute warn_unused_result [-Wunused-result]
hstore_io.c:1324:6: warning: ignoring return value of ‘strtod’, declared with
attribute
On 21-03-2013 05:06, Michael Paquier wrote:
While playing with custom background workers, I noticed that postmaster does
not notify its registered bgworkers if it receives SIGHUP,
so you have to send a SIGHUP directly to the bgworker process to notify it.
Signal handling is correctly done for
On Thu, Mar 14, 2013 at 9:40 PM, Alexander Korotkov aekorot...@gmail.comwrote:
On Wed, Jan 23, 2013 at 7:29 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Heikki Linnakangas hlinnakan...@vmware.com writes:
On 23.01.2013 09:36, Alexander Korotkov wrote:
On Wed, Jan 23, 2013 at 6:08 AM, Tom
Euler Taveira escribió:
On 21-03-2013 05:06, Michael Paquier wrote:
While playing with custom background workers, I noticed that postmaster does
not notify its registered bgworkers if it receives SIGHUP,
so you have to send a SIGHUP directly to the bgworker process to notify it.
Signal
On 03/21/2013 10:46 AM, Kevin Grittner wrote:
Is anyone looking at these?:
hstore_io.c: In function ‘hstore_to_json_loose’:
hstore_io.c:1312:5: warning: ignoring return value of ‘strtol’, declared with
attribute warn_unused_result [-Wunused-result]
hstore_io.c:1324:6: warning: ignoring return
Heikki Linnakangas heikki.linnakan...@iki.fi wrote:
Fix element @ range cost estimation.
The statistics-based cost estimation patch for range types broke that, by
incorrectly assuming that the left operand of all range oeprators is a
range. That lead to a type x is not a range type error.
On 21.03.2013 17:20, Kevin Grittner wrote:
Something is still wrong. When I run `make check-world` everything
passes, but `make installcheck-world` on a fresh initdb with
default configuration yields this:
Huh, that's strange. It works for me, and the build farm is happy. I
must ask: are you
The SQL standard defines a RESPECT NULLS or IGNORE NULLS option for lead,
lag, [...]. This is not implemented in PostgreSQL
(http://www.postgresql.org/docs/devel/static/functions-window.html)
I've had a go at implementing this, and I've attached the resulting patch.
It's not finished yet
Hi,
On Sun, Mar 17, 2013 at 9:24 PM, Michael Paquier
michael.paqu...@gmail.com wrote:
Please find attached the patches wanted:
- 20130317_dump_only_valid_index.patch, a 1-line patch that makes
pg_dump
not take a dump of invalid indexes. This patch can be backpatched to
9.0.
The patch
On Wed, Mar 20, 2013 at 5:42 PM, Alvaro Herrera
alvhe...@2ndquadrant.com wrote:
Here's a new version of this patch, rebased on top of the new
pg_identify_object() stuff. Note that the regression test doesn't work
yet, because I didn't adjust to the new identity output definition (the
docs
Heikki Linnakangas hlinnakan...@vmware.com wrote:
Huh, that's strange. It works for me, and the build farm is
happy. I must ask: are you sure the server is running with fresh
binaries? If it still fails, could you try to get a stack trace
or something?
Hmm. Just to be sure I used
On Mon, Mar 18, 2013 at 10:09 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Boszormenyi Zoltan z...@cybertec.at writes:
How about the attached patch over current GIT? In other words,
why I am wrong with this idea?
Because it's wrong. Removing volatile means that the compiler is
permitted to
On Wed, Mar 20, 2013 at 5:50 PM, Peter Geoghegan p...@heroku.com wrote:
I realize that this isn't terribly critical, but I'd like to suggest
that commit_delay be made PGC_SIGHUP on 9.3 (it's currently
PGC_USERSET). It's not that a poorly chosen commit_delay setting has
the potential to
On Tue, Mar 12, 2013 at 11:36 AM, Greg Stark st...@mit.edu wrote:
On Tue, Mar 12, 2013 at 9:06 AM, Greg Smith g...@2ndquadrant.com wrote:
That's jumping right over a few rounds of simpler ways to do this, and just
going right to the approach we know allows adding more such options later
with
Terribly sorry about this -- my fault.
--
Álvaro Herrera
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On 03/21/2013 11:18 AM, Andrew Dunstan wrote:
On 03/21/2013 10:46 AM, Kevin Grittner wrote:
Is anyone looking at these?:
hstore_io.c: In function ‘hstore_to_json_loose’:
hstore_io.c:1312:5: warning: ignoring return value of ‘strtol’,
declared with attribute warn_unused_result
On 21 March 2013 18:27, Robert Haas robertmh...@gmail.com wrote:
This may be true, but so what? We don't generally restrict changing
GUC settings on the grounds that people probably won't wish to do so
because it isn't useful. We restrict it in situations where it is not
technically
On 3/21/13 2:38 PM, Robert Haas wrote:
Also, while I think that MOST people will probably want a SIGHUP right
after SET PERSISTENT, I am not sure that EVERYONE will want that. If
you want it and it doesn't happen automatically, you can always do it
by hand.
This is a fair position, and since
Andrew Dunstan and...@dunslane.net wrote:
[assign to local variable and then `(void) varname;` to avoid unused
warning]
This is the only thing that I have found to work with very recent gcc. Seems
ugly. Anyone got a better idea?
That seems to be what we've used elsewhere.
Greg Smith escribió:
On 3/21/13 2:38 PM, Robert Haas wrote:
Also, while I think that MOST people will probably want a SIGHUP right
after SET PERSISTENT, I am not sure that EVERYONE will want that. If
you want it and it doesn't happen automatically, you can always do it
by hand.
This is a
On Thu, Mar 21, 2013 at 6:27 PM, Robert Haas robertmh...@gmail.com wrote:
This may be true, but so what? We don't generally restrict changing
GUC settings on the grounds that people probably won't wish to do so
because it isn't useful. We restrict it in situations where it is not
technically
Kevin Grittner kgri...@ymail.com writes:
Hmm. Just to be sure I used maintainer-clean and another initdb
and now I don't see it. If I see it again I'll get a stack trace,
but for now it's not throwing the error.
It happened to me way too many times to have to do maintainer-clean for
reasons
On Thu, Mar 21, 2013 at 2:00 AM, Pavel Stehule pavel.steh...@gmail.com wrote:
2013/3/21 Brendan Jurd dire...@gmail.com:
On 21 March 2013 17:32, Pavel Stehule pavel.steh...@gmail.com wrote:
If I though about it more, I like to more limit one parametric
array_length function just for only 1D
On Fri, Mar 22, 2013 at 12:15 AM, Alvaro Herrera
alvhe...@2ndquadrant.comwrote:
Euler Taveira escribió:
On 21-03-2013 05:06, Michael Paquier wrote:
While playing with custom background workers, I noticed that
postmaster does
not notify its registered bgworkers if it receives SIGHUP,
Here's another cut at this patch. This is mainly about the
infrastructure to pass the data around in autovacuum; the proposed
formulas probably need lot of work.
We still have two terms in autovacuum priority, the first one considers
dead tuples and the second one considers wraparound limit. I
Is someone planning to provide additional feedback about this patch at some
point?
Thanks,
--
Michael
Robert Haas robertmh...@gmail.com writes:
On Mon, Mar 18, 2013 at 10:09 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Because it's wrong. Removing volatile means that the compiler is
permitted to optimize away stores (and fetches!) on the basis of their
being unnecessary according to straight-line
On Wed, 2013-03-20 at 02:11 +0200, Ants Aasma wrote:
Fletcher is also still a strong contender, we just need to replace the
255 modulus with something less prone to common errors, maybe use
65521 as the modulus. I'd have to think how to best combine the values
in that case. I believe we can
On Wed, Mar 20, 2013 at 09:50:55PM +, Peter Geoghegan wrote:
The fact is that whichever backend happens to end up becoming the
group commit leader from one XLogFlush() call to the next is, for all
practical purposes, unpredictable. You cannot reasonably hope to avoid
a delay within an
This contains some edits to comments that referred to the obsolete and
bogus TupleDesc scanning. No mechanical alterations.
--- a/contrib/dblink/dblink.c
+++ b/contrib/dblink/dblink.c
@@ -2961,9 +2961,8 @@ initRemoteGucs(remoteGucs *rgs, PGconn *conn)
}
/*
- * Scan a TupleDesc and, should it
Simon Riggs si...@2ndquadrant.com writes:
Only one setting will be best for the whole cluster, so neither the
user nor the DBA gains if a user sets this to a different value than
the one that has been determined to be optimal.
Since we wait while holding the lock it is actually harmful to
On Friday, March 22, 2013 12:48 AM Alvaro Herrera wrote:
Greg Smith escribió:
On 3/21/13 2:38 PM, Robert Haas wrote:
Also, while I think that MOST people will probably want a SIGHUP
right
after SET PERSISTENT, I am not sure that EVERYONE will want that.
If
you want it and it doesn't
Amit Kapila escribió:
On Friday, March 22, 2013 12:48 AM Alvaro Herrera wrote:
Maybe add some syntax to prevent the SIGHUP for the rare case where
that
is wanted, say
SET PERSISTENT (reload=off) var=val;
(perhaps WITH at the end, dunno)
I think adding new syntax change is
On 3/21/13 10:39 PM, Amit Kapila wrote:
I think adding new syntax change is little scary for me, not for the matter
of implementation but for building consensus on syntax.
Can we do it as an enhancement later?
Yeah, I think the basics of this could be committed, but have later
improvements
On Friday, March 22, 2013 8:57 AM Alvaro Herrera wrote:
Amit Kapila escribió:
On Friday, March 22, 2013 12:48 AM Alvaro Herrera wrote:
Maybe add some syntax to prevent the SIGHUP for the rare case where
that
is wanted, say
SET PERSISTENT (reload=off) var=val;
(perhaps
Hello all,
Sorry if this is a naive question.
I was going through Greg Smith's slides on buffer
cache(http://www.westnet.com/~gsmith/content/postgresql/InsideBufferCache.pdf).
When going through the page replacement algorithm that we use i.e.
clocksweep algorithm, I felt a potential problem in
Greg Smith g...@2ndquadrant.com writes:
On 3/21/13 10:39 PM, Amit Kapila wrote:
I feel giving Notice after every command doesn't look good, so may be we can
mention the same in documentation.
I think that NOTICE after every command is the only way we'll make sure
to catch every user who
On Friday, March 22, 2013 10:22 AM Atri Sharma wrote:
Hello all,
Sorry if this is a naive question.
I was going through Greg Smith's slides on buffer
cache(http://www.westnet.com/~gsmith/content/postgresql/InsideBufferCac
he.pdf).
When going through the page replacement algorithm that we
47 matches
Mail list logo
