On Dec 19, 2006, at 9:50 PM, Jonah H. Harris wrote:
On 12/19/06, Tom Lane <[EMAIL PROTECTED]> wrote:
I think we should just accept the strings case-insensitively, too.
While acknowledging Peter's pedantically-correct points, I say +1 for
ease of use.
+1. I spend some time walking people th
I'm teaching a class this week and a student asked me about OIDs. He
related the story of how in Sybase, if you moved a database from one
server from another, permissions got all screwed up because user IDs
no longer matched. I explained that exposing something like an
integer ID in a user
On 12/19/06, Tom Lane <[EMAIL PROTECTED]> wrote:
I think we should just accept the strings case-insensitively, too.
While acknowledging Peter's pedantically-correct points, I say +1 for
ease of use.
--
Jonah H. Harris, Software Architect | phone: 732.331.1324
EnterpriseDB Corporation
On Wed, December 20, 2006 11:08, Tom Lane wrote:
> "Jeroen T. Vermeulen" <[EMAIL PROTECTED]> writes:
>> Probably a silly question, but better safe than sorry:
>> AFAICS there's no way for PQencryptPassword() to see what encoding
>> applies. Are we quite sure that that is not a problem?
>
> Right o
On 12/19/06, Bruce Momjian <[EMAIL PROTECTED]> wrote:
The article assumes healthy open source communities, not open source
communities that are offshoots or parasites of commercial companies.
Assumptions are many times incorrect. Similarly, I wouldn't disregard
an open source community just be
On 12/19/06, Joshua D. Drake <[EMAIL PROTECTED]> wrote:
Ingres is opensource again yes. http://www.ingres.com/ .
Yep.
> I'm not aware of too many more. Like I said, if you want to establish
> this as the typical case, name ten examples.
We could also mention all the Ingres-based offshoots
Peter Eisentraut wrote:
Tom Lane wrote:
Nor do I believe that we'd ever accept a future patch that made
the distinction between "kb" and "kB" significant --- if you think
people are confused now, just imagine what would happen then.
As I said elsewhere, I'd imagine future functionality like a
Stephen Frost <[EMAIL PROTECTED]> writes:
> Force references to go through macros which implement the lookup for the
> appropriate type? ie: LOGICAL_COL(table_oid,2) vs.
> PHYSICAL_COL(table_oid,1) Perhaps that's too simplistic.
It doesn't really address the question of how you know which one to
On Tue, 2006-12-19 at 23:17 -0500, Tom Lane wrote:
> "Joshua D. Drake" <[EMAIL PROTECTED]> writes:
> > On Tue, 2006-12-19 at 22:54 -0500, Tom Lane wrote:
> >> So, I suppose you can give us ten examples of thriving companies based
> >> on private forks of dead open-source projects?
>
> > MySQL? (so
"Joshua D. Drake" <[EMAIL PROTECTED]> writes:
> On Tue, 2006-12-19 at 22:54 -0500, Tom Lane wrote:
>> So, I suppose you can give us ten examples of thriving companies based
>> on private forks of dead open-source projects?
> MySQL? (sorry couldn't resist).
Uh, no, because that was never a genuine
Joshua D. Drake wrote:
> On Tue, 2006-12-19 at 22:04 -0500, Tom Lane wrote:
> > "Joshua D. Drake" <[EMAIL PROTECTED]> writes:
> > >> I remember the president of Great Bridge
> > >> saying that the company needs the community, but not visa-vera --- if
> > >> the company dies, the community keeps goi
* Tom Lane ([EMAIL PROTECTED]) wrote:
> If you can show me a reasonably bulletproof or machine-checkable way to
> keep the two kinds of column numbers distinct, I'd be all for it. But
> without that, the answer will remain no.
Force references to go through macros which implement the lookup for t
"Jeroen T. Vermeulen" <[EMAIL PROTECTED]> writes:
> Probably a silly question, but better safe than sorry:
> AFAICS there's no way for PQencryptPassword() to see what encoding
> applies. Are we quite sure that that is not a problem?
Right offhand it seems that the worst possible consequence is
au
On Tue, 2006-12-19 at 22:54 -0500, Tom Lane wrote:
> "Jonah H. Harris" <[EMAIL PROTECTED]> writes:
> > On 12/19/06, Bruce Momjian <[EMAIL PROTECTED]> wrote:
> >> if the company dies, the community keeps going (as it did after Great
> >> Bridge, without a hickup), but if the community dies, the comp
Hello, Itagaki-san
> I posted a patch to PATCHES. Please try out it.
Really!? I've just joined pgsql-patches. When did you post it,
yesterday? I couldn't find the patch in the following page which
lists the mails to pgsql-patches of this month:
http://archives.postgresql.org/pgsql-patches/200
Probably a silly question, but better safe than sorry:
AFAICS there's no way for PQencryptPassword() to see what encoding
applies. Are we quite sure that that is not a problem? Or are passwords
ASCII-only?
Jeroen
---(end of broadcast)---
TIP 5
"Jonah H. Harris" <[EMAIL PROTECTED]> writes:
> On 12/19/06, Bruce Momjian <[EMAIL PROTECTED]> wrote:
>> if the company dies, the community keeps going (as it did after Great
>> Bridge, without a hickup), but if the community dies, the company dies
>> too.
> However, in regard to a dying community
Jonah H. Harris wrote:
> The title of the document, "How Companies Can Effectively Contribute
> To Open Source Communities" doesn't seem to fit the content. I would
> consider something more along the lines of, "Enterprise Open Source:
> Effectively Contributing Commercial Support to Open Source
Robert Treat <[EMAIL PROTECTED]> writes:
> On Tuesday 19 December 2006 11:25, Martijn van Oosterhout wrote:
>> A patch to allow seperate physical and logical orderings was submitted
>> and rejected. Unless something has changed on that front, any
>> discussion in this direction isn't really useful.
The article assumes healthy open source communities, not open source
communities that are offshoots or parasites of commercial companies.
The article title, "How Companies Can Effectively Contribute To Open
Source Communities" itself assumes that because the company is
contributing to the communi
> > >
> > > I do think I need to add a more generous outreach to companies in the
> > > article, explaining how valuable they are to the community, so let me
> > > work on that and I will post when I have an update.
> >
> > Cool, that is what I was really looking for.
>
> Yes, the original was
On Tuesday 19 December 2006 11:25, Martijn van Oosterhout wrote:
> On Tue, Dec 19, 2006 at 10:48:41AM -0500, Andrew Dunstan wrote:
> > Sure, but the only sane way I can think of to do that would be have
> > separate logical and physical orderings, with a map between the two. I
> > guess we'd need t
Jonah H. Harris wrote:
As this document is supposed to be factual, I'd really like not to get
into a war over lines-of-code development rates vs. bugs, quality (or
lack thereof), etc. The *fact* is, some commercial software companies
could easily churn out more, better quality code, if they ch
Joshua D. Drake wrote:
>
> In one fails swoop:
>
ITYM "fell swoop". see http://www.worldwidewords.org/qa/qa-fel1.htm
cheers
a
---(end of broadcast)---
TIP 3: Have you checked our extensive FAQ?
http://www.postgresql.org/docs/faq
> In one fails swoop:
Sorry a beer and email just doesn't mix. The above should be one fell
swoop.
>
> Devrim, Alvaro, Darcy, Heikki, Bruce, Simon, Greg, Dave, Marc and I are
> all suddenly looking for employment...
>
> You don't think there would be an issue that could cause some grief to
> t
Joshua D. Drake wrote:
> > I remember the president of Great Bridge
> > saying that the company needs the community, but not visa-vera --- if
> > the company dies, the community keeps going (as it did after Great
> > Bridge, without a hickup), but if the community dies, the company dies
> > too.
Bruce Momjian <[EMAIL PROTECTED]> wrote:
> OK, if I understand correctly, instead of doing a buffer scan, write(),
> and fsync(), and recyle the WAL files at checkpoint time, you delay the
> scan/write part with the some delay.
Exactly. Actual behavior of checkpoint is not changed by the patch. C
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> Nor do I believe that we'd ever accept a future patch that made
>> the distinction between "kb" and "kB" significant --- if you think
>> people are confused now, just imagine what would happen then.
> As I said elsewhere, I'd imagin
On Tue, 2006-12-19 at 22:04 -0500, Tom Lane wrote:
> "Joshua D. Drake" <[EMAIL PROTECTED]> writes:
> >> I remember the president of Great Bridge
> >> saying that the company needs the community, but not visa-vera --- if
> >> the company dies, the community keeps going (as it did after Great
> >> Br
"Joshua D. Drake" <[EMAIL PROTECTED]> writes:
>> I remember the president of Great Bridge
>> saying that the company needs the community, but not visa-vera --- if
>> the company dies, the community keeps going (as it did after Great
>> Bridge, without a hickup), but if the community dies, the compa
> Hello,
>
> Attached is a simple patch that replaces strcmp() with pg_strcasecmp().
> Thanks to AndrewS for pointing out that I shouldn't use strcasecp().
>
That should be AndrewD :)
J
> I compiled and installed, ran an initdb with 32mb (versus 32MB) and it
> seems to work correctly with a
On 12/19/06, Bruce Momjian <[EMAIL PROTECTED]> wrote:
This actually brings up an important distinction. Joshua is saying that
the community is painted as "god" in the article, and I agree there is a
basis for that, but I don't think you can consider the community and
company as equals either.
Peter Eisentraut wrote:
An objection to enums on the ground that foreign keys can accomplish the
same thing could be extended to object to any data type with a finite
domain.
Exactly. The extreme case is the boolean type, which could easily be
represented by a two-value enum. Or, if you were
On Wed, 2006-12-20 at 02:19 +0100, Peter Eisentraut wrote:
> Joshua D. Drake wrote:
> > I compiled and installed, ran an initdb with 32mb (versus 32MB) and
> > it seems to work correctly with a show shared_buffers;
>
> Did it actually allocate 32 millibits of shared buffers?
Funny :)
Joshua D. D
Alvaro Herrera wrote:
I don't, because there are always those that are knowledgeable enough to
know how to reduce space lost to padding. So it would be nice to have
2-byte enums on-disk, and resolve them based on the column's typid. But
then, I'm not familiar with the patch at all so I'm not su
Tom Lane wrote:
> +1 on that, but I think we should just accept the strings
> case-insensitively, too.
I think if we'd allow this to spread, documentation, example files and
other material would use it inconsistently, and even more people would
be confused and it would make us look silly.
It's
Hi Asaba-san.
From: "Yoshiyuki Asaba"
Is it able to use fsetpos()/fgetpos() instead of ftell()/fseek()?
fpos_t is a 8byte type. I tested pg_dump/pg_restore with the attached
patch.
I'm sorry the response ..slowly...my machine reacts for the reasons of
poverty late. Last night.. I was actuall
Joshua D. Drake wrote:
> I compiled and installed, ran an initdb with 32mb (versus 32MB) and
> it seems to work correctly with a show shared_buffers;
Did it actually allocate 32 millibits of shared buffers?
--
Peter Eisentraut
http://developer.postgresql.org/~petere/
---
Tom Lane wrote:
> Nor do I believe that we'd ever accept a future patch that made
> the distinction between "kb" and "kB" significant --- if you think
> people are confused now, just imagine what would happen then.
As I said elsewhere, I'd imagine future functionality like a units-aware
data type
Jeremy Drake wrote:
> On Wed, 20 Dec 2006, Philip Yarra wrote:
>
> > Mario wrote:
> > > Even if you get a core dumped every time you press CTRL+\ ? why?
> >
> > Try ulimit -c 0, then run it (you should get no core dump)
> > Then ulimit -c 50, then run it (you should get a core dump)
> >
>
On Tue, 2006-12-19 at 19:16 -0500, Tom Lane wrote:
> Peter Eisentraut <[EMAIL PROTECTED]> writes:
> > Perhaps it would be more effective to clarify the error message? Right
> > now it just says something to the effect of "invalid integer". I'd
> > imagine "invalid memory unit: TB" would be less
> > > > The community could learn a great deal from adopting some of the more
> > > > common business practices when it comes to development as well.
> > > >
> > > > In short, I guess I think it is important to recognize that both are
> > > > partners in the open source world and that to ignore on
On Wed, 20 Dec 2006, Philip Yarra wrote:
> Mario wrote:
> > Even if you get a core dumped every time you press CTRL+\ ? why?
>
> Try ulimit -c 0, then run it (you should get no core dump)
> Then ulimit -c 50, then run it (you should get a core dump)
>
> SIGQUIT is supposed to dump core. Ul
The 8.2.0 release went well. We spent a month more in beta than we
planned, but that time helped to eliminate many bugs, and many that had
existed in previous PostgreSQL major releases as well. We have had very
few bug reports for 8.2.0, and will be doing a minor release in 1-2
weeks to get thos
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> Perhaps it would be more effective to clarify the error message? Right
> now it just says something to the effect of "invalid integer". I'd
> imagine "invalid memory unit: TB" would be less confusing.
+1 on that, but I think we should just accept
Joshua D. Drake wrote:
> On Wed, 2006-12-20 at 09:51 +1300, Andrej Ricnik-Bay wrote:
> > On 12/20/06, Joshua D. Drake <[EMAIL PROTECTED]> wrote:
> >
> > > O.k. in all Bruce I like your article but I must admit it seems to take
> > > a "The community is god" perspective and that we must all bend to
"Mario" <[EMAIL PROTECTED]> writes:
> On 20/12/06, Peter Eisentraut <[EMAIL PROTECTED]> wrote:
> >
> > This isn't a bug. It's working as designed.
>
> Even if you get a core dumped every time you press CTRL+\ ? why?
That's what C-\ does. Try it with any other program:
$ sleep 1
Quit (core d
Mario wrote:
Even if you get a core dumped every time you press CTRL+\ ? why?
Try ulimit -c 0, then run it (you should get no core dump)
Then ulimit -c 50, then run it (you should get a core dump)
SIGQUIT is supposed to dump core. Ulimit settings can suppress
generation of core files.
Gregory Stark wrote:
>
> "Kenneth Marshall" <[EMAIL PROTECTED]> writes:
>
> > My one comment is that a little 'b' is used to indicate bits normally
> > and a capital 'B' is used to indicate bytes. So
> >kb = '1024 bits'
> >kB = '1024 bytes'
> > I do think that whether or not the k
Mario wrote:
> On 20/12/06, Peter Eisentraut <[EMAIL PROTECTED]> wrote:
>> Mario wrote:
>> > When psql is running and CRTL + \ is pressed, a core dumped show up.
>> > In first place I ran psql into gdb, saw the backtrace and I believed
>> > it was a libc6 bug and I reported to my distro security t
On 20/12/06, Peter Eisentraut <[EMAIL PROTECTED]> wrote:
Mario wrote:
> When psql is running and CRTL + \ is pressed, a core dumped show up.
> In first place I ran psql into gdb, saw the backtrace and I believed
> it was a libc6 bug and I reported to my distro security team
> https://launchpad.n
Mario wrote:
> When psql is running and CRTL + \ is pressed, a core dumped show up.
> In first place I ran psql into gdb, saw the backtrace and I believed
> it was a libc6 bug and I reported to my distro security team
> https://launchpad.net/distros/ubuntu/+source/glibc/+bug/76437
This isn't a bu
"Kenneth Marshall" <[EMAIL PROTECTED]> writes:
> My one comment is that a little 'b' is used to indicate bits normally
> and a capital 'B' is used to indicate bytes. So
>kb = '1024 bits'
>kB = '1024 bytes'
> I do think that whether or not the k/m/g is upper case or lower case
> is
When psql is running and CRTL + \ is pressed, a core dumped show up.
In first place I ran psql into gdb, saw the backtrace and I believed
it was a libc6 bug and I reported to my distro security team
https://launchpad.net/distros/ubuntu/+source/glibc/+bug/76437
Ubuntu edgy has got libc-2.4, a fri
Joshua D. Drake wrote:
> I am not suggestion variant capitalization. I am suggestion a simple
> document patch to help eliminate what may not be obvious.
Perhaps it would be more effective to clarify the error message? Right
now it just says something to the effect of "invalid integer". I'd
im
On Tue, 2006-12-19 at 23:39 +0100, Magnus Hagander wrote:
> Peter Eisentraut wrote:
> > Magnus Hagander wrote:
> >> In most cases, I just assume they would just assume
> >> they can't use units on it because the default value in the file
> >> doesn't have units.
> >
> > But the default value *does
Lukas Kahwe Smith wrote:
> Hi,
>
> I think another point you need to bring out more clearily is that the
> community is also often "miffed" if they feel they have been left out of
> the design and testing phases. This is sometimes just a reflex that is
> not always based on technical reasoning.
Peter Eisentraut wrote:
> Magnus Hagander wrote:
>> In most cases, I just assume they would just assume
>> they can't use units on it because the default value in the file
>> doesn't have units.
>
> But the default value *does* have units.
>
It does? Didn't in my file. I must've overwritten it wi
Magnus Hagander wrote:
> In most cases, I just assume they would just assume
> they can't use units on it because the default value in the file
> doesn't have units.
But the default value *does* have units.
--
Peter Eisentraut
http://developer.postgresql.org/~petere/
---
"Tom Lane" <[EMAIL PROTECTED]> writes:
> Magnus Hagander <[EMAIL PROTECTED]> writes:
>> Oh, you mean MB vs Mb. Man, it had to be that simple :)
>
> ISTM we had discussed whether guc.c should accept units strings in
> a case-insensitive manner, and the forces of pedantry won the first
> round. Sh
> > In my mind, this is pretty silly. There is no reputable precedent
> > anywhere for variant capitalization in unit names.
>
> I am not suggestion variant capitalization. I am suggestion a simple
> document patch to help eliminate what may not be obvious.
Good lord... *suggesting*
Joshua D.
Bruce Momjian wrote:
> The only value to being case-sensitive in this area is to allow
> upper/lower case with different meanings, but I don't see us using
> that, so why do we bother caring about the case?
Because the units are what they are.
In broader terms, we may one day want to have other u
Peter Eisentraut wrote:
> Joshua D. Drake wrote:
>> + #
>> + # Any memory setting may use a shortened notation such as 1024MB or
>> 1GB.
>> + # Please take note of the case next to the unit size.
>> + #
>
> Well, if you add that, you should also list all the other valid units.
> But it's quite r
On Tue, 2006-12-19 at 22:59 +0100, Peter Eisentraut wrote:
> Joshua D. Drake wrote:
> > + #
> > + # Any memory setting may use a shortened notation such as 1024MB or
> > 1GB.
> > + # Please take note of the case next to the unit size.
> > + #
>
> Well, if you add that, you should also list all the
Joshua D. Drake wrote:
> + #
> + # Any memory setting may use a shortened notation such as 1024MB or
> 1GB.
> + # Please take note of the case next to the unit size.
> + #
Well, if you add that, you should also list all the other valid units.
But it's quite redundant, because nearly all the para
On Tue, 2006-12-19 at 16:47 -0500, Bruce Momjian wrote:
> Joshua D. Drake wrote:
> > On Tue, 2006-12-19 at 10:01 +0100, Peter Eisentraut wrote:
> > > Magnus Hagander wrote:
> > > > Is it possible to add an error hint to the message? Along the line of
> > > > "HINT: Did you perhaps get your casing w
Joshua D. Drake wrote:
> On Tue, 2006-12-19 at 10:01 +0100, Peter Eisentraut wrote:
> > Magnus Hagander wrote:
> > > Is it possible to add an error hint to the message? Along the line of
> > > "HINT: Did you perhaps get your casing wrong" (with better wording,
> > > of course).
> >
> > Or how abou
On Tue, 2006-12-19 at 13:32 -0800, Joshua D. Drake wrote:
> On Tue, 2006-12-19 at 10:01 +0100, Peter Eisentraut wrote:
> > Magnus Hagander wrote:
> > > Is it possible to add an error hint to the message? Along the line of
> > > "HINT: Did you perhaps get your casing wrong" (with better wording,
> >
On Tue, 2006-12-19 at 16:30 -0500, Andrew Dunstan wrote:
> Joshua D. Drake wrote:
> >
> > I think my overall thought is the tone seems a bit non-gracious to
> > companies, when IMO the community should be actively courting companies
> > to give resources. If companies feel unwelcome, they won't giv
On Wed, 2006-12-20 at 10:27 +1300, Andrej Ricnik-Bay wrote:
> On 12/20/06, Joshua D. Drake <[EMAIL PROTECTED]> wrote:
>
> > I think my overall thought is the tone seems a bit non-gracious to
> > companies, when IMO the community should be actively courting companies
> > to give resources. If compa
On Tue, 2006-12-19 at 10:01 +0100, Peter Eisentraut wrote:
> Magnus Hagander wrote:
> > Is it possible to add an error hint to the message? Along the line of
> > "HINT: Did you perhaps get your casing wrong" (with better wording,
> > of course).
>
> Or how about we just make everything case-insens
Joshua D. Drake wrote:
I think my overall thought is the tone seems a bit non-gracious to
companies, when IMO the community should be actively courting companies
to give resources. If companies feel unwelcome, they won't give.
I have not been following closely. But IMNSHO we should be stre
On 12/20/06, Joshua D. Drake <[EMAIL PROTECTED]> wrote:
I think my overall thought is the tone seems a bit non-gracious to
companies, when IMO the community should be actively courting companies
to give resources. If companies feel unwelcome, they won't give.
I appreciate that, but then Bruce'
On Wed, 2006-12-20 at 09:51 +1300, Andrej Ricnik-Bay wrote:
> On 12/20/06, Joshua D. Drake <[EMAIL PROTECTED]> wrote:
>
> > O.k. in all Bruce I like your article but I must admit it seems to take
> > a "The community is god" perspective and that we must all bend to the
> > will of said community.
Andrew Dunstan wrote:
> Magnus Hagander wrote:
>> We need different macrosand possibly functions, yes.
>> I think I got enough patched at home last night to get it working with
>> this, I was just too focused on one set of macros at the time. It's not
>> enough to include them very late - because o
Magnus Hagander wrote:
We need different macrosand possibly functions, yes.
I think I got enough patched at home last night to get it working with
this, I was just too focused on one set of macros at the time. It's not
enough to include them very late - because off_t is used in the shared
datastr
On 12/20/06, Joshua D. Drake <[EMAIL PROTECTED]> wrote:
O.k. in all Bruce I like your article but I must admit it seems to take
a "The community is god" perspective and that we must all bend to the
will of said community.
I'm not really in a position to judge how a company thinks about
"donatin
Joshua D. Drake wrote:
O.k. in all Bruce I like your article but I must admit it seems to take
a "The community is god" perspective and that we must all bend to the
will of said community.
The community could learn a great deal from adopting some of the more
common business practices when it co
Hello,
O.k. below are some comments. Your article although well written has a
distinct, from the community perspective ;) and I think there are some
points from the business side that are missed.
---
Employees working in open source communities have two bosses -- the
companies that employ them, a
Hi,
I think another point you need to bring out more clearily is that the
community is also often "miffed" if they feel they have been left out of
the design and testing phases. This is sometimes just a reflex that is
not always based on technical reasoning. Its just that as you correctly
poi
Gurjeet Singh wrote:
> On 12/20/06, Bruce Momjian <[EMAIL PROTECTED]> wrote:
>
> > Fixed, thanks.
> >
>
> Follwing statement seems to be a bit mangled:
>
> then when company('s?) needs diverge, going *it*(?) alone, then returning to
> the community process at some later time.
Thanks, clarified.
On 12/20/06, Bruce Momjian <[EMAIL PROTECTED]> wrote:
Fixed, thanks.
Follwing statement seems to be a bit mangled:
then when company('s?) needs diverge, going *it*(?) alone, then returning to
the community process at some later time.
--
[EMAIL PROTECTED]
[EMAIL PROTECTED] gmail | hotmail |
Fixed, thanks.
---
Gurjeet Singh wrote:
> On 12/20/06, Bruce Momjian <[EMAIL PROTECTED]> wrote:
> >
> > Thanks for the feedback, sectioning fixed.
> >
>
> Spelling mistake:
>
> because they have gone though a company proce
On 12/20/06, Bruce Momjian <[EMAIL PROTECTED]> wrote:
Thanks for the feedback, sectioning fixed.
Spelling mistake:
because they have gone though a company process
to
because they have gone *through* a company process
Regards,
--
[EMAIL PROTECTED]
[EMAIL PROTECTED] gmail | hotmail | yahoo
On Tue, 2006-12-19 at 13:38 -0500, Bruce Momjian wrote:
> Joshua D. Drake wrote:
> > On Tue, 2006-12-19 at 12:11 -0500, Bruce Momjian wrote:
> > > I have written an article about the complexities of companies
> > > contributing to open source projects:
> > >
> > > http://momjian.us/main/writings
Joshua D. Drake wrote:
> On Tue, 2006-12-19 at 12:11 -0500, Bruce Momjian wrote:
> > I have written an article about the complexities of companies
> > contributing to open source projects:
> >
> > http://momjian.us/main/writings/pgsql/company_contributions/
> >
> > If you have any suggestions
On Tue, 2006-12-19 at 18:05 +, Gregory Stark wrote:
> "Simon Riggs" <[EMAIL PROTECTED]> writes:
>
> > Like to see some tests with 2 parallel threads, since that is the most
> > common case. I'd also like to see some tests with varying queries,
> > rather than all use select count(*). My worry
"Simon Riggs" <[EMAIL PROTECTED]> writes:
> Like to see some tests with 2 parallel threads, since that is the most
> common case. I'd also like to see some tests with varying queries,
> rather than all use select count(*). My worry is that these tests all
> progress along their scans at exactly th
On Tue, 2006-12-19 at 17:43 +, Simon Riggs wrote:
> On Tue, 2006-12-19 at 09:07 -0800, Jeff Davis wrote:
> > I have updated my Synchronized Scan patch and have had more time for
> > testing.
> >
> > Go to http://j-davis.com/postgresql/syncscan-results10.html
> > where you can download the patc
On Tue, 2006-12-19 at 12:11 -0500, Bruce Momjian wrote:
> I have written an article about the complexities of companies
> contributing to open source projects:
>
> http://momjian.us/main/writings/pgsql/company_contributions/
>
> If you have any suggestions, please let me know. I am going t
On Tue, 2006-12-19 at 09:07 -0800, Jeff Davis wrote:
> I have updated my Synchronized Scan patch and have had more time for
> testing.
>
> Go to http://j-davis.com/postgresql/syncscan-results10.html
> where you can download the patch, and see the benchmarks that I've run.
>
> The results are very
The 8.2.0 release went well. We spent a month more in beta than we
planned, but that time helped to eliminate many bugs, and many that had
existed in previous PostgreSQL major releases as well. We have had very
few bug reports for 8.2.0, and will be doing a minor release in 1-2
weeks to get those
I have written an article about the complexities of companies
contributing to open source projects:
http://momjian.us/main/writings/pgsql/company_contributions/
If you have any suggestions, please let me know. I am going to add a
link to this from the developer's FAQ.
--
Bruce Momjia
I have updated my Synchronized Scan patch and have had more time for
testing.
Go to http://j-davis.com/postgresql/syncscan-results10.html
where you can download the patch, and see the benchmarks that I've run.
The results are very promising. I did not see any significant slowdown
for non-concurre
Greetings,
Subject pretty much says it all. I've put up with this error in the
past when it has caused me trouble but it's now starting to hit our
clients on occation which is just unacceptable.
The way I've seen it happen, and this is just empirically so I'm not
sure that it's exactly
On Tue, Dec 19, 2006 at 10:48:41AM -0500, Andrew Dunstan wrote:
> Sure, but the only sane way I can think of to do that would be have
> separate logical and physical orderings, with a map between the two. I
> guess we'd need to see what the potential space savings would be and
> establish what t
> > > > MinGW has fseeko64 and ftello64 with off64_t.
> > > >
> > >
> > > Maybe we need separate macros for MSVC and MinGW. Given the other
> >
> > You mean something quick and dirty like this ? That would work.
>
> Yes, except does that actually work? If so you found the place in the
> hea
Gregory Stark wrote:
"Andrew Dunstan" <[EMAIL PROTECTED]> writes:
I'm not a big fan of ordering columns to optimise record layout, except in the
most extreme cases (massive DW type apps). I think visible column order should
be logical, not governed by physical considerations.
Well as
On Tue, Dec 19, 2006 at 04:25:18PM +0100, Zeugswetter Andreas ADI SD wrote:
>
> > Did you see this from Andreas?
> >
> > > MinGW has fseeko64 and ftello64 with off64_t.
> > >
> >
> > Maybe we need separate macros for MSVC and MinGW. Given the other
>
> You mean something quick and dirty lik
> Did you see this from Andreas?
>
> > MinGW has fseeko64 and ftello64 with off64_t.
> >
>
> Maybe we need separate macros for MSVC and MinGW. Given the other
You mean something quick and dirty like this ? That would work.
Andreas
pg_dump_fseeko64.patch
Description: pg_dump_fseeko64.patc
1 - 100 of 124 matches
Mail list logo