On Jul 9, 2009, at 5:53 PM, Dave Page wrote:
On Thu, Jul 9, 2009 at 11:31 PM, Robert Haas
wrote:
On Jul 9, 2009, at 5:07 PM, Peter Eisentraut wrote:
On Thursday 09 July 2009 19:06:35 Brendan Jurd wrote:
Your login details for the app == your community login == your wiki
login.
One thin
Hi,
On Thu, Jul 9, 2009 at 11:13 PM, Kevin
Grittner wrote:
> Fujii Masao wrote:
>> Kevin Grittner wrote:
>
>>> I think the interesting bit is when you're at this point and the
>>> connection between the master and slave goes down for a couple
>>> days. How do you handle that?
>>
>> In the curren
Em Thu, 09 Jul 2009 19:58:01 -0300, Josh Berkus
escreveu:
The real question is slow-to-upgrade OSes like HP-UX, AIX, OpenBSD and
Solaris. What version of Bison are they shipping with?
In AIX 5.3: bison (GNU Bison) 1.875
[]s
Dickson S. Guedes
http://pgcon.postgresql.org.br
http://www.postg
On Friday 10 July 2009 00:58:01 Josh Berkus wrote:
> Tom,
>
> > As best I can tell, they ended up not changing the API, and there is no
> > reason we shouldn't depend on the feature and continue to claim that we
> > work with bison>= 1.875. Does anyone feel uncomfortable with that?
> > (It may be
Josh Berkus wrote:
> The real question is slow-to-upgrade OSes like HP-UX, AIX, OpenBSD
> and Solaris. What version of Bison are they shipping with?
I don't know about them, but just so you know:
kgri...@inhouseapps:~> cat /etc/SuSE-release
SUSE LINUX Enterprise Server 9 (i586)
VERSION = 9
Tom,
As best I can tell, they ended up not changing the API, and there is no
reason we shouldn't depend on the feature and continue to claim that we
work with bison>= 1.875. Does anyone feel uncomfortable with that?
(It may be of mostly academic interest anyway, since I bet few people
are still
On Thu, Jul 9, 2009 at 11:31 PM, Robert Haas wrote:
> On Jul 9, 2009, at 5:07 PM, Peter Eisentraut wrote:
>
>> On Thursday 09 July 2009 19:06:35 Brendan Jurd wrote:
>>>
>>> Your login details for the app == your community login == your wiki
>>> login.
>>
>> One thing I forgot to mention: Please se
I've been poking at the project of using a reentrant flex scanner for
PG. In order to make this work in a non-klugy way, it turns out that
we have to also upgrade our Bison parser to be a "pure parser" ---
otherwise Bison doesn't want to pass the additional scanner pointer to
yylex(). I haven't f
On Jul 9, 2009, at 5:07 PM, Peter Eisentraut wrote:
On Thursday 09 July 2009 19:06:35 Brendan Jurd wrote:
Your login details for the app == your community login == your wiki
login.
One thing I forgot to mention: Please set up an SSL server
certificate around
the login page.
Who will pr
On Thursday 09 July 2009 19:06:35 Brendan Jurd wrote:
> Your login details for the app == your community login == your wiki login.
One thing I forgot to mention: Please set up an SSL server certificate around
the login page.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
--On Donnerstag, Mai 07, 2009 12:57:56 +0200 Andres Freund
wrote:
Ok, fixed that place (stupid me, I had seen that it is used there and
forgot about it) and found no other places.
Thanks,
Andres
Here is a slightly updated version of the patch. I did some (very minor)
editing on the wordin
Brendan Jurd writes:
> Bear in mind that CF activity over the past week has been in the realm
> of 0-4 changes per 24 hours, so it's not like we are talking about
> huge amounts of throughput here.
Well, it'll be more once commitfest actually starts, but in any case
it's not going to be enough to
2009/7/10 Josh Berkus :
>
>> We don't AFAIK collect data about these events. However, we could
>> have certain actions trigger the creation of an automated comment
>> (e.g., "Status changed to Committed by petere") and let the
>> aforementioned comment view suffice for a "history".
>
> Can you put
Josh Berkus writes:
>> We don't AFAIK collect data about these events. However, we could
>> have certain actions trigger the creation of an automated comment
>> (e.g., "Status changed to Committed by petere") and let the
>> aforementioned comment view suffice for a "history".
> Can you put in a
We don't AFAIK collect data about these events. However, we could
have certain actions trigger the creation of an automated comment
(e.g., "Status changed to Committed by petere") and let the
aforementioned comment view suffice for a "history".
Can you put in a simple event-recording trigger
On Jul 9, 2009, at 12:16 PM, Tom Lane wrote:
Brendan Jurd writes:
We're now about a week away from the start of the July 2009
commitfest, and we need to make a decision about whether to start
using http://commitfest.postgresql.org to manage it, or punt to the
next commitfest and continue to u
On Thu, Jul 09, 2009 at 02:35:04PM -0300, Dickson S. Guedes wrote:
> This could help, maybe with a RSS in that (like in git).
+1 for the RSS feed, if only because I think it sounds neat :)
--
Joshua Tolley / eggyknap
End Point Corporation
http://www.endpoint.com
signature.asc
Description: Digit
2009/7/10 Tom Lane :
> While reorganizing my bookmarks for this I realized that there is a
> fairly significant bit of functionality that's entirely missing from
> the new app. With the wiki page, you could conveniently see what had
> been done lately by examining the page history. I don't see an
Em Thu, 09 Jul 2009 14:16:41 -0300, Tom Lane escreveu:
I'm not particularly wedded to the wiki page
history in terms of what it looks like or how it functions, but I do
feel a need to know what other people have done recently.
May be the new app could have a page with a filterable table log wi
On Wed, Jul 08, 2009 at 10:28:02AM -0500, Robert Haas wrote:
> On Jul 8, 2009, at 8:43 AM, Noah Misch wrote:
>> The expontential factor seems smaller for real queries. I have a query of
>> sixteen joins that takes 71s to plan deterministically; it looks like this:
>>
>> SELECT 1 FROM fact JOIN di
Brendan Jurd writes:
> We're now about a week away from the start of the July 2009
> commitfest, and we need to make a decision about whether to start
> using http://commitfest.postgresql.org to manage it, or punt to the
> next commitfest and continue to use the wiki for July.
While reorganizing
2009/7/7 Brendan Jurd :
> We're now about a week away from the start of the July 2009
> commitfest, and we need to make a decision about whether to start
> using http://commitfest.postgresql.org to manage it, or punt to the
> next commitfest and continue to use the wiki for July.
Thank you to ever
On Thursday 09 July 2009 17:37:41 Kevin Grittner wrote:
> Resending to list due to failure:
> 451 4.3.5 Server configuration problem
>
> Joshua Tolley wrote:
> > Entire stored plans, or predetermined seeds for GEQO's random number
> > generator all boil down to saying, "I want you to use this plan
Resending to list due to failure:
451 4.3.5 Server configuration problem
Joshua Tolley wrote:
> Entire stored plans, or predetermined seeds for GEQO's random number
> generator all boil down to saying, "I want you to use this plan
> henceforth and forever."
A predetermined seed for geqo's ra
Hello, Bernd.
You wrote:
BH> --On Dienstag, Juli 07, 2009 18:07:08 -0400 Tom Lane
BH> wrote:
>> Enum. If we do this then it seems entirely fair that someone might
>> want other settings someday. Also, it seems silly to pick a format
>> partly on the grounds that it's expansible, and then not
Fujii Masao wrote:
> Kevin Grittner wrote:
>> I think the interesting bit is when you're at this point and the
>> connection between the master and slave goes down for a couple
>> days. How do you handle that?
>
> In the current design of synch rep, you have only to restart the
> standby afte
Robert Haas wrote:
> If, as you suggest, it isn't actually useful, then why keep it at
> all?
I was imagining that someone who has a query which is taking a long
time to run, and asserts that it would run faster if only the
optimizer would arrange the joins a certain way, could test that
theor
On Wed, Jul 08, 2009 at 05:23:16PM -0400, Tom Lane wrote:
> Noah Misch writes:
> > The expontential factor seems smaller for real queries. I have a query of
> > sixteen joins that takes 71s to plan deterministically; it looks like this:
>
> > SELECT 1 FROM fact JOIN dim0 ... JOIN dim6
> > JOIN t
On Wed, Jul 8, 2009 at 8:26 PM, Tom Lane wrote:
> Robert Haas writes:
>> That was my first reaction too, but now I'm wondering whether we
>> shouldn't just do #1. #2 is a planner hint, too, just not a very good
>> one. If, as you suggest, it isn't actually useful, then why keep it
>> at all? (O
Here is an updated version of multi-threaded pgbench patch.
Andrew Dunstan wrote:
> > Hmm, but how will you communicate stats back from the sub-processes?
> My first reaction is to say "use a pipe."
I added partial implementation of pthread using fork and pipe for platform
without ENABLE_THREAD
On Wed, Jul 8, 2009 at 11:11 PM, Kasia Tuszynska wrote:
> Hello Postgres Hackers,
>
>
>
> We have begun testing Postgres 8.4 on windows, beginning with the installer.
> We have noticed that several additional modules which are usually installed
> through the Application Stack Wizard are missing fro
Hi,
Robert Haas writes:
> On Jul 8, 2009, at 8:26 PM, Tom Lane wrote:
>> Now, your answer will probably be that we should provide some better
>> mechanism for re-using a previously identified plan structure. No
>> doubt that would be ideal, but the amount of effort required to get
>> there is n
Hi,
On Tue, Jul 7, 2009 at 8:51 PM, Fujii Masao wrote:
> http://archives.postgresql.org/message-id/4951108a.5040...@enterprisedb.com
>> I don't think we need or should
>> allow running regular queries before entering "replication mode". the
>> backend should become a walsender process directly aft
33 matches
Mail list logo
