On 24/08/10 23:56, Andres Freund wrote:
I have to ask one question: On a short review of the discussion and
the patch I didn't find anything about the concurrency issues
involved (at least nodeModifyTable.c didnt show any).
The SQL spec doesn't require MERGE to be an atomic upsert operation.
On 08/23/2010 07:34 PM, Bruce Momjian wrote:
I looked at the pg_upgrade ramifications of this change and it seems
some adjustments will have to be made. Right now pg_upgrade creates an
empty enum type:
CREATE TYPE etest AS ENUM ();
and then it calls EnumValuesCreate() to create the
On 2010-08-25 9:26 AM +0300, Heikki Linnakangas wrote:
Whats the plan to go forward at that subject? I think the patch needs
to lock tables exclusively (the pg level, not access exclusive) as
long as there is no additional handling...
Well, you can always do LOCK TABLE before calling MERGE if
Argument List?
--
dim
Le 24 août 2010 à 18:06, Tom Lane t...@sss.pgh.pa.us a écrit :
I wrote:
Robert Haas robertmh...@gmail.com writes:
If you try to put all that on the same line, I think it might get
awkwardly long. Perhaps something like:
Function Scan on function_name
Expression:
On Wed, Aug 25, 2010 at 5:44 AM, Josh Berkus j...@agliodbs.com wrote:
Again, given that this is a method which is (a) fairly minority-need,
and (b) not at all tested in the field, I do not think it belongs in the
main docs. Let's put it on the wiki and blog about it, and AFTER we've
collected
On Wed, Aug 25, 2010 at 07:11, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
1. The new conversion seems to have stolen the apostrophe from D'Arcy
J.M. Cain da...@druid.net, rendering him DArcy J.M. Cain
da...@druid.net.
Yeah, I see that too. It's probably bad
On Tue, 2010-08-24 at 11:04 -0700, Josh Berkus wrote:
I've been looking at the open item which belongs with this doc:
http://www.postgresql.org/docs/9.0/static/backup-incremental-updated.html
I'm back from holidays today, so will begin looking at this and related
open-ish items.
--
Simon
On Thu, 2010-08-19 at 19:06 -0400, Tom Lane wrote:
Fujii Masao masao.fu...@gmail.com writes:
The explanation of trace_recovery_messages in the document
is inconsistent with the definition of it in guc.c.
I've applied a patch for this.
I was tempted to propose that we just rip out
On Wed, Aug 25, 2010 at 09:26:51AM +0300, Heikki Linnakangas wrote:
On 24/08/10 23:56, Andres Freund wrote:
I have to ask one question: On a short review of the discussion and
the patch I didn't find anything about the concurrency issues
involved (at least nodeModifyTable.c didnt show any).
On 25/08/10 12:41, Andres Freund wrote:
But randomly loosing tuples will make much more people unhappy. At a
much more problematic point of time (in production).
Hmm, how would you lose tuples?
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
--
Sent via pgsql-hackers
On Fri, 2010-08-20 at 15:59 -0400, Tom Lane wrote:
Josh Berkus j...@agliodbs.com writes:
Hmmm. It seems to me that we'd need a sharelock on the referenced row
both times.
No, we don't. The first update knows that it's updating a pre-existing
referencing row and not changing the FK
On 25/08/10 09:18, Magnus Hagander wrote:
On Wed, Aug 25, 2010 at 07:11, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
2. Any non-ASCII characters in, for example, contributor's names show
up differently in the two repos. Generally, the original repo is OK
and
On Wed, Aug 25, 2010 at 13:03, Max Bowsher m...@f2s.com wrote:
On 25/08/10 09:18, Magnus Hagander wrote:
On Wed, Aug 25, 2010 at 07:11, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
2. Any non-ASCII characters in, for example, contributor's names show
up
On Tue, Aug 24, 2010 at 11:21 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
On Fri, Aug 20, 2010 at 1:56 PM, Max Bowsher m...@f2s.com wrote:
My guess at this point is that there may be a (very old?) version of cvs
which, when adding a file to a branch,
On Wed, Aug 25, 2010 at 5:36 AM, Simon Riggs si...@2ndquadrant.com wrote:
This is definitely a stop-gap facility. If you were to propose a more
general facility for increasing log level of specific modules, I'm sure
the rest of us would see that implemented across the rest of the code.
Yeah, I
On 25/08/10 01:15, Robert Haas wrote:
On Fri, Aug 20, 2010 at 1:56 PM, Max Bowsher m...@f2s.com wrote:
My guess at this point is that there may be a (very old?) version of cvs
which, when adding a file to a branch, actually misrecorded the file as
having existed on the branch from the moment
Hi,
PostgreSQL allows in plain SQL to declare a cursor
e.g. in all lower case and fetch from is in all upper case.
We need to allow this from ECPG, too, but strictly when
the cursor name is not in a variable. Otherwise this code
below doesn't notice the cursor's double declaration
and complains
On Tue, 24 Aug 2010, Tom Lane wrote:
There's an entry in the 9.0 release notes saying that we've got
filtering dictionaries now. Cool, but I don't see any documentation
of the feature in textsearch.sgml. Shouldn't there be some?
Something like
On 25/08/10 14:03, Max Bowsher wrote:
On 25/08/10 09:18, Magnus Hagander wrote:
On Wed, Aug 25, 2010 at 07:11, Tom Lanet...@sss.pgh.pa.us wrote:
Robert Haasrobertmh...@gmail.com writes:
There are also a number of commits that differ in order between the
two repos, and an even larger number
On Wed, Aug 25, 2010 at 13:19, Robert Haas robertmh...@gmail.com wrote:
What seemed more likely to be artifacts were
these:
remotes/origin/unlabeled-1.44.2
remotes/origin/unlabeled-1.51.2
remotes/origin/unlabeled-1.59.2
remotes/origin/unlabeled-1.87.2
remotes/origin/unlabeled-1.90.2
On 25/08/10 04:21, Tom Lane wrote:
Robert Haas robertmh...@gmail.com writes:
What seemed more likely to be artifacts were
these:
remotes/origin/unlabeled-1.44.2
remotes/origin/unlabeled-1.51.2
remotes/origin/unlabeled-1.59.2
remotes/origin/unlabeled-1.87.2
On 25/08/10 12:36, Heikki Linnakangas wrote:
On 25/08/10 14:03, Max Bowsher wrote:
On 25/08/10 09:18, Magnus Hagander wrote:
On Wed, Aug 25, 2010 at 07:11, Tom Lanet...@sss.pgh.pa.us wrote:
Robert Haasrobertmh...@gmail.com writes:
There are also a number of commits that differ in order
Oleg Bartunov o...@sai.msu.su writes:
On Tue, 24 Aug 2010, Tom Lane wrote:
There's an entry in the 9.0 release notes saying that we've got
filtering dictionaries now. Cool, but I don't see any documentation
of the feature in textsearch.sgml. Shouldn't there be some?
Something like
Simon,
On 08/25/2010 11:53 AM, Simon Riggs wrote:
..we want to ensure that the PK value..
..or any other possibly referenced attributes?
Markus
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
On Wed, 2010-08-25 at 15:51 +0200, Markus Wanner wrote:
Simon,
On 08/25/2010 11:53 AM, Simon Riggs wrote:
..we want to ensure that the PK value..
..or any other possibly referenced attributes?
Don't think that's relevant.
referenced meaning by an RI constraint, which only ever refers to
Max Bowsher m...@f2s.com writes:
On 25/08/10 12:36, Heikki Linnakangas wrote:
On 25/08/10 14:03, Max Bowsher wrote:
cvs2git will try to use the timestamps from the commits, but sometimes
the ordering of how revisions and tags relate to each other will
actually disagree with the timestamps. In
[resending after noticing that reply all resulted in sending to
pgsql-hackers-owner rather than pgsql-hackers]
Luxenberg, Scott I. scott.luxenb...@noblis.org wrote:
This is just my email to notify you all that the project I've been
working on with Stephen, the PostgreSQL Performance Farm,
2010/8/25 Simon Riggs si...@2ndquadrant.com:
referenced meaning by an RI constraint, which only ever refers to
PKs in other tables.
FK constraints can also point to non-PK UNIQUE columns.
Nicolas
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your
On Wed, Aug 25, 2010 at 10:02 AM, Simon Riggs si...@2ndquadrant.com wrote:
On Wed, 2010-08-25 at 15:51 +0200, Markus Wanner wrote:
Simon,
On 08/25/2010 11:53 AM, Simon Riggs wrote:
..we want to ensure that the PK value..
..or any other possibly referenced attributes?
Don't think that's
Hi,
On 08/21/2010 10:11 PM, Peter Geoghegan wrote:
We changed 8.5 to 9.0 explicitly because doing so was good marketing,
That's exactly how I see this as well. The current scheme allows for
some flexibility for marketing purposes while still being
self-consistent and logical in numbering.
Dimitri Fontaine dfonta...@hi-media.com writes:
Argument List?
Well, as shown in the example I posted, it's not just the argument list
but the whole call:
Function Call: unnest(ARRAY[ROW(('1.2.2'::text)::semver, '='::text,
('1.2.2'::text)::semver), ROW('1.2.23', '=', '1.2.23')])
Now you
On Wed, Aug 25, 2010 at 1:34 AM, Itagaki Takahiro
itagaki.takah...@gmail.com wrote:
* Should we accept a scalar value as a valid JSON?
According to RFC, the root element of JSON text must be an object
or array. But to_json() and from_json() accept scalar values.
This seems a bit like the XML
On Wed, 2010-08-25 at 16:14 +0200, Nicolas Barbier wrote:
2010/8/25 Simon Riggs si...@2ndquadrant.com:
referenced meaning by an RI constraint, which only ever refers to
PKs in other tables.
FK constraints can also point to non-PK UNIQUE columns.
You're exactly correct and I now
2010/8/25 Simon Riggs si...@2ndquadrant.com:
On Wed, 2010-08-25 at 16:14 +0200, Nicolas Barbier wrote:
2010/8/25 Simon Riggs si...@2ndquadrant.com:
referenced meaning by an RI constraint, which only ever refers to
PKs in other tables.
FK constraints can also point to non-PK UNIQUE
On Wed, Aug 25, 2010 at 3:20 PM, Simon Riggs si...@2ndquadrant.com wrote:
FK constraints can also point to non-PK UNIQUE columns.
You're exactly correct and I now understand Markus' comment. Do you
think that exact meaning prevents my proposal from being useful?
I think it just shows it
Nicolas Barbier nicolas.barb...@gmail.com writes:
2010/8/25 Simon Riggs si...@2ndquadrant.com:
You're exactly correct and I now understand Markus' comment. Do you
think that exact meaning prevents my proposal from being useful?
Not at all, because I guess that updates to non-UNIQUE columns
Tom Lane escreveu:
You didn't actually read what I said, did you? That patch will have
precisely zero effect on the OP's example.
Oh, I see your point. Didn't pay attention at the OP's example. I was only
worried about the successful queries that doesn't return SQLSTATE but as you
point out,
Tom Lane wrote:
Steve Singer ssin...@ca.afilias.info writes:
I think I've been able to reproduce the issue floating around with
streaming replication on AIX.
Excellent, because we weren't getting much from the original reporter.
I'm withdrawing my comment, today on a clean install of the
On 08/25/2010 04:57 PM, Tom Lane wrote:
It strikes me that a possibly useful simplification of the idea is a
lock type that allows HOT updates and not non-HOT ones; or more
precisely not ones that change any indexed columns --- if the row ends
up having to go off-page for lack of space, that
Max Bowsher wrote:
On 25/08/10 12:36, Heikki Linnakangas wrote:
On 25/08/10 14:03, Max Bowsher wrote:
cvs2git will try to use the timestamps from the commits, but sometimes
the ordering of how revisions and tags relate to each other will
actually disagree with the timestamps. In such a case,
Max Bowsher m...@f2s.com writes:
On 25/08/10 04:21, Tom Lane wrote:
What seemed more likely to be artifacts were these:
remotes/origin/unlabeled-1.44.2
remotes/origin/unlabeled-1.51.2
remotes/origin/unlabeled-1.59.2
remotes/origin/unlabeled-1.87.2
remotes/origin/unlabeled-1.90.2
Any
Steve Singer wrote:
Tom Lane wrote:
Steve Singer ssin...@ca.afilias.info writes:
I think I've been able to reproduce the issue floating around with
streaming replication on AIX.
I will do another clean build from the beta4 source tar to confirm that
I'm not still having the issue but I'm
On 25/08/10 16:43, Tom Lane wrote:
Max Bowsher m...@f2s.com writes:
On 25/08/10 04:21, Tom Lane wrote:
What seemed more likely to be artifacts were these:
remotes/origin/unlabeled-1.44.2
remotes/origin/unlabeled-1.51.2
remotes/origin/unlabeled-1.59.2
remotes/origin/unlabeled-1.87.2
Kevin,
* Kevin Grittner (kevin.gritt...@wicourts.gov) wrote:
Would this project be useful for someone trying to assess the
performance impact of a proposed patch (at least on the developer's
machine)? What would someone do to use it in this way?
The goal is to have this running in a similar
Robert Haas wrote:
This series of commits also seems pretty messed up:
http://archives.postgresql.org/pgsql-committers/2007-04/msg00222.php
http://archives.postgresql.org/pgsql-committers/2007-04/msg00223.php
The commit messages make it clear that CVS did something funky,
although it's
Stephen Frost sfr...@snowman.net wrote:
The goal is to have this running in a similar manner as the build
farm to identify when a patch has an impact on performance (good
or bad). Hackers would then be able to view performance farm
reports similar to viewing build farm reports. Not sure if
On Wed, Aug 25, 2010 at 12:02 PM, Michael Haggerty mhag...@alum.mit.edu wrote:
I think we should try to do something to clean this up,
perhaps by doctoring the file on the CVS side.
This is probably caused by cvs2svn's failure to consider file deletions
when choosing the best revision from
* Kevin Grittner (kevin.gritt...@wicourts.gov) wrote:
I actually understood that part, but was already wondering if it
could be bent to slightly different purposes. It seems as though
there would be value to using it to evaluate the performance impact
of a proposed patch, at least on a
It strikes me that a possibly useful simplification of the idea is a
lock type that allows HOT updates and not non-HOT ones; or more
precisely not ones that change any indexed columns --- if the row ends
up having to go off-page for lack of space, that need not concern us.
While an
On Wed, Aug 25, 2010 at 5:35 PM, Robert Haas robertmh...@gmail.com wrote:
Well, the history here is pretty weird. In relevant part, here's the
result of cvs log on src/backend/parser/gram.c:
Interestingly this weirdness first surfaced due to a previous
discussion of using git about 3 and a
Robert Haas robertmh...@gmail.com writes:
The fact that the file was modified twice after being removed at rev
2.88 seems really wacko. Are you sure that's not contributing to what
we're seeing here?
Yeah, that was discussed in the earlier git-conversion thread that I
pointed to. We never
Robert Haas wrote:
Well, the history here is pretty weird. In relevant part, here's the
result of cvs log on src/backend/parser/gram.c:
revision 2.92
date: 2007/04/17 01:06:27; author: tgl; state: dead; lines: +0 -0
And remove 'em again ...
revision 2.91
Josh Berkus j...@agliodbs.com writes:
It strikes me that a possibly useful simplification of the idea is a
lock type that allows HOT updates and not non-HOT ones; or more
precisely not ones that change any indexed columns --- if the row ends
up having to go off-page for lack of space, that
Michael Haggerty mhag...@alum.mit.edu writes:
Robert Haas wrote:
The fact that the file was modified twice after being removed at rev
2.88 seems really wacko. Are you sure that's not contributing to what
we're seeing here?
I think this is the normal behavior when a file is deleted then
On Wed, Aug 25, 2010 at 6:34 PM, Tom Lane t...@sss.pgh.pa.us wrote:
That is true, but tracking exactly which indexes are relevant for that,
at the extremely low level that this would have to take effect, doesn't
seem like a bright plan to me. It's already ugly beyond words that
heapam.c knows
A.M. age...@themactionfaction.com writes:
On Aug 25, 2010, at 12:28 PM, Tom Lane wrote:
However, it's odd that you got this variant of the HINT and not the one
that suggests increasing SHMMAX. Looking at the code, that means that
shmget returned ENOMEM, not EINVAL, which surprises me.
I was
Greg Stark gsst...@mit.edu writes:
It's still not a very practical idea at least at first glance. It
would mean storing a variable sized list of columns somewhere that can
be consulted when the update happens. I don't know how the share lock
infrastructure works but I don't think it's obvious
(resending as I also accidentally CC'd pgsql-hackers-owner, not the list)
On 25/08/10 02:25, Luxenberg, Scott I. wrote:
This is just my email to notify you all that the project I've been
working on with Stephen, the PostgreSQL Performance Farm, has been
released. As of now, it only supports
On Wed, Aug 25, 2010 at 1:27 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
The fact that the file was modified twice after being removed at rev
2.88 seems really wacko. Are you sure that's not contributing to what
we're seeing here?
Yeah, that was
With 9.0b4, I am testing the new NOTIFY payload feature. One thing I noticed is
that it seems impossible to differentiate at the receiving end from:
NOTIFY test;
and
NOTIFY test,'';
So, it is impossible to differentiate between a notification with an empty
string payload and a notification
I wrote:
it appears from your report that OS X is also using ENOMEM when SHMALL
is exceeded, which is not all that surprising because actually none of
the spec-defined error codes cover SHMALL exhaustion.
A look into
http://www.opensource.apple.com/source/xnu/xnu-1504.7.4/bsd/kern/sysv_shm.c
On tis, 2010-08-17 at 21:48 +0300, Peter Eisentraut wrote:
On tis, 2010-08-17 at 20:55 +0300, Peter Eisentraut wrote:
On fre, 2010-08-13 at 20:20 -0400, Tom Lane wrote:
According to a discussion over in Fedora-land, $subject is true:
A.M. age...@themactionfaction.com writes:
So, it is impossible to differentiate between a notification with an
empty string payload and a notification without a payload due to the
backend protocol defining the payload as a string.
That's correct. This was baked into the FE/BE protocol in
On Wed, 25 Aug 2010, Tom Lane wrote:
Oleg Bartunov o...@sai.msu.su writes:
On Tue, 24 Aug 2010, Tom Lane wrote:
There's an entry in the 9.0 release notes saying that we've got
filtering dictionaries now. Cool, but I don't see any documentation
of the feature in textsearch.sgml. Shouldn't
Oleg Bartunov o...@sai.msu.su writes:
On Wed, 25 Aug 2010, Tom Lane wrote:
No --- that's documentation for a specific contrib module, not
documentation about the feature in general. Currently the general
description of dictionaries says that it's impossible for a dictionary
to modify the
On Wed, 2010-08-25 at 14:10 -0400, Tom Lane wrote:
Greg Stark gsst...@mit.edu writes:
It's still not a very practical idea at least at first glance. It
would mean storing a variable sized list of columns somewhere that can
be consulted when the update happens. I don't know how the share
Magnus Hagander mag...@hagander.net writes:
The current mapping used is the same one as on git.postgresql.org (see
attached file).
BTW, I noticed that this list omits several old committers:
162 bryanh
20 byronn
6 julian
1 mcguirk
(the numbers are the number of commits I find in
On 8/25/10 1:35 PM, Simon Riggs wrote:
If the row is key share locked (as opposed to tuple share locks we
already have), then an UPDATE would only work if it was a non-HOT
UPDATE. Yes, that would save us some effort in working out whether to
allow the UPDATE or not. It *is* more restrictive
Simon Riggs wrote:
On Tue, 2010-08-24 at 11:04 -0700, Josh Berkus wrote:
I've been looking at the open item which belongs with this doc:
http://www.postgresql.org/docs/9.0/static/backup-incremental-updated.html
I'm back from holidays today, so will begin looking at this and related
On Tue, Jul 13, 2010 at 11:31 PM, Markus Wanner mar...@bluegap.ch wrote:
This patch turns the existing autovacuum launcher into an always running
process, partly called the coordinator. If autovacuum is disabled, the
coordinator process still gets started and keeps around, but it doesn't
On Wed, Aug 25, 2010 at 9:39 PM, Itagaki Takahiro
itagaki.takah...@gmail.com wrote:
On Tue, Jul 13, 2010 at 11:31 PM, Markus Wanner mar...@bluegap.ch wrote:
This patch turns the existing autovacuum launcher into an always running
process, partly called the coordinator. If autovacuum is
On Aug 25, 2010, at 6:49 PM, Tom Lane wrote:
Magnus Hagander mag...@hagander.net writes:
The current mapping used is the same one as on git.postgresql.org (see
attached file).
BTW, I noticed that this list omits several old committers:
Julian Assange pr...@suburbia.net
That is _the_
On Thu, Aug 26, 2010 at 11:39 AM, Robert Haas robertmh...@gmail.com wrote:
On Tue, Jul 13, 2010 at 11:31 PM, Markus Wanner mar...@bluegap.ch wrote:
This patch turns the existing autovacuum launcher into an always running
process, partly called the coordinator.
It's not clear to me whether
FYI, we are planning to package Postgres 9.0RC1 tomorrow/Thursday, with
release on Monday/Tuesday of next week.
--
Bruce Momjian br...@momjian.ushttp://momjian.us
EnterpriseDB http://enterprisedb.com
+ It's impossible for everything to be true. +
--
A.M. age...@themactionfaction.com writes:
On Aug 25, 2010, at 6:49 PM, Tom Lane wrote:
BTW, I noticed that this list omits several old committers:
Julian Assange pr...@suburbia.net
That is _the_ Julian Assange who is in the news now. Very cool!
Yowza ... *that* Julian Assange? Cool, but
On Thu, Aug 26, 2010 at 12:45 AM, Steve Singer ssin...@ca.afilias.info wrote:
A clean build from the beta4 source tarball where I'm careful to install
into a clean (ie no old beta2 artifacts laying around waiting to be
overwritten) isn't reproducing the issue.
I'm happy to try other things if
76 matches
Mail list logo
