Robert Haas writes:
> On Thu, Aug 19, 2010 at 3:34 PM, Tom Lane wrote:
>> Robert Haas writes:
>>> Any other kibitzing before I commit this?
>>
>> Sure ...
>>
>> [kibitzing]
> v4.
For my money, you could just have said "Applied with suggested changes".
They were pretty darn trivial.
On Thu, Aug 26, 2010 at 3:40 PM, Markus Wanner 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 needs to be
On Thu, Aug 26, 2010 at 3:03 PM, Markus Wanner 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 us? (At t
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, a
Pei He 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 List. And, the
>
Heikki Linnakangas 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 were
>> better, it'd be wo
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 ListCe
On 26/08/10 22:16, Tom Lane wrote:
Heikki Linnakangas 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 extremely
platform-dependent. What have
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
Markus Wanner 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 would that b
Heikki Linnakangas 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 search for the '\n' byte without worr
Excerpts from Tom Lane's message of jue ago 26 14:59:43 -0400 2010:
> Alvaro Herrera writes:
> > Code is here:
> > else if (deptype == SHARED_DEPENDENCY_ACL)
> > appendStringInfo(descs, _("access to %s"), objdesc);
> > in StoreObjectDescription().
>
> > Happy to change
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 imess
Alvaro Herrera 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 appropriate. "privileges for
Robert Haas writes:
> On Tue, Aug 24, 2010 at 9:58 AM, Tom Lane 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 on Windows. If for some
>> reason
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
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 pe
> 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 alrea
Bruce Momjian 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
> the e
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:
>
> http://archives.postgr
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
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'
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:
http://archives.postgresql.org/pgsql-hackers/2002-11/msg0066
Tom Lane wrote:
> Bruce Momjian 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 , and then about
> half a dozen
On Thu, Aug 26, 2010 at 15:53, Tom Lane wrote:
> Magnus Hagander writes:
>> On Thu, Aug 26, 2010 at 00:49, Tom Lane 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
> w
Magnus Hagander writes:
> On Thu, Aug 26, 2010 at 00:49, Tom Lane 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 entries to be changed.
On Thu, 26 Aug 2010, Bruce Momjian wrote:
Magnus Hagander wrote:
On Thu, Aug 26, 2010 at 00:49, 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:
?162
Bruce Momjian 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 , and then about
half a dozen committed by "julian" without
Magnus Hagander wrote:
> On Thu, Aug 26, 2010 at 00:49, 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:
> >
> > ?162 bryanh
> > ?20 byro
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: L
On Thu, Aug 26, 2010 at 6:07 AM, Markus Wanner 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 dunno. It was
On Thu, Aug 26, 2010 at 05:45, Tom Lane wrote:
> "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 Assa
On Thu, Aug 26, 2010 at 00:49, 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:
>
> 162 bryanh
> 20 byronn
> 6 julian
> 1 mcguirk
>
> (the nu
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.
Howev
On Thu, Aug 26, 2010 at 7:42 PM, Markus Wanner 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 just use an or
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 cov
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 24/08/10 02:44, Tom Lane wrote:
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
response to actual signals.
You can can set the latch in the signal handle
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 in
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 wrote:
> >
> > The concurrency issues are not involved. I don't know much about
> > this part. I think we need more discussion
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, or
Tom Lane 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 been "inlined" by
Hitoshi Harada 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 hopeless to have such
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
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 *
45 matches
Mail list logo
