Tom Lane wrote:
Andrew Dunstan <[EMAIL PROTECTED]> writes:
It is building with thread.c but it should not be unless I am misreading
the Makefile. The makefile processing in Project.pm doesn't look nearly
powerful enough to handle this:
# thread.c is needed only for non-WIN32 i
Andrew Dunstan <[EMAIL PROTECTED]> writes:
> It is building with thread.c but it should not be unless I am misreading
> the Makefile. The makefile processing in Project.pm doesn't look nearly
> powerful enough to handle this:
> # thread.c is needed only for non-WIN32 implementation of path.c
>
Tom Lane wrote:
This morning's ecpg patch certainly seems to have been snake-bit.
Although the Windows gcc buildfarm members seem happy, the MSVC ones
are all failing with
Linking...
Creating library Release\libecpg\libecpg.lib and object
Release\libecpg\libecpg.exp
libecpg
[EMAIL PROTECTED] (Bruce Momjian) writes:
> I think we need another week to get things ready for beta. I will have
> the release notes done mid-week and hopefully we can close out all open
> items by the end of the week.
It's worth noting that Greg Smith has collected release note
information int
On 10/1/07, Islam Hegazy <[EMAIL PROTECTED]> wrote:
> I am a graduate student in the University of Calgary. I want to add some new
> operators to PostgreSQL to perform some specific tasks in a project I am
> working in. My problem is that I cannot find my way into the code, where
> should I start a
Dear PostgreSQL developers
I am a graduate student in the University of Calgary. I want to add some new
operators to PostgreSQL to perform some specific tasks in a project I am
working in. My problem is that I cannot find my way into the code, where should
I start and where to find the document
Gregory Stark <[EMAIL PROTECTED]> writes:
> "Tom Lane" <[EMAIL PROTECTED]> writes:
>> Gregory Stark <[EMAIL PROTECTED]> writes:
>>> Why do you cast arguments to memcmp to char* ?
>>
>> Well, *I* haven't done it in a long time,
> I'm referring to tuptoaster.c:488
Oh, I'm sorry, I thought you wer
"Tom Lane" <[EMAIL PROTECTED]> writes:
> Gregory Stark <[EMAIL PROTECTED]> writes:
>> Why do you cast arguments to memcmp to char* ?
>
> Well, *I* haven't done it in a long time,
I'm referring to tuptoaster.c:488
--
Gregory Stark
EnterpriseDB http://www.enterprisedb.com
-
Gregory Stark <[EMAIL PROTECTED]> writes:
> Why do you cast arguments to memcmp to char* ?
Well, *I* haven't done it in a long time, but it used to be a fairly
standard thing. I imagine that back before memcpy was usually declared
with void * arguments, it was necessary to avoid compiler warnings
This morning's ecpg patch certainly seems to have been snake-bit.
Although the Windows gcc buildfarm members seem happy, the MSVC ones
are all failing with
Linking...
Creating library Release\libecpg\libecpg.lib and object
Release\libecpg\libecpg.exp
libecpg.exp : error LNK2001
"Tom Lane" <[EMAIL PROTECTED]> writes:
> Apparently gcc's thought process is "the pointer is declared as struct
> varlena *, therefore must be at least 4-aligned, therefore the data at
> offset 2 is at least 2-aligned". The intermediate cast to "varattrib_1b_e *"
> did not prevent this; I had to a
Gregory Stark <[EMAIL PROTECTED]> writes:
> Here's a patch that does all of the above.
Applied with tweak to use the added byte as an actual length word.
I ran into an interesting failure here on HPPA: the code the compiler
generated for copying unaligned toast pointers into aligned local
variab
Tom Lane wrote:
> "Guillaume Smet" <[EMAIL PROTECTED]> writes:
>> So a total of: 16 minutes for 8.2 compared to 53 minutes for 8.3 to
>> have the database in the same state.
>
> Please try that experiment with all three configurations on both
> versions:
> * autovacuum off
> * autovacu
On 9/29/07, Bruce Momjian <[EMAIL PROTECTED]> wrote:
> I think we need more than one person's request to add this function.
Well, I don't expect it would get requested. Most DBAs would likely
look for the function in the docs, see it's not there and then just
implement it themselves. Obviously i
Stefan Kaltenbrunner <[EMAIL PROTECTED]> writes:
> Michael Meskes wrote:
>> Applied another patch by ITAGAKI Takahiro <[EMAIL PROTECTED]>
>> to get memory allocation thread-safe. He also did some cleaning up.
> this patch seems to break every single buildfarm member out there:
> http://buildfarm.p
Stefan Kaltenbrunner <[EMAIL PROTECTED]> writes:
> Michael Meskes wrote:
>> Applied another patch by ITAGAKI Takahiro <[EMAIL PROTECTED]>
>> to get memory allocation thread-safe. He also did some cleaning up.
> this patch seems to break every single buildfarm member out there:
> http://buildfarm.p
Gregory Stark <[EMAIL PROTECTED]> writes:
> "Tom Lane" <[EMAIL PROTECTED]> writes:
>> I'd be inclined to make the second byte be the length and have
>> VARSIZE_1B_E depend on that --- any objection?
> On one hand it offends me since it's hard coding an assumption that the size
> of a pointer decid
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> Bruce Momjian <[EMAIL PROTECTED]> writes:
>>> I think we need another week to get things ready for beta.
>>
>> Why? Other than the lack of release notes, we could wrap on Monday.
> OK, Monday is fine. It seemed to me there were was
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > I think we need another week to get things ready for beta.
>
> Why? Other than the lack of release notes, we could wrap on Monday.
OK, Monday is fine. It seemed to me there were was a lot of activity in
recent days so I wasn't sure
On Sun, 2007-09-30 at 00:25 -0400, Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > I think we need another week to get things ready for beta.
>
> Why? Other than the lack of release notes, we could wrap on Monday.
+1
The full release notes aren't really required for Beta.
We ca
20 matches
Mail list logo
