2010/8/25 Robert Haas robertmh...@gmail.com:
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
Hi,
On 08/25/2010 10: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.
I think you meant it the other way around: an UPDATE on a key share
locked tuple only works if it *was*
I thought it would be interesting to see how other databases handle
this peculiar deadlock situation.
I didn't have access to any Oracle or Sybase databases, but for what
it's worth I've tested MySQL.
Results:
1. Process 1 successfully made its update and managed to commit.
2. Process 1 second
Hitoshi Harada umi.tan...@gmail.com writes:
It depends on use cases, but in my mind plain text will do for us. If
we have JavaScript engine in PostgreSQL like pl/v8 and it handles
on-disk format as-is, then we should choose the kind of format, but in
either text or binary format way it is
Tom Lane t...@sss.pgh.pa.us writes:
Now you might suggest that the function itself is redundant with the
information given in the FunctionScan node line and so we need only
show the argument list. Unfortunately there are cases where this fails;
in particular, the named function could have
Hi,
thanks for your feedback on this, it sort of got lost below the
discussion about the dynamic shared memory stuff, IMO.
On 08/26/2010 04:39 AM, Robert Haas wrote:
It's not clear to me whether it's better to have a single coordinator
process that handles both autovacuum and other things,
On Tue, 2010-08-24 at 18:23 -0700, David Fetter wrote:
On Wed, Aug 25, 2010 at 08:11:18AM +0800, Boxuan Zhai wrote:
On Wed, Aug 25, 2010 at 4:56 AM, Andres Freund and...@anarazel.de wrote:
The concurrency issues are not involved. I don't know much about
this part. I think we need more
Itagaki-san,
thanks for reviewing this.
On 08/26/2010 03:39 AM, Itagaki Takahiro wrote:
Other changes in the patch doesn't seem be always needed for the purpose.
In other words, the patch is not minimal.
Hm.. yeah, maybe the separation between step1 and step2 is a bit
arbitrary. I'll look
On 24/08/10 02:44, Tom Lane wrote:
Heikki Linnakangasheikki.linnakan...@enterprisedb.com 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
response to actual signals.
You can can
On 2010-08-25 12:44 PM +0300, Heikki Linnakangas wrote:
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?
I think what Andres means is: T1 starts a
On 08/26/2010 05:01 AM, Itagaki Takahiro wrote:
Markus, do you need B? Or A + standard backend processes are enough?
If you need B eventually, starting with B might be better.
No, I certainly don't need B.
Why not just use an ordinary backend to do user defined background
processing? It
On Thu, Aug 26, 2010 at 7:42 PM, Markus Wanner mar...@bluegap.ch wrote:
Markus, do you need B? Or A + standard backend processes are enough?
No, I certainly don't need B.
OK, I see why you proposed coordinator hook (yeah, I call it hook :)
rather than adding user-defined processes.
Why not
Itagaki-san,
On 08/26/2010 01:02 PM, Itagaki Takahiro wrote:
OK, I see why you proposed coordinator hook (yeah, I call it hook :)
rather than adding user-defined processes.
I see. If you call that a hook, I'm definitely not a hook-hater ;-) at
least not according to your definition.
On Thu, Aug 26, 2010 at 00:49, Tom Lane t...@sss.pgh.pa.us 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:
162 bryanh
20 byronn
6
On Thu, Aug 26, 2010 at 05:45, Tom Lane t...@sss.pgh.pa.us wrote:
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
On Thu, Aug 26, 2010 at 6:07 AM, Markus Wanner mar...@bluegap.ch wrote:
What'd be the benefits of having separate coordinator processes? They'd be
doing pretty much the same: coordinate background processes. (And yes, I
clearly consider autovacuum to be just one kind of background process).
I
Right, sorry about that, one of those stupid things I did on a lack of
sleep. The github is now here:
http://github.com/slux/PostgreSQL-Performance-Farm
-Original Message-
From: Heikki Linnakangas [mailto:heikki.linnakan...@enterprisedb.com]
Sent: Wednesday, August 25, 2010 2:31 PM
To:
Magnus Hagander wrote:
On Thu, Aug 26, 2010 at 00:49, Tom Lane t...@sss.pgh.pa.us 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:
Bruce Momjian br...@momjian.us writes:
Dan McGuirk is definitely right. I do not remember Julian Assange at
all. Why do we believe it is Julian Assange?
There's half a dozen commits from back around 1996 applied by Marc
on behalf of Julian Assange pr...@suburbia.net, and then about
half a
On Thu, 26 Aug 2010, Bruce Momjian wrote:
Magnus Hagander wrote:
On Thu, Aug 26, 2010 at 00:49, Tom Lane t...@sss.pgh.pa.us 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
Magnus Hagander mag...@hagander.net writes:
On Thu, Aug 26, 2010 at 00:49, Tom Lane t...@sss.pgh.pa.us wrote:
BTW, I noticed that this list omits several old committers:
Added to the list used.
Just for the archives, would you post the current list? I lost track of
who asked for their email
On Thu, Aug 26, 2010 at 15:53, Tom Lane t...@sss.pgh.pa.us wrote:
Magnus Hagander mag...@hagander.net writes:
On Thu, Aug 26, 2010 at 00:49, Tom Lane t...@sss.pgh.pa.us wrote:
BTW, I noticed that this list omits several old committers:
Added to the list used.
Just for the archives, would
Tom Lane wrote:
Bruce Momjian br...@momjian.us writes:
Dan McGuirk is definitely right. I do not remember Julian Assange at
all. Why do we believe it is Julian Assange?
There's half a dozen commits from back around 1996 applied by Marc
on behalf of Julian Assange pr...@suburbia.net, and
Excerpts from Magnus Hagander's message of jue ago 26 09:55:34 -0400 2010:
'thomas' : ('Thomas G. Lockhart', 'lockh...@alumni.caltech.edu'),
Curious about this address -- in his farewell message, Thomas used
lockh...@fourpalms.org:
I wrote:
The issue seems to be that given a construct like
ARRAY[
ROW('1.2.2'::semver, '='::text, '1.2.2'::semver),
ROW('1.2.23', '=', '1.2.23')
]
the parser is satisfied upon finding that all the array elements are
of type RECORD. It doesn't do
On Aug 26, 2010, at 9:05 AM, Tom Lane wrote:
On reflection, I think that the current system design for this is
predicated on the theory that RECORDs really are all the same type, and
the executor had better be prepared to cope with a series of RECORDs
that have different tupdescs, or throw
Alvaro Herrera wrote:
Excerpts from Magnus Hagander's message of jue ago 26 09:55:34 -0400 2010:
'thomas' : ('Thomas G. Lockhart', 'lockh...@alumni.caltech.edu'),
Curious about this address -- in his farewell message, Thomas used
lockh...@fourpalms.org:
Bruce Momjian br...@momjian.us writes:
Alvaro Herrera wrote:
'thomas' : ('Thomas G. Lockhart', 'lockh...@alumni.caltech.edu'),
Curious about this address -- in his farewell message, Thomas used
lockh...@fourpalms.org:
Yes, both emails were valid. The fourplams is one he used only toward
I wonder whether we shouldn't
use the most recent address we have for
the git conversion, though.
Thomas, do you have a preference? See
http://archives.postgresql.org/pgsql-hackers/2010-08/msg01078.php
for
context.
I'd already
I'm reviving the effort I started a while back to make COPY faster:
http://archives.postgresql.org/pgsql-patches/2008-02/msg00100.php
http://archives.postgresql.org/pgsql-patches/2008-03/msg00015.php
The patch I now have is based on using memchr() to search end-of-line.
In a nutshell:
* we
On Tue, Aug 24, 2010 at 9:58 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Bruce Momjian br...@momjian.us 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,
Robert Haas robertmh...@gmail.com writes:
On Tue, Aug 24, 2010 at 9:58 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Given the existence of the deadman switch mechanism (which I hadn't
remembered when this thread started), I'm coming around to the idea that
we could just treat exit(128) as nonfatal
Alvaro Herrera alvhe...@commandprompt.com writes:
Code is here:
else if (deptype == SHARED_DEPENDENCY_ACL)
appendStringInfo(descs, _(access to %s),
objdesc);
in StoreObjectDescription().
Happy to change it to whatever is deemed
Robert,
On 08/26/2010 02:44 PM, Robert Haas wrote:
I dunno. It was just a thought. I haven't actually looked at the
code to see how much synergy there is. (Sorry, been really busy...)
No problem, was just wondering if there's any benefit you had in mind.
On the more general topic of
Excerpts from Tom Lane's message of jue ago 26 14:59:43 -0400 2010:
Alvaro Herrera alvhe...@commandprompt.com writes:
Code is here:
else if (deptype == SHARED_DEPENDENCY_ACL)
appendStringInfo(descs, _(access to %s), objdesc);
in StoreObjectDescription().
Heikki Linnakangas heikki.linnakan...@enterprisedb.com writes:
* we perform possible encoding conversion early, one input block at a
time, rather than after splitting the input into lines. This allows us
to assume in the later stages that the data is in server encoding,
allowing us to
Markus Wanner mar...@bluegap.ch writes:
On 08/26/2010 02:44 PM, Robert Haas wrote:
On the more general topic of imessages, I had one other thought that
might be worth considering. Instead of using shared memory, what
about using a file that is shared between the sender and receiver?
What
On 08/26/2010 09:22 PM, Tom Lane wrote:
Not having to have a hard limit on the space for unconsumed messages?
Ah, I see. However, spilling to disk is unwanted for the current use
cases of imessages. Instead the sender needs to be able to deal with
out-of-(that-specific-part-of-shared)-memory
On 26/08/10 22:16, Tom Lane wrote:
Heikki Linnakangasheikki.linnakan...@enterprisedb.com writes:
* instead of the byte-at-a-time loop in CopyReadLineText(), use memchr()
to find the next NL/CR character. This is where the speedup comes from.
That seems like the speedup, if any, would be
Hi,
When I check the types of fields in a data structure, I found most
fields are defined as general types, as List, Node. Then, To know the
content inside the List, I need to track the usage of the fields.
For example, the fromClause in SelectStmt is defined as List. And, the
content in the
Heikki Linnakangas heikki.linnakan...@enterprisedb.com writes:
On 26/08/10 22:16, Tom Lane wrote:
I think this is likely to break apps that have worked for years. I
can't get excited about doing that in return for an 0-10% speedup
that might only materialize on some platforms. If the numbers
Pei He hepeim...@gmail.com writes:
When I check the types of fields in a data structure, I found most
fields are defined as general types, as List, Node. Then, To know the
content inside the List, I need to track the usage of the fields.
For example, the fromClause in SelectStmt is defined as
I still believe this exit code 128 is related to pgAdmin opened during the
clossing session on Remote Desktop. I have a Windows user login wich is not
administrator just no privileged user, it cannot start/stop services, just
monitoring. With pgAdmin window opened inside my disconected session, as
On Thu, Aug 26, 2010 at 3:03 PM, Markus Wanner mar...@bluegap.ch wrote:
On the more general topic of imessages, I had one other thought that
might be worth considering. Instead of using shared memory, what
about using a file that is shared between the sender and receiver?
What would that buy
On Thu, Aug 26, 2010 at 3:40 PM, Markus Wanner mar...@bluegap.ch wrote:
On 08/26/2010 09:22 PM, Tom Lane wrote:
Not having to have a hard limit on the space for unconsumed messages?
Ah, I see. However, spilling to disk is unwanted for the current use cases
of imessages. Instead the sender
Robert Haas robertmh...@gmail.com writes:
On Thu, Aug 19, 2010 at 3:34 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
Any other kibitzing before I commit this?
Sure ...
[kibitzing]
v4.
For my money, you could just have said Applied with suggested
46 matches
Mail list logo
