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.
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
>
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
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
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:
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
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
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 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
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
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 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 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
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
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 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
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 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 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
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 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
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/
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
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:
> 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
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:
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
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
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 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
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, 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 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 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 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'
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 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
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 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 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
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 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
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
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
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
"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
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
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
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
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
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 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
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)
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
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.
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 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
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
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
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
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
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
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
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
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
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
"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),
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
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
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 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
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 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
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: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://
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
"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
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
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
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
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
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
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
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-
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
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
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
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 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 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
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
92 matches
Mail list logo
