2010/8/25 Robert Haas :
> On Wed, Aug 25, 2010 at 1:34 AM, Itagaki Takahiro
> 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
On Thu, Aug 26, 2010 at 12:45 AM, Steve Singer 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 people suggest the
"A.M." writes:
> On Aug 25, 2010, at 6:49 PM, Tom Lane wrote:
>> BTW, I noticed that this list omits several old committers:
>> Julian Assange
> That is _the_ Julian Assange who is in the news now. Very cool!
Yowza ... *that* Julian Assange? Cool, but maybe we shouldn't
advertise the connectio
FYI, we are planning to package Postgres 9.0RC1 tomorrow/Thursday, with
release on Monday/Tuesday of next week.
--
Bruce Momjian http://momjian.us
EnterpriseDB http://enterprisedb.com
+ It's impossible for everything to be true. +
--
Sent via pgsql-ha
On Thu, Aug 26, 2010 at 11:39 AM, Robert Haas wrote:
>> On Tue, Jul 13, 2010 at 11:31 PM, Markus Wanner wrote:
>>> This patch turns the existing autovacuum launcher into an always running
>>> process, partly called the coordinator.
>
> It's not clear to me whether it's better to have a single coo
On Aug 25, 2010, at 6:49 PM, Tom Lane wrote:
> Magnus Hagander 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
That is _the_ Julian Assange who is in the ne
On Wed, Aug 25, 2010 at 9:39 PM, Itagaki Takahiro
wrote:
> On Tue, Jul 13, 2010 at 11:31 PM, Markus Wanner 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
On Tue, Jul 13, 2010 at 11:31 PM, Markus Wanner 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
> dispatch vacuum job
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 r
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 restric
Magnus Hagander 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 cvs2cl for each name).
On Wed, 2010-08-25 at 14:10 -0400, Tom Lane wrote:
> Greg Stark 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
> > inf
Oleg Bartunov 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 input lexe
On Wed, 25 Aug 2010, Tom Lane wrote:
Oleg Bartunov 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?
"A.M." 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 2003;
we're not going to cha
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:
> > > http://lists.fedoraproject.org/pipermail/devel/
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
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 wi
On Wed, Aug 25, 2010 at 1:27 PM, Tom Lane wrote:
> Robert Haas 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-conversi
(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 9.0,
Greg Stark 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 that there i
"A.M." 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 already running an
On Wed, Aug 25, 2010 at 6:34 PM, Tom Lane 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 enough about i
Michael Haggerty 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
> re-added. In
Josh Berkus 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 need not conc
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
Robert Haas 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 did figure out how
On Wed, Aug 25, 2010 at 5:35 PM, 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:
>
Interestingly this weirdness first surfaced due to a previous
discussion of using git about 3 and a half years ago:
http
> 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 improv
* 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 lim
On Wed, Aug 25, 2010 at 12:02 PM, Michael Haggerty 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 which to branch
>Stephen Frost 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 we'd
> have ale
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 i
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 simila
On 25/08/10 16:43, Tom Lane wrote:
> Max Bowsher 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
Steve Singer wrote:
Tom Lane wrote:
Steve Singer 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 thinking the original re
Max Bowsher 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
>>
>>
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 su
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 need
Tom Lane wrote:
Steve Singer 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 binaries I
am not able to
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
Nicolas Barbier writes:
> 2010/8/25 Simon Riggs :
>> 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 are way
> more common that updates to UNIQU
On Wed, Aug 25, 2010 at 3:20 PM, Simon Riggs 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 needs more thought.
2010/8/25 Simon Riggs :
> On Wed, 2010-08-25 at 16:14 +0200, Nicolas Barbier wrote:
>> 2010/8/25 Simon Riggs :
>>
>> > "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 co
On Wed, 2010-08-25 at 16:14 +0200, Nicolas Barbier wrote:
> 2010/8/25 Simon Riggs :
>
> > "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 understand Markus'
On Wed, Aug 25, 2010 at 1:34 AM, Itagaki Takahiro
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 document/content distinct
Dimitri Fontaine 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 might suggest that th
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.
On Wed, Aug 25, 2010 at 10:02 AM, Simon Riggs 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 relevan
2010/8/25 Simon Riggs :
> "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 subscription:
htt
[resending after noticing that "reply all" resulted in sending to
pgsql-hackers-owner rather than pgsql-hackers]
"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
Max Bowsher 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
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
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:
http://www.postgresql.org/mailpref/pgsql
Oleg Bartunov 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
> http://develo
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 Lane wrote:
Robert Haas writes:
> There are also a number of commits that differ in order between the
> two repos,
On 25/08/10 04:21, Tom Lane wrote:
> Robert Haas 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
> remotes/origin/unlabeled-1.90.2
>
On Wed, Aug 25, 2010 at 13:19, Robert Haas 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
>>
>> A
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 Lane wrote:
Robert Haas writes:
There are also a number of commits that differ in order between the
two repos, and an even larger number where commits are duplicated or
merged i
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
http://developer.postgresql.org/pgdocs/postgres
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 us
On 25/08/10 01:15, Robert Haas wrote:
> On Fri, Aug 20, 2010 at 1:56 PM, Max Bowsher 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 it was
On Wed, Aug 25, 2010 at 5:36 AM, Simon Riggs 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 was thinking about
On Tue, Aug 24, 2010 at 11:21 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Fri, Aug 20, 2010 at 1:56 PM, Max Bowsher 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 exist
On Wed, Aug 25, 2010 at 13:03, Max Bowsher wrote:
> On 25/08/10 09:18, Magnus Hagander wrote:
>> On Wed, Aug 25, 2010 at 07:11, Tom Lane wrote:
>>> Robert Haas writes:
>
2. Any non-ASCII characters in, for example, contributor's names show
up differently in the two repos. Generally, t
On 25/08/10 09:18, Magnus Hagander wrote:
> On Wed, Aug 25, 2010 at 07:11, Tom Lane wrote:
>> Robert Haas 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 the new repo is garbled; al
On Fri, 2010-08-20 at 15:59 -0400, Tom Lane wrote:
> Josh Berkus 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 value. If some
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 mail
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 an
On Thu, 2010-08-19 at 19:06 -0400, Tom Lane wrote:
> Fujii Masao 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 trace_recovery_mess
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.
--
Simo
On Wed, Aug 25, 2010 at 07:11, Tom Lane wrote:
> Robert Haas writes:
>> 1. The new conversion seems to have stolen the apostrophe from "D'Arcy
>> J.M. Cain ", rendering him "DArcy J.M. Cain
>> ".
>
> Yeah, I see that too. It's probably bad input rather than the
> converter's fault ;-)
indeed. W
On Wed, Aug 25, 2010 at 5:44 AM, Josh Berkus 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 bug reports a
Argument List?
--
dim
Le 24 août 2010 à 18:06, Tom Lane a écrit :
> I wrote:
>> Robert Haas 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: function_name(function_a
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 t
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 e
76 matches
Mail list logo
