On Thu, Oct 20, 2011 at 9:51 PM, Fujii Masao wrote:
> On Thu, Oct 20, 2011 at 1:05 AM, Robert Haas wrote:
>> OK, so this is an artifact of the changes to make libpq communication
>> bidirectional. But I'm still confused about where the error is coming
>> from. In your OP, you wrote "In 9.2dev a
On Thu, Oct 20, 2011 at 1:05 AM, Robert Haas wrote:
> OK, so this is an artifact of the changes to make libpq communication
> bidirectional. But I'm still confused about where the error is coming
> from. In your OP, you wrote "In 9.2dev and 9.1, when walreceiver
> detects an error while sending
Hello,
> > Robert Haas writes:
> >> - Why does the second byte need special handling for 0xED and 0xF4?
> >
> > http://www.faqs.org/rfcs/rfc3629.html
> >
> > See section 4 in particular. The underlying requirement is to disallow
> > multiple representations of the same Unicode code point.
The
I wrote:
> ProcessStandbyHSFeedbackMessage has a race condition: it thinks it can
> call GetOldestXmin and then the result will politely hold still while
> it considers what to do next. But in fact, whoever has the oldest xmin
> could exit their transaction, allowing the global minimum to advance.
On Thu, Oct 20, 2011 at 07:33:59AM -0500, Kevin Grittner wrote:
> Dan Ports wrote:
> > The part that's harder is building the list of potential conflicts
> > that's used to identify safe snapshots for r/o transactions. That
> > (currently) has to happen atomically taking the snapshot.
>
> That's
On 10/20/2011 09:53 PM, Tom Lane wrote:
With that change, the correct test at line 795 would become
else if (pg_strcasecmp(prev_wd, "DROP") == 0&&
prev2_wd[0] == '\0')
I've committed this --- please adjust the EXECUTE patch to match.
Thanks for cleaning up the code to so
--On 20. Oktober 2011 02:02:09 +0200 Florian Pflug wrote:
In the mean time, the modified ports are all contained in the
attached tar.bz2, should any of ye fellow OSX users want to try them
out before that.
Simply extract that archive, and add
file://
to /opt/local/etc/macports/sources.conf
I wrote:
> What I suggest is that we redefine previous_word() as returning an empty
> string, not NULL, anytime there is no such preceding word. This is
> better than the current behavior because (a) it's less surprising and
> (b) it's not ambiguous. Right now the caller can't tell the difference
On Thu, Oct 20, 2011 at 10:49 AM, Kohei KaiGai wrote:
>>> part-3: drop statement reworks for other object classes
>>
>> This is going to need some rebasing.
>>
> OK, I rebased it.
>
> This patch includes bug-fix when we tried to drop non-existence
> operator family with IF EXISTS.
I'm thinking we
Alvaro Herrera writes:
> Excerpts from Josh Kupershmidt's message of mié oct 19 23:50:58 -0300 2011:
>> I assume this is an accepted quirk of previous_word() since we have
>> this existing similar code:
> Maybe both are wrong, though the DROP case seems to work so maybe it's
> just dead code.
I
Excerpts from Josh Kupershmidt's message of mié oct 19 23:50:58 -0300 2011:
> On Wed, Oct 19, 2011 at 10:40 PM, Tom Lane wrote:
> > Josh Kupershmidt writes:
> >> Incidentally, I was wondering what the heck was up with a clause like this:
> >> else if (pg_strcasecmp(prev_wd, "EXECUTE") == 0 &
Dan Ports wrote:
> I think it would be fairly sensible to push some of this into
> ProcArray, actually. The commit sequence numbers just involve
> assigning/incrementing a global counter when taking a snapshot and
> finishing a transaction -- that's not too much work, doesn't
> require any addit
12 matches
Mail list logo
