Josh Berkus wrote:
>> the behavior was the same up to the second UPDATE on Process 2, at
>> which point there was no deadlock. Process 2 was able to commit,
>> at which point Process 1 failed with:
>>
>> ERROR: could not serialize access due to concurrent update
>
> Does this happen immediat
On 24/08/10 04:08, Alvaro Herrera wrote:
Excerpts from Tom Lane's message of lun ago 23 19:44:02 -0400 2010:
Heikki Linnakangas writes:
[ "latch" proposal ]
This seems reasonably clean as far as signal conditions generated
internally to Postgres go, but I remain unclear on how it helps for
On 2010-08-24 8:25 AM +0300, igor polishchuk wrote:
Marko et al,
This is my first ever attempt of a patch review just for learning the
procedure. I'm not a postgres developer, so the review is partial and mostly
from the usability prospective.
That's all right. I'm sure any help is appreciated
On 08/23/2010 07:12 PM, Bruce Momjian wrote:
Josh Berkus wrote:
On 8/23/10 12:20 PM, Tom Lane wrote:
Josh Berkus writes:
I really don't see the value in making a command substantially less
intuitive in order to avoid a single keyword, unless it affects areas of
Postgres outside of this part
On Tue, August 24, 2010 08:32, Itagaki Takahiro wrote:
> I applied the attached patch to HEAD. concat(), concat_ws(), left(),
> right(), and reverse() are in it, but format() and sprintf() are not.
+1 to add also sprintf
Erik Rijkers
--
Sent via pgsql-hackers mailing list (pgsql-hackers@post
Which files need be modified?
sgml, html, and man-page or only sgml?
I am not familiar with this.
On Sun, 22 Aug 2010 08:25:59 -0700
David Fetter wrote:
> On Sun, Aug 22, 2010 at 10:03:32PM +0800, Quan Zongliang wrote:
> > Sure, I agree.
> > New patch attached. How about this?
>
> Docs re-added
Andrew Dunstan wrote:
>
>
> On 08/23/2010 07:12 PM, Bruce Momjian wrote:
> > Josh Berkus wrote:
> >> On 8/23/10 12:20 PM, Tom Lane wrote:
> >>> Josh Berkus writes:
> I really don't see the value in making a command substantially less
> intuitive in order to avoid a single keyword, unle
On Tue, Aug 24, 2010 at 2:05 PM, Quan Zongliang wrote:
> Which files need be modified?
> sgml, html, and man-page or only sgml?
> I am not familiar with this.
Only SGML. HTML and man pages are generated from the SGML.
--
Magnus Hagander
Me: http://www.hagander.net/
Work: http://www.redpill-
Robert Haas wrote:
> [moving to -hackers]
>
> On Thu, Aug 19, 2010 at 9:43 PM, Robert Haas wrote:
> > I suspect this is the same problem as bug #4897, and probably also the
> > same problem as this:
> > http://archives.postgresql.org/pgsql-bugs/2009-08/msg00114.php
> >
> > and maybe also this and
Applied.
---
Bruce Momjian wrote:
> Tom Lane wrote:
> > Bruce Momjian writes:
> > > OK, I have attached a proposed patch to improve this. I moved the
> > > pg_clog mention to a new paragraph and linked it to the reason the
On Tue, Aug 24, 2010 at 8:57 AM, Bruce Momjian wrote:
> Robert Haas wrote:
>> [moving to -hackers]
>>
>> On Thu, Aug 19, 2010 at 9:43 PM, Robert Haas wrote:
>> > I suspect this is the same problem as bug #4897, and probably also the
>> > same problem as this:
>> > http://archives.postgresql.org/p
Robert Haas wrote:
> >> This isn't really a "fix" for the bug in the sense that the nicest
> >> thing of all would be to prevent the child from exiting abnormally in
> >> the first place. ?But it's far from clear that we can control that.
> >
> > This URL has some interesting details on our problem
Bruce Momjian writes:
> Robert Haas wrote:
>> Yeah, that seems very plausible, although exactly how to verify I don't know.
> And here is confirmation from the Microsoft web site:
> In some instances, calling GetExitCode() against the failed process
> indicates the following
Tom Lane wrote:
> Bruce Momjian writes:
> > Robert Haas wrote:
> >> Yeah, that seems very plausible, although exactly how to verify I don't
> >> know.
>
> > And here is confirmation from the Microsoft web site:
>
> > In some instances, calling GetExitCode() against the failed process
Tom Lane wrote:
> Bruce Momjian writes:
> > Robert Haas wrote:
> >> Yeah, that seems very plausible, although exactly how to verify I don't
> >> know.
>
> > And here is confirmation from the Microsoft web site:
>
> > In some instances, calling GetExitCode() against the failed process
"David E. Wheeler" writes:
> I've been trying to come up with a simpler way to iterate over a series of
> values in pgTAP tests than by creating a table, inserting rows, and then
> selecting from the table. The best I've come up with so far is:
> CREATE TYPE vcmp AS ( lv semver, op text, rv
So I got annoyed by $SUBJECT just now while chasing Wheeler's bug
report. Seems like this would be a good thing to print. Should
it appear always, or just with VERBOSE, or ???
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To mak
On Tue, Aug 24, 2010 at 10:40:30AM -0400, Tom Lane wrote:
> So I got annoyed by $SUBJECT just now while chasing Wheeler's bug
> report. Seems like this would be a good thing to print. Should
> it appear always, or just with VERBOSE, or ???
+1 for always.
Cheers,
David.
--
David Fetter http://
On Tue, Aug 24, 2010 at 10:40 AM, Tom Lane wrote:
> So I got annoyed by $SUBJECT just now while chasing Wheeler's bug
> report. Seems like this would be a good thing to print. Should
> it appear always, or just with VERBOSE, or ???
I think showing it always is reasonable. I'd like to see it pr
On Tue, Aug 24, 2010 at 10:56 AM, Robert Haas wrote:
> On Tue, Aug 24, 2010 at 10:40 AM, Tom Lane wrote:
>> So I got annoyed by $SUBJECT just now while chasing Wheeler's bug
>> report. Seems like this would be a good thing to print. Should
>> it appear always, or just with VERBOSE, or ???
>
> I
Robert Haas writes:
> On Tue, Aug 24, 2010 at 10:56 AM, Robert Haas wrote:
>> I think showing it always is reasonable. I'd like to see it printed
>> in a form such that casting to regproc will succeed.
> On second thought, that second sentence may not make sense.
It does not, because it's not
On Aug 23, 2010, at 11:24 PM, Joe Conway wrote:
> Maybe something like this?
>
> select cmp_ok(a,b,c)
> from
> (
>values('1.2.2'::varchar, '='::text, '1.2.2'::varchar),
> ('1.2.23', '=', '1.2.23'),
> ('1.2.42', '=', '1.2.32')
> ) as ss(a, b, c);
> cmp_ok
>
> t
> t
On Aug 24, 2010, at 7:05 AM, Tom Lane wrote:
> You could do it like this:
>
>SELECT cmp_ok(lv, op, rv) FROM unnest(ARRAY[
>ROW('1.2.2', '=', '1.2.2'),
>ROW('1.2.23', '=', '1.2.23')
>]::vcmp[]);
Oh, duh. :-)
>> psql:t/types.pg:205: ERROR: invalid memory alloc request si
On Tue, Aug 24, 2010 at 11:06 AM, Tom Lane wrote:
> Robert Haas writes:
>> On Tue, Aug 24, 2010 at 10:56 AM, Robert Haas wrote:
>>> I think showing it always is reasonable. I'd like to see it printed
>>> in a form such that casting to regproc will succeed.
>
>> On second thought, that second se
Hi,
On Tuesday 24 August 2010 16:40:30 Tom Lane wrote:
> So I got annoyed by $SUBJECT just now while chasing Wheeler's bug
> report. Seems like this would be a good thing to print. Should
> it appear always, or just with VERBOSE, or ???
I vote for only showing it with verbose - not that its a ne
"David E. Wheeler" writes:
> On Aug 24, 2010, at 7:05 AM, Tom Lane wrote:
>> I get a core dump on that one ... looking ...
> Well I'm glad I reported it, then.
The issue seems to be that given a construct like
ARRAY[
ROW('1.2.2'::semver, '='::text, '1.2.2'::semver),
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_arg1, function_arg2, ...)
Yeah, that's what I had in mind, but I'm still fumbling for the ri
Andres Freund writes:
> On Tuesday 24 August 2010 16:40:30 Tom Lane wrote:
>> So I got annoyed by $SUBJECT just now while chasing Wheeler's bug
>> report. Seems like this would be a good thing to print. Should
>> it appear always, or just with VERBOSE, or ???
> I vote for only showing it with v
On Tuesday 24 August 2010 17:36:50 Tom Lane wrote:
> Andres Freund writes:
> > On Tuesday 24 August 2010 16:40:30 Tom Lane wrote:
> >> So I got annoyed by $SUBJECT just now while chasing Wheeler's bug
> >> report. Seems like this would be a good thing to print. Should
> >> it appear always, or j
On Tue, Aug 24, 2010 at 11:32 AM, Tom Lane wrote:
> I think it wouldn't take too much code to defend against this in
> transformArrayExpr, but I'm a tad worried about whether there are
> similar cases elsewhere. The generic problem is that we suppose that
> different values are compatible if they
Excerpts from Tom Lane's message of mar ago 24 11:36:50 -0400 2010:
> Andres Freund writes:
> > On Tuesday 24 August 2010 16:40:30 Tom Lane wrote:
> >> So I got annoyed by $SUBJECT just now while chasing Wheeler's bug
> >> report. Seems like this would be a good thing to print. Should
> >> it ap
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_arg1, function_arg2, ...)
> Yeah, that's what I had in mind, but I'm still fumbl
Robert Haas writes:
> On Tue, Aug 24, 2010 at 11:32 AM, Tom Lane wrote:
>> I think it wouldn't take too much code to defend against this in
>> transformArrayExpr, but I'm a tad worried about whether there are
>> similar cases elsewhere. The generic problem is that we suppose that
>> different va
Tom,
That was it! My implementation of cancel() was swallowing the result
message. Thanks so much, I've got it working now.
--
Eric Simon
The IQ Group, Inc.
-Original Message-
From: pgsql-hackers-ow...@postgresql.org
[mailto:pgsql-hackers-ow...@postgresql.org] On Behalf Of Tom Lane
S
Excerpts from Tom Lane's message of mar ago 24 09:36:05 -0400 2010:
> "McGehee, Robert" writes:
> > Thanks Tom and Alvaro for clearing up my confusion.
> > \l showed that a485099 had both (C)reate and (T)emporary access.
> > Revoking those allowed me to drop the role. Thanks for the help!
>
> I w
On Tue, Aug 24, 2010 at 12:06:34PM -0400, Tom Lane wrote:
> 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_arg1, fun
Hi,
I want to run two different versions of postgresql-8.2.5 under eclipse.
But, it requires me to change PGDATA and LD_LIBRARY_PATH to switch.
Moreover, to let eclipse know the changes, I need to modify .profile
under my home folder, and log out and log in. (I am using Ubuntu.)
Is there a way t
On Tue, Aug 24, 2010 at 5:06 PM, Tom Lane wrote:
> Function Scan on pg_catalog.unnest f (cost=0.00..1.50 rows=100 width=96)
> Output: (((lv)::text || op) || (rv)::text)
> Function Call: unnest(ARRAY[ROW(('1.2.2'::text)::semver, '='::text,
> ('1.2.2'::text)::semver), ROW('1.2.23', '=', '1.2.
Alvaro Herrera writes:
> Happy to change it to whatever is deemed appropriate. "privileges for %s"
> sounds good; I'll do that unless somebody comes up with a better idea
> which outvotes this one.
> Backpatch all the way to 8.1? Code doesn't exist prior to that.
I'd vote for fixing it in HEAD
Greg Stark writes:
> On Tue, Aug 24, 2010 at 5:06 PM, Tom Lane wrote:
>> Function Scan on pg_catalog.unnest f (cost=0.00..1.50 rows=100 width=96)
>> Output: (((lv)::text || op) || (rv)::text)
>> Function Call: unnest(ARRAY[ROW(('1.2.2'::text)::semver, '='::text,
>> ('1.2.2'::text)::semver)
On Tue, Aug 24, 2010 at 12:27 PM, Tom Lane wrote:
> This is a crash in released branches, so we have to have a
> back-patchable fix. Anything that gets out from under the typmod issue
> isn't going to be back-patchable.
I nominate that comment for "understatement of the year".
--
Robert Haas
E
On Tue, Aug 24, 2010 at 1:21 PM, Tom Lane wrote:
> Greg Stark writes:
>> On Tue, Aug 24, 2010 at 5:06 PM, Tom Lane wrote:
>>> Function Scan on pg_catalog.unnest f (cost=0.00..1.50 rows=100 width=96)
>>> Output: (((lv)::text || op) || (rv)::text)
>>> Function Call: unnest(ARRAY[ROW(('1.2.2'
On Tue, Aug 24, 2010 at 1:19 PM, Tom Lane wrote:
> Alvaro Herrera writes:
>> Happy to change it to whatever is deemed appropriate. "privileges for %s"
>> sounds good; I'll do that unless somebody comes up with a better idea
>> which outvotes this one.
>
>> Backpatch all the way to 8.1? Code doe
All,
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
... and my viewpoint is that the procedure described should be *cut*
from the official docs and put on the Wiki, with warnings. It's simply
far too hack
Josh Berkus wrote:
> All,
>
> 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
>
> ... and my viewpoint is that the procedure described should be *cut*
> from the official docs and put on the Wiki, with
On Aug 24, 2010, at 10:21 AM, Tom Lane wrote:
>> This may be the ultimate bike-shed but Wouldn't this be clearer the
>> other way around? I generally think input comes first and then output.
>
> The order was bothering me a bit too, but there's a generic decision
> in there that the tlist is show
"David E. Wheeler" writes:
> On Aug 24, 2010, at 10:21 AM, Tom Lane wrote:
>> The order was bothering me a bit too, but there's a generic decision
>> in there that the tlist is shown before any node-type-specific items.
>> Not sure that we want to move it to the bottom for all of them.
> Does it
2010/8/24 Pei He :
> I want to run two different versions of postgresql-8.2.5 under eclipse.
>
> But, it requires me to change PGDATA and LD_LIBRARY_PATH to switch.
>
> Moreover, to let eclipse know the changes, I need to modify .profile
> under my home folder, and log out and log in. (I am using
Thanks, Nicolas.
It works.
--
Pei
On Tue, Aug 24, 2010 at 2:38 PM, Nicolas Barbier
wrote:
> 2010/8/24 Pei He :
>
>> I want to run two different versions of postgresql-8.2.5 under eclipse.
>>
>> But, it requires me to change PGDATA and LD_LIBRARY_PATH to switch.
>>
>> Moreover, to let eclipse kno
Bruce Momjian wrote:
> Josh Berkus wrote:
> > All,
> >
> > 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
> >
> > ... and my viewpoint is that the procedure described should be *cut*
> > from the o
On Tue, Aug 24, 2010 at 15:58, Tom Lane wrote:
> Bruce Momjian writes:
>> Robert Haas wrote:
>>> Yeah, that seems very plausible, although exactly how to verify I don't
>>> know.
>
>> And here is confirmation from the Microsoft web site:
>
>> In some instances, calling GetExitCode() agains
Magnus Hagander wrote:
> On Tue, Aug 24, 2010 at 15:58, Tom Lane wrote:
> > Bruce Momjian writes:
> >> Robert Haas wrote:
> >>> Yeah, that seems very plausible, although exactly how to verify I don't
> >>> know.
> >
> >> And here is confirmation from the Microsoft web site:
> >
> >> ? ? ? In som
On Tue, Aug 24, 2010 at 21:14, Bruce Momjian wrote:
> Magnus Hagander wrote:
>> On Tue, Aug 24, 2010 at 15:58, Tom Lane wrote:
>> > Bruce Momjian writes:
>> >> Robert Haas wrote:
>> >>> Yeah, that seems very plausible, although exactly how to verify I don't
>> >>> know.
>> >
>> >> And here is c
On 2010-08-24 9:04 PM +0300, Josh Berkus wrote:
... and my viewpoint is that the procedure described should be *cut*
from the official docs and put on the Wiki, with warnings. It's simply
far too hackish and dependant on DBA understanding of PostgreSQL
internals to belong in the main docs.
In 9
On Tue, Aug 24, 2010 at 3:10 PM, Magnus Hagander wrote:
> On Tue, Aug 24, 2010 at 15:58, Tom Lane wrote:
>> Bruce Momjian writes:
>>> Robert Haas wrote:
Yeah, that seems very plausible, although exactly how to verify I don't
know.
>>
>>> And here is confirmation from the Microsoft web
On Tue, Aug 24, 2010 at 21:39, Robert Haas wrote:
> On Tue, Aug 24, 2010 at 3:10 PM, Magnus Hagander wrote:
>> On Tue, Aug 24, 2010 at 15:58, Tom Lane wrote:
>>> Bruce Momjian writes:
Robert Haas wrote:
> Yeah, that seems very plausible, although exactly how to verify I don't
> kn
Marko Tiikkaja writes:
> Is this method not reliable then? Can something go wrong even if the
> user does exactly what the documentation says?
It is not. This whole discussion started from somebody reporting that
it didn't work.
regards, tom lane
--
Sent via pgsql-ha
On 24/08/10 16:35, Boxuan Zhai wrote:
Hi,
I finished the MERGE on inheritance tables. Now comes the merge_v201
Oh, great! That means that all the known issues are fixed now, and all
that's left is fixing any issues raised in review.
I've added this to the September commitfest, but I hope I'
On 8/24/10 12:42 PM, Tom Lane wrote:
> Marko Tiikkaja writes:
>> Is this method not reliable then? Can something go wrong even if the
>> user does exactly what the documentation says?
>
> It is not. This whole discussion started from somebody reporting that
> it didn't work.
Again, given that
On Tue, Aug 24, 2010 at 9:58 AM, Tom Lane wrote:
> Bruce Momjian writes:
>> Robert Haas wrote:
>>> Yeah, that seems very plausible, although exactly how to verify I don't
>>> know.
>
>> And here is confirmation from the Microsoft web site:
>
>> In some instances, calling GetExitCode() agai
On Tue, 2010-08-24 at 13:44 -0700, Josh Berkus wrote:
> On 8/24/10 12:42 PM, Tom Lane wrote:
> > Marko Tiikkaja writes:
> >> Is this method not reliable then? Can something go wrong even if the
> >> user does exactly what the documentation says?
> >
> > It is not. This whole discussion started
On Tue, Aug 24, 2010 at 4:44 PM, Josh Berkus wrote:
> On 8/24/10 12:42 PM, Tom Lane wrote:
>> Marko Tiikkaja writes:
>>> Is this method not reliable then? Can something go wrong even if the
>>> user does exactly what the documentation says?
>>
>> It is not. This whole discussion started from so
On Tue, Aug 24, 2010 at 11:02:41PM +0300, Heikki Linnakangas wrote:
> On 24/08/10 16:35, Boxuan Zhai wrote:
> >Hi,
> >
> >I finished the MERGE on inheritance tables. Now comes the merge_v201
>
> Oh, great! That means that all the known issues are fixed now, and
> all that's left is fixing any issue
Robert Haas writes:
> There is some amount of user code (I'm not sure preceisely how much)
> that runs after shared memory is mapped and before the deadman switch
> is engaged.
Er ... what would you define as "user code"?
The deadman switch is engaged at the point where we create a PGPROC.
Befor
On Mon, Aug 23, 2010 at 4:50 AM, Magnus Hagander wrote:
> If we need to do it at all. Tom's latest lookover indicates that he
> thinks it may be good the way it is, and we need some more detailed
> checks. I know Robert has said he wants to dedicate some time to doing
> such checks this week, and
I think I've been able to reproduce the issue floating around with
streaming replication on AIX.
LOG: could not bind IPv6 socket: The socket name is already in use.
HINT: Is another postmaster already running on port 5433? If not, wait
a few seconds and retry.
LOG: database system was shut
Hi,
I just noticed that we restrict creation of a role named "public", but
this is case-sensitive -- i.e. we don't restrict roles named PUBLIC,
etc.
Is this intended?
--
Álvaro Herrera
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
Alvaro Herrera writes:
> I just noticed that we restrict creation of a role named "public", but
> this is case-sensitive -- i.e. we don't restrict roles named PUBLIC,
> etc.
> Is this intended?
Yes. If you had a role named that, you might think that
GRANT whatever TO PUBLIC
should refer
Excerpts from Tom Lane's message of mar ago 24 19:04:14 -0400 2010:
> Alvaro Herrera writes:
> > I just noticed that we restrict creation of a role named "public", but
> > this is case-sensitive -- i.e. we don't restrict roles named PUBLIC,
> > etc.
>
> > Is this intended?
>
> Yes. If you had a
Alvaro Herrera writes:
> The reason I'm asking is that I'm trying to allow "public" to be passed
> to has_table_privileges(), and have it check for the PUBLIC pseudo-role.
> Originally I had coded it using pg_strcasecmp() on the grounds that any
> case should refer to this.
That would be incorrec
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.
> This worked fine with beta2 but now seems to be an issue on beta4.
> If I do
> export LIBPATH=/opt/
On Wed, Aug 25, 2010 at 4:56 AM, Andres Freund wrote:
> On Tue, Aug 24, 2010 at 11:02:41PM +0300, Heikki Linnakangas wrote:
> > On 24/08/10 16:35, Boxuan Zhai wrote:
> > >Hi,
> > >
> > >I finished the MERGE on inheritance tables. Now comes the merge_v201
> >
> > Oh, great! That means that all the
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?
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgr
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 first added to trunk
> - this would explain
On Tue, Aug 24, 2010 at 5:11 PM, Tom Lane wrote:
> Robert Haas writes:
>> There is some amount of user code (I'm not sure preceisely how much)
>> that runs after shared memory is mapped and before the deadman switch
>> is engaged.
>
> Er ... what would you define as "user code"?
Our code, as opp
On Tue, Aug 24, 2010 at 4:56 PM, Andres Freund 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...
That sounds like it might cause more problems than it sol
On Fri, Aug 20, 2010 at 11:05 AM, Euler Taveira de Oliveira
wrote:
> Dmitriy Igrishin escreveu:
>> /* NOT presents - NULL. Why not "0" ? */
>> const char* sqlstate = Pg::PQresultErrorField(res, PG_DIAG_SQLSTATE);
>>
> That's because the protocol doesn't set error field when the command
> s
I tried to revise the patch. It allows plugins to get control next to
client authentication, but before returning the status to users.
This change enables plugins which should be invoked on authentication
failed to utilize this hook, not only assignment of session security
label.
At the same time,
On Tue, Aug 24, 2010 at 08:17:15PM -0400, Robert Haas wrote:
> On Tue, Aug 24, 2010 at 5:11 PM, Tom Lane wrote:
> > Robert Haas writes:
> >> There is some amount of user code (I'm not sure preceisely how
> >> much) that runs after shared memory is mapped and before the
> >> deadman switch is enga
On Wed, Aug 25, 2010 at 08:11:18AM +0800, Boxuan Zhai wrote:
> On Wed, Aug 25, 2010 at 4:56 AM, Andres Freund wrote:
>
> > On Tue, Aug 24, 2010 at 11:02:41PM +0300, Heikki Linnakangas wrote:
> > > On 24/08/10 16:35, Boxuan Zhai wrote:
> > > >Hi,
> > > >
> > > >I finished the MERGE on inheritance
Robert Haas escreveu:
> On Fri, Aug 20, 2010 at 11:05 AM, Euler Taveira de Oliveira
> wrote:
>> Dmitriy Igrishin escreveu:
>>> /* NOT presents - NULL. Why not "0" ? */
>>> const char* sqlstate = Pg::PQresultErrorField(res, PG_DIAG_SQLSTATE);
>>>
>> That's because the protocol doesn't set e
On Tue, Aug 24, 2010 at 9:44 PM, Euler Taveira de Oliveira
wrote:
> Robert Haas escreveu:
>> On Fri, Aug 20, 2010 at 11:05 AM, Euler Taveira de Oliveira
>> wrote:
>>> Dmitriy Igrishin escreveu:
/* NOT presents - NULL. Why not "0" ? */
const char* sqlstate = Pg::PQresultErrorFiel
Robert Haas writes:
> I suppose we could change the function to return 0 always when the
> operation is not an error or warning report, rather than NULL, but
> certainly we wouldn't want to include those bytes in *every* success
> message, so they'd have to be something that the libpq inferred
Robert Haas escreveu:
> It appears to me that it already is documented. The very first
> sentence of the documentation reads:
>
> Returns an individual field of an error report.
>
> And a few sentences later it says:
>
> NULL is returned if the PGresult is not an error or warning result
>
I'm
Tom Lane escreveu:
> The real issue
> here is that there are no SQLSTATEs assigned for any error/warning
> conditions generated internally in libpq.
>
Did you mean successful conditions? Only warning/error conditions produce a
SQLSTATE.
> As far as this particular example goes, I think it's highl
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 existed on the branch from the moment it was first added to tr
Euler Taveira de Oliveira writes:
> What I'm thinking is something like
You didn't actually read what I said, did you? That patch will have
precisely zero effect on the OP's example.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org
Hey all,
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, due to the use of workers.
More details can be found in the readme. The Git repository is located
here: http:
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 ;-)
> 2. Any non-ASCII characters in, for example, contributor's names
Hi, I start to review JSON patch.
On Fri, Aug 13, 2010 at 7:33 PM, Joseph Adams
wrote:
> Updated patch: the JSON code has all been moved into core, so this
> patch is now for a built-in data type.
I think the patch can be split into two pieces:
1. Basic I/O support for JSON type (in/out/valid
7. I think we need to write and include in the fine documentation some
"big picture" documentation about enhanced security providers. Of
course, we have to decide what we want to say. But the SECURITY LABEL
documentation is just kind of hanging out there in space right now; it
>
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.
92 matches
Mail list logo
