On Fri, Mar 31, 2017 at 11:29 AM, Tom Lane <t...@sss.pgh.pa.us> wrote:
> Robert Haas <robertmh...@gmail.com> writes:
>> On Thu, Mar 30, 2017 at 4:45 PM, Tom Lane <t...@sss.pgh.pa.us> wrote:
>>> In short, it seems like this statement in the docs is correctl
e back branches
> should also be changed.
Sounds reasonable, but I don't see much advantage to changing it in
the back-branches.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.or
rom the extension afterwards.
Stephen, is this still on your list of things for today? Please
provide a status update.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
ects it contain will not be
> dumpable as well.
>
> That's the reason why the PgQ event tables created by
> pgq.create_queue() are not dumped.
That sucks.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-general mailing list (pgsql-gene
Note that
> I am not suggesting that ordering quals in query by their perceived cost
> is the solution. Keep optimizer informed by setting costs appropriately
> and it will do the right thing more often than not. :)
I think that if the costs are actually identical, the system will
, you could still
>> accommodate that:
>
> Actually, only if it's a variable that you setup and repeat and you show. A
> bit cumbersome and mixes the parts that are title and those that are present
> only because you are watching.
Ah, come on. This doesn't really seem like
king at it to be nice to the people
who do. Whatever is the consensus is OK with me. I just don't want
to get yelled at later for committing something here, so it would be
nice to see a few votes for whatever we're gonna do here.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise Postgre
tter yet, include the + 50 in title_len, and then you don't need to
reference the number 50 again further down.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
return false;
+}
Instead of repeating the cleanup code, how about making this break;
then, change the return statement at the bottom of the function to
return (res != -1).
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pg
in
pg_multixact/members, you're OK. But in theory, until that emergency
autovacuuming finishes, there's nothing keeping that directory from
wrapping around.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-general mailing list (pgsql
, but which is really a different proposal
altogether.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
On Fri, Jun 5, 2015 at 2:20 AM, Noah Misch n...@leadboat.com wrote:
On Thu, Jun 04, 2015 at 05:29:51PM -0400, Robert Haas wrote:
Here's a new version with some more fixes and improvements:
I read through this version and found nothing to change. I encourage other
hackers to study the patch
On Fri, Jun 5, 2015 at 12:00 PM, Andres Freund and...@anarazel.de wrote:
On 2015-06-05 11:43:45 -0400, Tom Lane wrote:
Robert Haas robertmh...@gmail.com writes:
On Fri, Jun 5, 2015 at 2:20 AM, Noah Misch n...@leadboat.com wrote:
I read through this version and found nothing to change. I
On Fri, Jun 5, 2015 at 2:36 PM, Alvaro Herrera alvhe...@2ndquadrant.com wrote:
Tom Lane wrote:
Robert Haas robertmh...@gmail.com writes:
There are at least two other known issues that seem like they should
be fixed before we release:
1. The problem that we might truncate an SLRU members
On Fri, Jun 5, 2015 at 2:47 PM, Andres Freund and...@anarazel.de wrote:
On 2015-06-05 14:33:12 -0400, Tom Lane wrote:
Robert Haas robertmh...@gmail.com writes:
1. The problem that we might truncate an SLRU members page away when
it's in the buffers, but not drop it from the buffers, leading
worse, life will suck.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
On Thu, Jun 4, 2015 at 5:29 PM, Robert Haas robertmh...@gmail.com wrote:
- Forces aggressive autovacuuming when the control file's
oldestMultiXid doesn't point to a valid MultiXact and enables member
wraparound at the next checkpoint following the correction of that
problem.
Err, enables
On Thu, Jun 4, 2015 at 12:57 PM, Robert Haas robertmh...@gmail.com wrote:
On Thu, Jun 4, 2015 at 9:42 AM, Robert Haas robertmh...@gmail.com wrote:
Thanks for the review.
Here's a new version. I've fixed the things Alvaro and Noah noted,
and some compiler warnings about set but unused
On Thu, Jun 4, 2015 at 1:27 PM, Andres Freund and...@anarazel.de wrote:
On 2015-06-04 12:57:42 -0400, Robert Haas wrote:
+ /*
+ * Do we need an emergency autovacuum? If we're not sure, assume yes.
+ */
+ return !oldestOffsetKnown ||
+ (nextOffset - oldestOffset
On Thu, Jun 4, 2015 at 9:42 AM, Robert Haas robertmh...@gmail.com wrote:
Thanks for the review.
Here's a new version. I've fixed the things Alvaro and Noah noted,
and some compiler warnings about set but unused variables.
I also tested it, and it doesn't quite work as hoped. If started
);
+ MultiXactState-offsetStopLimit = oldestOffset;
That last line needs s/oldestOffset/offsetStopLimit/, I presume.
Another oops.
Thanks for the review.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-general mailing list (pgsql-general
On Wed, Jun 3, 2015 at 8:24 AM, Robert Haas robertmh...@gmail.com wrote:
On Tue, Jun 2, 2015 at 5:22 PM, Andres Freund and...@anarazel.de wrote:
Hm. If GetOldestMultiXactOnDisk() gets the starting point by scanning
the disk it'll always get one at a segment boundary, right? I'm not sure
in the attached
patch.
Actually, we still need to call DetermineSafeOldestOffset in that
case. Otherwise, if someone goes from lots of multixacts to none, the
stop point won't advance.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-general
initialize
nextOffset to 0. That ought to safe us?
That's pretty much betting the farm on the bugs we know about today
being the only ones there are. That seems imprudent.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-general mailing
conservative? There's no
safe value in a circular numbering space.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref
On Tue, Jun 2, 2015 at 1:21 AM, Noah Misch n...@leadboat.com wrote:
On Mon, Jun 01, 2015 at 02:06:05PM -0400, Robert Haas wrote:
On Mon, Jun 1, 2015 at 12:46 AM, Noah Misch n...@leadboat.com wrote:
On Fri, May 29, 2015 at 03:08:11PM -0400, Robert Haas wrote:
SetMultiXactIdLimit() bracketed
with
multixacts that are completely filled by the time we've reached
consistency.
That would be a departure from the behavior of every existing release
that includes this code based on, to my knowledge, zero trouble
reports.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise
On Tue, Jun 2, 2015 at 11:27 AM, Andres Freund and...@anarazel.de wrote:
On 2015-06-02 11:16:22 -0400, Robert Haas wrote:
I'm having trouble figuring out what to do about this. I mean, the
essential principle of this patch is that if we can't count on
relminmxid, datminmxid, or the control
.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
On Tue, Jun 2, 2015 at 11:44 AM, Andres Freund and...@anarazel.de wrote:
On 2015-06-02 11:37:02 -0400, Robert Haas wrote:
The exact circumstances under which we're willing to replace a
relminmxid with a newly-computed one that differs are not altogether
clear to me, but there's an if statement
On Mon, Jun 1, 2015 at 12:46 AM, Noah Misch n...@leadboat.com wrote:
Incomplete review, done in a relative rush:
Thanks.
On Fri, May 29, 2015 at 03:08:11PM -0400, Robert Haas wrote:
OK, here's a patch. Actually two patches, differing only in
whitespace, for 9.3 and for master (ha!). I now
to this one.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
commit d33b4eb0167f465edb00bd6c0e1bcaa67dd69fe9
Author: Robert Haas rhaas@postgresql.org
Date: Fri May 29 14:35:53 2015 -0400
foo
diff --git a/src/backend/access/transam/multixact.c b/src
what needs to be removed. It would be
far better to invert that logic: decide what needs to be removed -
presumably, everything from the oldest member that now exists up until
some later point - and then remove precisely that stuff and nothing
else.
--
Robert Haas
EnterpriseDB: http
On Fri, May 29, 2015 at 10:17 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Thomas Munro thomas.mu...@enterprisedb.com writes:
On Fri, May 29, 2015 at 11:24 AM, Robert Haas robertmh...@gmail.com wrote:
B. We need to change find_multixact_start() to fail softly.
Here is an experimental WIP patch
On Fri, May 29, 2015 at 3:08 PM, Robert Haas robertmh...@gmail.com wrote:
It won't fix the fact that pg_upgrade is putting
a wrong value into everybody's datminmxid field, which should really
be addressed too, but I've been working on this for about three days
virtually non-stop and I don't
On Fri, May 29, 2015 at 9:46 PM, Andres Freund and...@anarazel.de wrote:
On 2015-05-29 15:08:11 -0400, Robert Haas wrote:
It seems pretty clear that we can't effectively determine anything
about member wraparound until the cluster is consistent.
I wonder if this doesn't actually hints
On Fri, May 29, 2015 at 12:43 PM, Robert Haas robertmh...@gmail.com wrote:
Working on that now.
OK, here's a patch. Actually two patches, differing only in
whitespace, for 9.3 and for master (ha!). I now think that the root
of the problem here is that DetermineSafeOldestOffset
On Thu, May 28, 2015 at 8:51 AM, Robert Haas robertmh...@gmail.com wrote:
[ speculation ]
OK, I finally managed to reproduce this, after some off-list help from
Steve Kehlet (the reporter), Alvaro, and Thomas Munro. Here's how to
do it:
1. Install any pre-9.3 version of the server and generate
. That seem like an
unnecessary risk.
Thoughts?
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
to the previous discussion?
I mean, the problem we're having right now is that sometimes we have
an offset, but the corresponding member isn't there. So clearly
offsets reference members. Do members also reference offsets? I
didn't think so, but life is full of surprises.
--
Robert Haas
?
Did you by any chance perform an immediate shutdown? Do you have the
actual log messages that were written when the system was shut down
for the upgrade?
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-general mailing list (pgsql
On Thu, May 28, 2015 at 8:03 AM, Robert Haas robertmh...@gmail.com wrote:
Steve, is there any chance we can get your pg_controldata output and a
list of all the files in pg_clog?
Err, make that pg_multixact/members, which I assume is at issue here.
You didn't show us the DETAIL line from
was interrupted or some such.
There may be bugs in redo, also, but they don't explain what happened to Steve.
Steve, is there any chance we can get your pg_controldata output and a
list of all the files in pg_clog?
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
On Thu, May 28, 2015 at 8:01 AM, Robert Haas robertmh...@gmail.com wrote:
On Wed, May 27, 2015 at 6:21 PM, Alvaro Herrera
alvhe...@2ndquadrant.com wrote:
Steve Kehlet wrote:
I have a database that was upgraded from 9.4.1 to 9.4.2 (no pg_upgrade, we
just dropped new binaries in place
a valid oldestOffset? If so, until the next
checkpoint happens, autovacuum has no clue whether it needs to worry.
There's got to be a fix for that, but it escapes me at the moment.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql
() to TrimMultiXact() seems like
a good idea. I'm not sure why we didn't do that before.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http
On Mon, Nov 17, 2014 at 4:27 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
On Thu, Nov 13, 2014 at 7:34 PM, Tom Lane t...@sss.pgh.pa.us wrote:
One thing that occurs to me is that if the generic plan estimate comes
out much cheaper than the custom one, maybe
to a custom plan, which is something I don't think
I've seen before.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref
that anyone will get upset if their query plans change
between beta1 and beta2, but the same cannot be said for released
branches.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org
that we can iron out any kinks before we get
too far down that path.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org
*Don't* VACUUM FULL. Just VACUUM. It's not the same thing.
...Robert
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
.
Does the SQL standard say anything on this topic?
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql
thinks that the
current behavior is for the best. But see commits
a06e41deebdf74b8b5109329dc75b2e9d9057962 and
a40b1e0bf32b1da46c1baa9bc7da87f207cd37d8.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-general mailing list (pgsql-general
which
seems a bit unfortunate terminology for that case. Is it important to
do something about that, and if so what?
Is this anything more than a naming problem?
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-general mailing list
, that timestamp will get bumped on TRUNCATE, CLUSTER, VACUUM
FULL, and rewriting versions of ALTER TABLE.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your
of an effort to understand how the system
works now, and why, before proposing radical redesigns.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http
(n_distinct = ...);
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
On Wed, Feb 9, 2011 at 4:50 AM, Thom Brown t...@linux.com wrote:
On 9 February 2011 02:11, Robert Haas robertmh...@gmail.com wrote:
On Tue, Feb 8, 2011 at 8:30 PM, Andrew Dunstan and...@dunslane.net wrote:
Quite right, but the commitfest manager isn't meant to be a substitute for
one. Bug
On Fri, Jun 17, 2011 at 2:15 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
So, I finally got around to look at this, and I think there is a
simpler solution. When an overflow occurs while calculating the next
value, that just means that the value we're about
- for
example, check_postgres.pl.
http://bucardo.org/check_postgres/check_postgres.pl.html#sequence
We tend to avoid emitting warnings for this kind of thing because they
can consume vast amounts of disk space, and a lot of times no one's
looking at them anyway.
--
Robert Haas
EnterpriseDB: http
watermark of libselinux-2.0.93
instead.
Looks to me like you need to adjust the wording of the error message.
Maybe libselinux version 2.0.93 or newer is required, or something like that.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via
/wiki/PostgreSQL_9.1_Open_Items
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
unlikely to
break anything else. ISTM the worst case scenario is that it takes
two minor releases to get it right, and even that seems fairly
unlikely.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-general mailing list (pgsql-general
that.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise Postgres Company
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
On Tue, Sep 28, 2010 at 9:33 PM, Itagaki Takahiro
itagaki.takah...@gmail.com wrote:
On Wed, Sep 29, 2010 at 10:18 AM, Robert Haas robertmh...@gmail.com wrote:
No, the column is very clearly labelled Reviewers, not Reviewer.
And we have certainly had patches with more than one person's name
2009/1/22 Informatica-Cooperativa Cnel. Oviedo informat...@coopovie.com.py:
Buenos Dias todos,
Soy un usuario de postgres de Paraguay, consulto
sobre la posibilidad de inclucion en la futura version la siguiente
sentencia(Uso de alias en la condicion HAVING ):
2009/11/30 rahimeh khodadadi rahimeh.khodad...@gmail.com:
-- Forwarded message --
From: rahimeh khodadadi rahimeh.khodad...@gmail.com
Date: 2009/11/29
Subject: Re: psql+krb5
To: Denis Feklushkin denis.feklush...@gmail.com
Please review the guidelines for reporting a
On Tue, Dec 1, 2009 at 11:26 AM, Scott Marlowe scott.marl...@gmail.com wrote:
Except that he posted a month ago and got no answers...
Gee, I wonder why.
...Robert
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
On Tue, Nov 24, 2009 at 12:28 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Kevin Grittner kevin.gritt...@wicourts.gov writes:
So we're conceding that this is a valid need and people will now have
a way to meet it. Is the argument against having CINE syntax that it
would be more prone to error than
On Tue, Nov 24, 2009 at 2:07 PM, Kevin Grittner
kevin.gritt...@wicourts.gov wrote:
Tom Lane t...@sss.pgh.pa.us wrote:
If it did so, that would be outside the apparent meaning of the
command, which is to do nothing if an object of that name exists.
That's why we've gone with CREATE OR REPLACE
On Sun, Nov 22, 2009 at 11:38 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
On Sun, Nov 22, 2009 at 6:51 PM, Tom Lane t...@sss.pgh.pa.us wrote:
CREATE IF NOT EXISTS has been proposed and rejected before, more than
once. Please see the archives.
Search
On Sun, Nov 22, 2009 at 6:51 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Craig Ringer cr...@postnewspapers.com.au writes:
I do think this comes up often enough that a built-in trigger update
named column with result of expression on insert trigger might be
desirable.
There's something of the sort
On Thu, Sep 24, 2009 at 8:36 PM, Tom Lane t...@sss.pgh.pa.us wrote:
BTW, are port numbers still limited to 16 bits in IPv6?
Yes.
...Robert
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
On Thu, Sep 24, 2009 at 8:59 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Sam Mason s...@samason.me.uk writes:
+ if (portnum 1 || portnum 65535)
BTW, it strikes me that we could tighten this even more by rejecting
target ports below 1024. This is guaranteed safe on all Unix systems
On Thu, Apr 2, 2009 at 12:17 PM, David E. Wheeler da...@kineticode.com wrote:
On Apr 1, 2009, at 2:22 PM, Tom Lane wrote:
Another way to state the point is that we can offer people a choice of
two limitations: string_to_array doesn't work for zero-length lists,
or string_to_array doesn't work
On Thu, Apr 2, 2009 at 12:10 PM, David E. Wheeler da...@kineticode.com wrote:
On Apr 1, 2009, at 12:19 PM, Robert Haas wrote:
my @ints = map { $_ || 0 } split ',', $string;
This ensures that I get the proper number of records in the example of
something like '1,2,,4'.
I can't see
On Thu, Apr 2, 2009 at 2:04 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Right at the moment, if we stick with the historical definition
of the function, *both* camps have to write out their choice of
the above. Seems like this is the worst of all possible worlds.
We should probably pick one or the
On Thu, Apr 2, 2009 at 2:18 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
On Thu, Apr 2, 2009 at 2:04 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Right at the moment, if we stick with the historical definition
of the function, *both* camps have to write out
On Thu, Apr 2, 2009 at 2:50 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
On Thu, Apr 2, 2009 at 2:18 PM, Tom Lane t...@sss.pgh.pa.us wrote:
If there's a camp that actually *wants* a NULL result for this case,
I missed the reasoning.
So that we don't break
On Tue, Mar 31, 2009 at 10:44 AM, Greg Stark st...@enterprisedb.com wrote:
On Tue, Mar 31, 2009 at 3:42 PM, Sam Mason s...@samason.me.uk wrote:
string_to_array('',',')::INT[] = invalid input syntax for integer:
Oof. That's a good point.
+1. I find this argument much more compelling than
On Wed, Apr 1, 2009 at 12:52 PM, David E. Wheeler da...@kineticode.com wrote:
Well, I'd just point out that the return value of string_to_array() is
text[]. Thus, this is not a problem with string_to_array(), but a casting
problem from text[] to int[]. Making string_to_array() return a NULL for
On Wed, Apr 1, 2009 at 1:05 PM, justin jus...@emproshunts.com wrote:
I'm still a hold out, We are taking a string putting it into a array based
on a delimiter. That is very simple and straight forward. Yet many argue
if we want to cast this into another data type the function should deal
On Wed, Apr 1, 2009 at 5:22 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Or we could stick to the current behavior and say use COALESCE() to
resolve the ambiguity, if you need to.
If there's no consensus on changing the behavior, it's probably better
to be backward compatible than not.
...Robert
--
Could you send the output of these two queries using explain analyze
instead of plain explain?
portal=# explain analyze select * from foo i, foo j where i.id = j.id;
QUERY PLAN
What's strange about it? A probe into an in-memory hashtable is a lot
cheaper than a probe into an index, so this type of plan makes plenty
of sense if the hashtable will fit in RAM and there are going to be a
lot of probes. (Where a lot means enough to amortize the cost of
building the
Well, that just says your cost parameters need a bit of adjustment
if you'd like the planner to get the crossover point exactly right.
Any sense of which ones might be worth fiddling with?
random_page_cost, effective_cache_size, maybe the cpu_xxx parameters.
I fiddled with this some more on
I'm seeing a lot of plans in my database that look like this:
portal=# explain select * from foo i, foo j where i.id = j.id;
QUERY PLAN
-
Hash Join (cost=769.87..2159.36 rows=13283 width=264)
* pg_last_recovered_xact_xid()
Will throw an ERROR if *not* executed in recovery mode.
returns bigint
* pg_last_completed_xact_xid()
Will throw an ERROR *if* executed in recovery mode.
returns bigint
Should these return xid?
...Robert
--
Sent via pgsql-general mailing list
So, say I have something like this - the actual example is something a
bit more useful:
CREATE TABLE foo (a integer, b integer);
INSERT INTO foo VALUES (1, 1); -- must have some data to generate the failure
CREATE FUNCTION bar (foo) RETURNS SETOF foo AS $$
DECLARE
f foo;
BEGIN
f.a :=
You need LATERAL support for this:
SELECT * FROM foo f LATERAL bar(f);
I'm not sure about the syntax, but LATERAL is a standard JOIN type wherein
upper nodes are visible.
That would be really nice. Then you could presumably also do:
SELECT f.id, f.name, f.apple, f.banana, bar.apple AS
I'm trying to write a SQL statement to determine whether a value is an
an array, but I want the comparison to be done using IS NOT DISTINCT
FROM rather than =.
My first thought was that instead of writing:
SELECT value = ANY(array)
...I could simply write:
SELECT value IS NOT DISTINCT FROM
I have to dig this up and see if I still have it.
...Robert
-Original Message-
From: Bruce Momjian [mailto:[EMAIL PROTECTED]
Sent: Tuesday, March 11, 2008 1:05 PM
To: Robert Haas
Cc: Tom Lane; pgsql-general@postgresql.org
Subject: Re: [GENERAL] contributing patches
Great, would you
These may be more -hackers questions, but I am duly following protocol
by trying elsewhere first.
1. Does the PostgreSQL development team require the assignment of
copyright in order to accept contributions? If so, is there a standard
form that is normally used for this purpose? Or,
We require that all submissions conform to the Postgres BSD license,
but we are not picky about requiring paperwork to prove it. Just put
the same copyright header into any added files as you see in existing
files.
OK cool.
Yeah, the core team does not have a lot of bandwidth right now for
]
Sent: Monday, February 26, 2007 4:15 AM
To: Robert Haas
Cc: David Fetter; pgsql-general@postgresql.org
Subject: Re: [GENERAL] complex referential integrity constraints
Robert Haas wrote:
I don't understand what a weighted constraint would mean. Either the
attacker_id can be a wolf, or it can't
To: Alban Hertroys
Cc: Robert Haas; David Fetter; pgsql-general@postgresql.org
Subject: Re: [GENERAL] complex referential integrity constraints
Alban Hertroys wrote:
Robert Haas wrote:
The idea here is that a wolf can attack a sheep, or a wolf can
attack
another wolf, but sheep can't attack anything
to have, so I'm just doing it in some really critical cases and hoping
that the others don't break.
Thanks,
...Robert
-Original Message-
From: Alban Hertroys [mailto:[EMAIL PROTECTED]
Sent: Friday, February 23, 2007 4:02 AM
To: Robert Haas
Cc: David Fetter; pgsql-general@postgresql.org
it in the TODO file, too.
...Robert
-Original Message-
From: Joris Dobbelsteen [mailto:[EMAIL PROTECTED]
Sent: Thursday, February 22, 2007 8:03 AM
To: Robert Haas; elein
Cc: pgsql-general@postgresql.org
Subject: RE: [GENERAL] complex referential integrity constraints
I partially agree
: David Fetter [mailto:[EMAIL PROTECTED]
Sent: Monday, February 19, 2007 1:04 PM
To: Robert Haas
Cc: pgsql-general@postgresql.org
Subject: Re: [GENERAL] complex referential integrity constraints
On Fri, Feb 16, 2007 at 09:58:56AM -0500, Robert Haas wrote:
So, I have the following problem.
Suppose
a few of them. It is exponentially harder to write a
constraint of this type than it is to write a simple foreign key
constraint.
...Robert
-Original Message-
From: Joris Dobbelsteen [mailto:[EMAIL PROTECTED]
Sent: Monday, February 19, 2007 5:59 AM
To: elein; Robert Haas
Cc: pgsql-general
1 - 100 of 101 matches
Mail list logo
