This patch implements the ability for large objects to be larger than 2GB.
I believe the limit to now be about 2TB, based on the fact that the large
object page size is 2048 bytes, and the page number is still 32 bits.
There are a few things about this patch which probably require tweaking or
at
I sent this from the wrong address last time so it did not go to the list,
I apologize to anyone who may be getting it again...
On Fri, 23 Sep 2005, Tom Lane wrote:
Jeremy Drake [EMAIL PROTECTED] writes:
2) The lo_*64, in order to be convenient from the client end, have
functions added
On Fri, 23 Sep 2005, Tom Lane wrote:
postgresql-fe.h defines a ton of stuff that has no business being
visible to libpq's client applications. It's designed to be used by
our *own* client-side code (psql and the like), but we have not made
any attempt to keep it from defining stuff that
On Fri, 23 Sep 2005, Tom Lane wrote:
Jeremy Drake [EMAIL PROTECTED] writes:
2) The lo_*64, in order to be convenient from the client end, have
functions added to libpq as the existing lo_* functions. The client side
of libpq did not previously know anything about int64 or how to
send
On Sat, 24 Sep 2005, Tom Lane wrote:
Jeremy Drake [EMAIL PROTECTED] writes:
In any case, are there any comments on the changes below libpq (the
functions visible to queries on down)?
Within the backend, I don't see the point in maintaining a distinction
between 32- and 64-bit APIs
On Sat, 24 Sep 2005, Alvaro Herrera wrote:
Hey,
While you guys are hacking at the LO code, it would be nice to consider
the suggestions outlined here:
http://archives.postgresql.org/pgsql-bugs/2004-07/msg00143.php
Included from that message for easier reference:
0) In Oid lo_creat(PGconn
We have encountered a very nasty but apparently rare bug which appears to
result in catalog corruption. I have not been able to pin down an exact
sequence of events which cause this problem, it appears to be a race
condition of some sort. This is what I have been able to figure out so
far.
* It
Code from perl cookbook, wrapped in plperlu wrapper
not very portable, Net::SMTP would probably be better, and result in more
portable perl code.
Didn't test this - but it is copied straight from perl cookbook via
google: http://www.unix.org.ua/orelly/perl/cookbook/ch18_04.htm
CREATE OR REPLACE
On Wed, 21 Dec 2005, Tom Lane wrote:
Jeremy Drake [EMAIL PROTECTED] writes:
We have encountered a very nasty but apparently rare bug which appears to
result in catalog corruption.
How much of this can you reproduce on 8.1.1? We've fixed a few issues
already.
We did not see this problem
Here is some additional information that I have managed to gather today
regarding this. It is not really what causes it, so much as what does
not.
I removed all plperl from the loading processes. I did a VACUUM FULL
ANALYZE, and then I reindexed everything in the database (Including
starting
On Thu, 5 Jan 2006, Tom Lane wrote:
The ReadBuffer bug I just fixed could result in disappearance of catalog
rows, so this observation is consistent with the theory that that's
what's biting you. It's not proof though...
Well, I applied that patch that you sent me the link to (the bufmgr.c
On Fri, 6 Jan 2006, Tom Lane wrote:
Jeremy Drake [EMAIL PROTECTED] writes:
Well, I applied that patch that you sent me the link to (the bufmgr.c
one), and rebuilt (PORTDIR_OVERLAY is cool...)
I ran my nine processes which hammer things overnight, and in the
morning one of them was dead
On Fri, 6 Jan 2006, Tom Lane wrote:
OK, this must be a different issue then. I think we have seen reports
like this one before, but not been able to reproduce it.
Could you rebuild with Asserts enabled and see if any asserts trigger?
I got an assert to fail. I'm not entirely sure if this
On Sat, 7 Jan 2006, Tom Lane wrote:
Fascinating --- that's not anywhere near where I thought your problem
was. Which cache is this tuple in? (Print *ct-my_cache)
$2 = {
id = 3,
cc_next = 0x2aac1048,
cc_relname = 0x2ab19df8 pg_amop,
cc_reloid = 2602,
cc_indexoid = 2654,
On Sat, 7 Jan 2006, Tom Lane wrote:
Jeremy Drake [EMAIL PROTECTED] writes:
Am I correct in interpreting this as the hash opclass for Oid?
However, AFAICS the only consequence of this bug is to trigger
that Assert failure if you've got Asserts enabled. Dead catcache
entries aren't actually
On Sat, 7 Jan 2006, Tom Lane wrote:
Jeremy Drake [EMAIL PROTECTED] writes:
On Sat, 7 Jan 2006, Tom Lane wrote:
I'll go fix CatCacheRemoveCList, but I think this is not the bug
we're looking for.
A bit of a leap in the dark, but: maybe the triggering event for this
situation
On Sun, 8 Jan 2006, Tom Lane wrote:
Yeah, that's not very surprising. Running the forced-cache-resets
function will definitely expose that catcache bug pretty quickly.
You'd need to apply the patches I put in yesterday to have a system
that has any chance of withstanding that treatment for
On Mon, 9 Jan 2006, Tom Lane wrote:
Does your application drop these temp tables explicitly, or leave them
to be dropped automatically during commit? It might be interesting to
see whether changing that makes any difference.
I drop them explicitly at the end of the function.
I'm also
On Thu, 19 Jan 2006, Jim C. Nasby wrote:
Do you still have that patch that folks could look at? ISTM that this
technique would be rather dependant on your actual workload, and as such
could result in a big win for certain types of queries.
It is not a patch, per se. It is a c language
On Thu, 19 Jan 2006, Jim C. Nasby wrote:
Feel free to do whatever with this, it's pretty fast for tables where
seeks to validate tuples would hurt, but you do get back dead things...
How'd you then weed out the dead tuples?
I didn't get that far with it. The purpose of this function was
On Fri, 3 Feb 2006, Josh Berkus wrote:
The feature you proposed is a way to make your idiosyncratic setup easier
to manage, but doesn't apply to anyone else's problems on this list, so
you're going to have a hard time drumming up enthusiasm.
I am somewhat reluctant to interject into this
It looks like pg_column_size gives you the actual size on disk, ie after
compression.
What looks interesting for you would be byteaoctetlen or the function it
wraps, toast_raw_datum_size. See src/backend/access/heap/tuptoaster.c.
pg_column_size calls toast_datum_size, while
On Tue, 28 Mar 2006, Tom Lane wrote:
Larry Rosenman ler@lerctr.org writes:
The other issue is borked installs where the server and libpq disagree.
What I'm looking for
is to expose what libpq has for it's default as well as what the server is
using. There is currently
no way to
On Wed, 26 Apr 2006, Teodor Sigaev wrote:
We (me and Oleg) are glad to present GIN to PostgreSQL. If community will
agree, we will commit it to HEAD branch.
http://www.sigaev.ru/gin/gin.gz
http://www.sigaev.ru/gin/README.txt
Install:
% cd pgsql
% zcat gin.gz | patch -p0
make and
On Thu, 25 May 2006, Tom Lane wrote:
Joshua D. Drake [EMAIL PROTECTED] writes:
I encountered this the other day and set up a build farm client for it.
http://www.pgbuildfarm.org/cgi-bin/show_log.pl?nm=meerkatdt=2006-05-25%2018:16:36
That NaN problem has been discussed before, and I
On Mon, 7 Aug 2006, Tom Lane wrote:
Stefan Kaltenbrunner [EMAIL PROTECTED] writes:
*) why the large difference in the build-flags ?
CVS HEAD configure.in knows about icc and the release branches don't.
I think the changes were only put into HEAD because of lack of testing,
but if we have
On Mon, 7 Aug 2006, Tom Lane wrote:
Stefan Kaltenbrunner [EMAIL PROTECTED] writes:
*) why the large difference in the build-flags ?
CVS HEAD configure.in knows about icc and the release branches don't.
I think the changes were only put into HEAD because of lack of testing,
but if we have
On Mon, 7 Aug 2006, Stefan Kaltenbrunner wrote:
the just added new buildfarm member leveret (fedora core5 x86_64) is
building with the recently released Intel C-compiler version 9.1.
It passes all tests on -HEAD but fails on make check in both
REL8_1_STABLE and REL8_0_STABLE.
The logs of the
Sorry if this gets through more than once, I seem to be having email
difficulties...
On Tue, 5 Sep 2006, Jeremy Drake wrote:
I noticed when I was working on a patch quite a while back that there are
no regression tests for large object support. I know, large objects
are not the most sexy
On Tue, 5 Sep 2006, Joshua D. Drake wrote:
Right, but just took a reboot to fix it isn't very confidence inspiring ;)
Are you kidding? This is standard procedure for troubleshooting Windows
problems :)
--
The world is coming to an end. Please log off.
---(end of
I noticed when I was working on a patch quite a while back that there are
no regression tests for large object support. I know, large objects
are not the most sexy part of the code-base, and I think they tend to be
ignored/forgotten most of the time. Which IMHO is all the more reason
they should
On Sun, 10 Sep 2006, Kevin Brown wrote:
Tom Lane wrote:
(does anyone know the cost of ntohl() on modern
Intel CPUs?)
I have a system with an Athlon 64 3200+ (2.0 GHz) running in 64-bit
mode, another one with the same processor running in 32-bit mode, a a
third running a Pentium 4 1.5 GHz
On Mon, 11 Sep 2006, Adrian Maier wrote:
It's not clear to me where does that date-in-the-future come from.
The machine's
date is set correctly:
$ date
Mon Sep 11 11:00:30 PST 2006
Um, no. I am currently in the PST time zone, and I can say from
first-hand experience that the current time
On Wed, 13 Sep 2006, Tom Dunstan wrote:
Another possibility would be to test these patches in some kind of virtual
machine that gets blown away every X days, so that even if someone did get
something malicious in there it wouldn't last long.
Or just have a snapshot which is reverted after
On Fri, 15 Sep 2006, Dave Page wrote:
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of
Ricardo Malafaia
Sent: 15 September 2006 16:35
To: Andrew Dunstan
Cc: pgsql-hackers@postgresql.org
Subject: Re: [HACKERS] polite request about syntax
On Tue, 19 Sep 2006, Alvaro Herrera wrote:
Jeremy Drake wrote:
I have found the same thing with the type timestamp without time zone.
The verbosity of type names seems rather extreme.
Then use simply timestamptz (with TZ) or timestamp (without).
Didn't know about these, learn something
On Wed, 20 Sep 2006, Gregory Stark wrote:
[EMAIL PROTECTED] writes:
I have the impression I'm not being heard.
*I* control the MAC address assignment for all of *MY* units.
No, you're missing the point. How does that help *me* avoid collisions with
your UUIDs? UUIDs are supposed to be
On Wed, 20 Sep 2006, Bruce Momjian wrote:
Doesn't creating many temp tables in a transaction do the same thing?
---
Like this?
jeremyd=# CREATE OR REPLACE FUNCTION testy(n integer) returns integer as $$
BEGIN
EXECUTE
On Thu, 21 Sep 2006, Tom Lane wrote:
Jeremy Drake [EMAIL PROTECTED] writes:
I put together a patch which adds a regression test for large objects,
hopefully attached to this message. I would like some critique of it, to
see if I have gone about it the right way. Also I would be happy
I just messed with a bunch of my majordomo settings and I wanted to make
sure things are working the way I thought. Please disregard. Sorry to
bother everyone
--
I'll defend to the death your right to say that, but I never said I'd
listen to it!
-- Tom Galloway with apologies
On Sun, 24 Sep 2006, Jeremy Drake wrote:
On Thu, 21 Sep 2006, Tom Lane wrote:
I suggest that instead of testing the server-side lo_import/lo_export
functions, perhaps you could test the psql equivalents and write and
read a file in psql's working directory.
I did not see any precedent
On Sun, 24 Sep 2006, Jeremy Drake wrote:
On Thu, 21 Sep 2006, Tom Lane wrote:
I think we could do without the Moby Dick extract too ...
I am open to suggestions. I saw one suggestion that I use an image of an
elephant, but I suspect that was tongue-in-cheek. I am not very fond
On Wed, 27 Sep 2006, Lukas Kahwe Smith wrote:
Dave Page wrote:
I have now moved the wiki installation to:
http://developer.postgresql.org/
BTW: I am wondering if there is an RSS feed of the changes?
On my wiki I have an RSS feed for every page, subwiki (aka area) and the
entire wiki
On Sun, 24 Sep 2006, Jeremy Drake wrote:
On Thu, 21 Sep 2006, Tom Lane wrote:
I suggest that instead of testing the server-side lo_import/lo_export
functions, perhaps you could test the psql equivalents and write and
read a file in psql's working directory.
snip
In the mean time, I
On Mon, 25 Sep 2006, Tom Lane wrote:
Jeremy Drake [EMAIL PROTECTED] writes:
I just tried using the \lo_import command in a regression test, and I
think I figured out why this will not work:
...
Yes, that's the large object OID in the output there, and it is different
each run (as I
I was just trying to build using the src/tools/msvc scripts on windows,
and I was wondering if there were any instructions on how to do this, what
prerequisites there are, where to get them, etc. I couldn't find any, but
I may not know the correct place to look.
Sorry if this is the wrong list
On Mon, 2 Oct 2006, Tom Lane wrote:
Jeremy Drake [EMAIL PROTECTED] writes:
I grabbed flex and bison from GNUwin32
(http://gnuwin32.sourceforge.net/packages/bison.htm)
This appears to not work out well. If I copy the generated files from
bison from a linux box, then they are ok
On Mon, 2 Oct 2006, Magnus Hagander wrote:
This appears to not work out well. If I copy the generated
files from bison from a linux box, then they are ok, but if I
try to use ones generated using that version of bison, it
does not compile. I'll look around for a different one.
That's
On Sun, 1 Oct 2006, Jeremy Drake wrote:
On Mon, 2 Oct 2006, Magnus Hagander wrote:
If you do build solution it should build all project sin the correct
order - there are dependency references set between them that should
take care of this automatically.
If I do build solution it tells
On Mon, 2 Oct 2006, Tom Lane wrote:
Jeremy Drake [EMAIL PROTECTED] writes:
The errors I got on this file were:
1bootparse.tab.c(1065) : error C2449: found '{' at file scope (missing
function header?)
I looked at this. Line 1065 is the left brace starting yyparse(). On
my Fedora Core
I now get things to compile, but now I get linker errors on any dll which
needs to access symbols from postgres.exe via postgres.lib. For example:
1-- Build started: Project: autoinc, Configuration: Release Win32 --
1Generate DEF file
1Not re-generating AUTOINC.DEF, file already exists.
On Tue, 3 Oct 2006, Magnus Hagander wrote:
Looks like the gendef script is failing. Check the contents of
release\postgres\postgres.def - it should have thousands of symbols, but
I'm willing to bet it's empty...
It contains one word: EXPORTS. I assume this means it is empty. What
should I
On Tue, 3 Oct 2006, Magnus Hagander wrote:
Looks like the gendef script is failing. Check the contents of
release\postgres\postgres.def - it should have thousands of
symbols,
but I'm willing to bet it's empty...
It contains one word: EXPORTS. I assume this means it is
empty.
On Tue, 3 Oct 2006, Magnus Hagander wrote:
Funky.
Can you try having it run the dumpbin command into a tempfile, and then
open-and-read that tempfile, to see if that makes a difference?
(Assuming you know enough perl to do that, of course)
Doing it as
system(dumpbin /symbols $_ $tmpfn)
It looks like something broke the ECPG-Check recently. A number of
buildfarm members are failing.
On Tue, 3 Oct 2006, PG Build Farm wrote:
The PGBuildfarm member mongoose had the following event on branch HEAD:
Failed at Stage: ECPG-Check
The snapshot timestamp for the build that
I just came across this code I wrote about a year ago which implements a
function equivilant to width_bucket for timestamps.
I wrote this when I was trying to plot some data over time, and I had more
points than I needed. This function allowed me to create a pre-determined
number of bins to
On Mon, 9 Oct 2006, Tom Lane wrote:
It's not clear to me why we have width_bucket operating on numeric and
not float8 --- that seems like an oversight, if not outright
misunderstanding of the type hierarchy.
Would that make the below a lot faster?
But if we had the float8
version, I think
On Wed, 28 Mar 2007, Simon Riggs wrote:
On Wed, 2007-03-28 at 17:12 -0400, Bruce Momjian wrote:
If everybody knows where everybody stands then we'll all be better off.
There may be other dependencies that need resolution, or last minute
decisions required to allow authors to finish.
Wasn't
On Tue, 24 Apr 2007, Bruce Momjian wrote:
Naz Gassiep wrote:
A few of us on IRC were wondering what the status of tsearch2 is in 8.3 ?
Was it decided to include it in core or did we decide to keep FTS as a
plugin?
Some brief comments from anyone on the inside of the whole FTS issue
The buildfarm appears to be failing after the recent pgstat patch.
The failure seems to be caused by this failed assertion, which appears to
occur fairly consistently in the ECPG tests, in the postmaster log:
TRAP: FailedAssertion(!(entry-trans == 0L), File: pgstat.c, Line: 696)
--
Disco is
Just glancing at this, a couple things stand out to me:
On Mon, 4 Jun 2007, Rodrigo Sakai wrote:
Datum
periodo_in(PG_FUNCTION_ARGS)
{
char*str = PG_GETARG_CSTRING(0);
chartvi_char[MAXDATEFIELDS];
chartvf_char[MAXDATEFIELDS];
tvi_char = (char *)
Was there some change in functionality reason for renaming is_array_type
to type_is_array? It broke compilation of fulldisjunctions, which I build
and run regression tests on in my sandbox to keep it getting too horribly
broken with respect to current HEAD. I got it to build and pass its
On Thu, 7 Jun 2007, Tom Lane wrote:
Jeremy Drake [EMAIL PROTECTED] writes:
Was there some change in functionality reason for renaming is_array_type
to type_is_array?
Just to sync style with type_is_enum ... there were more of the latter
than the former.
OK, so it is safe to just #define
On Sat, 16 Jun 2007, Michael Fuhr wrote:
A message entitled Having Fun With PostgreSQL was posted to Bugtraq
today. I haven't read through the paper yet so I don't know if the
author discusses security problems that need attention or if the
article is more like a compilation of Stupid
On Tue, 26 Jun 2007, Tom Lane wrote:
Gregory Stark [EMAIL PROTECTED] writes:
All that really has to happen is that dblink should by default not be
callable by any user other than Postgres.
Yeah, that is not an unreasonable change. Someone suggested it far
upthread, but we seem to have
On Tue, 26 Jun 2007, Andrew Dunstan wrote:
Jeremy Drake wrote:
2. If you cannot tell what process is connecting on a local socket (which
I suspect you cannot portably),
See ident_unix() in hba.c.
It might not be 100% portable but I think it's fairly close for platforms
that actually
On Thu, 12 Jul 2007, Stefan Kaltenbrunner wrote:
What would probably be useful if you want to pursue this is to filter
out the obvious spam like statement-not-reached, and see what's left.
I had gone through and looked at the warnings on mongoose before, but I am
running it against the
On Tue, 7 Aug 2007, Decibel! wrote:
ISTM that having a built-in array_to_set function would be awfully
useful... Is the aggregate method below an acceptable way to do it?
Umm, the array_to_set function is not an aggregate. Personally, when I
need this functionality, I use this function
I just saw that my buildfarm member (running ICC 9.0 on linux) failed
after the latest change to configure
http://www.pgbuildfarm.org/cgi-bin/show_log.pl?nm=mongoosedt=2007-09-11%2020:45:01
I was the one who sent in the first patch to configure to add the check
for ICC, and as I recall at the
On Wed, 12 Sep 2007, Tom Lane wrote:
Jeremy Drake [EMAIL PROTECTED] writes:
I just saw that my buildfarm member (running ICC 9.0 on linux) failed
after the latest change to configure
Argh! Can someone quote chapter and verse from the ICC manual about
this? I was just following what
On Tue, 2 Oct 2007, Gregory Stark wrote:
(we don't seem to have a recent icc ia32 build farm member).
Sorry about that, my buildfarm member (mongoose) is down with hardware
problems, and probably will be for the forseeable future. For some
reason, it suddenly decided to stop recognizing its
On Thu, 3 Apr 2008, Peter Eisentraut wrote:
Am Donnerstag, 3. April 2008 schrieb Andrew Dunstan:
If this were at all true we would not not have seen the complaints from
people along the lines of My ISP won't install contrib. But we have,
and quite a number of times. We have concrete
On Sat, 17 May 2008, Tom Lane wrote:
Does anyone know how to get the child
process exit status on Windows?
GetExitCodeProcess, if you've got the process handle handy (which I assume
you do, since you most likely were calling one of the WaitFor...Object
family of functions.
On Mon, 18 Aug 2008, Tom Lane wrote:
What would make more sense is to redesign the large-object stuff to be
somewhat modern and featureful, and provide stream-access APIs (think
lo_read, lo_seek, etc) that allow offsets wider than 32 bits.
A few years ago, I was working on such a project for
On Mon, 5 Nov 2007, Gregory Stark wrote:
How many developers have even jumped through the hoops to get wiki accounts?
According to
http://developer.postgresql.org/index.php?title=Special:Listusersgroup=pgdevlimit=500
there are currently 51 members of the group pgdev on the wiki.
--
Spare no
On Fri, 16 Nov 2007, Tom Lane wrote:
GIN index build's allocatedMemory counter needs to be long, not uint32.
Else, in a 64-bit machine with maintenance_work_mem set to above 4Gb,
the counter overflows
I don't know if this has been discussed before, but you are aware that it
is not dictated by
On Sat, 9 Feb 2008, Hiroshi Saito wrote:
Um, I was flipped off by you
You shouldn't go around flipping people off: it's rude :)
http://www.merriam-webster.com/dictionary/flip%20off
---(end of broadcast)---
TIP 4: Have you searched our list
On Mon, 18 Feb 2008, Tom Lane wrote:
There seems to have been a bit of a brain cramp upstream :-(.
Previously, AC_FUNC_FSEEKO did this to test if fseeko was available:
return !fseeko;
Now it does this:
return fseeko (stdin, 0, 0) (fseeko) (stdin, 0, 0);
Unfortunately, that
On Fri, 22 Feb 2008, D'Arcy J.M. Cain wrote:
On Fri, 22 Feb 2008 07:37:55 +
Dave Page [EMAIL PROTECTED] wrote:
I know I'm gonna regret wading in on this, but in my mind this is akin
to one of the arguments for including tsearch in the core server -
namely that too many brain dead
On Sun, 15 Oct 2006, [EMAIL PROTECTED] wrote:
On Sun, Oct 15, 2006 at 08:31:36PM +0530, Merlin Moncure wrote:
On 10/15/06, Anon Mous [EMAIL PROTECTED] wrote:
Would it be possible to combine a special memcache implementation of
memcache with a Postgresql interface wrapper?
have you seen
I set up the following experiment:
CREATE DOMAIN m_or_p AS char CHECK (VALUE = 'm' OR VALUE = 'p');
CREATE TABLE test_domain (
fkey integer not null,
kinteger not null,
x1 integer not null,
x2 integer,
mp m_or_p not null
);
CREATE INDEX test_domain_k_x1_x2_m ON test_domain (k,
On Sun, 15 Oct 2006, Tom Lane wrote:
Jeremy Drake [EMAIL PROTECTED] writes:
CREATE TABLE test_domain (
fkey integer not null,
kinteger not null,
x1 integer not null,
x2 integer,
mp m_or_p not null
);
CREATE INDEX test_domain_k_x1_x2_m ON test_domain (k, x1, x2
On Mon, 16 Oct 2006, [EMAIL PROTECTED] wrote:
On Sun, Oct 15, 2006 at 06:33:36PM -0700, Jeremy Drake wrote:
2) When updating a PostgreSQL record, I updated the memcache record
to the new value. If another process comes along in parallel before
I commit, that is still
I noticed something odd when trying to use the row-wise comparison
mentioned in the release notes for 8.2 and in the docs
http://developer.postgresql.org/pgdocs/postgres/functions-comparisons.html#ROW-WISE-COMPARISON
This sets up a suitable test:
create type myrowtype AS (a integer, b integer);
On Fri, 20 Oct 2006, Tom Lane wrote:
Jeremy Drake [EMAIL PROTECTED] writes:
select rowval from myrowtypetable ORDER BY ROW((rowval).*) USING ;
ERROR: operator does not exist: record record
This isn't required by the spec, and it's not implemented. I don't
see that it'd give any new
On Mon, 23 Oct 2006, Mark Kirkwood wrote:
Tom Lane wrote:
Yah, I checked. Several times... but if anyone else wants to repeat
the experiment, please do. Or look for bugs in either my test case
or Gurjeet's.
Just for fun, I tried it out with both GCC and with Intel's C compiler
On Mon, 23 Oct 2006, Tom Lane wrote:
Jeremy Drake [EMAIL PROTECTED] writes:
So at this point I realize that intel's compiler is optimizing the loop
away, at least for the std crc and probably for both. So I make mycrc an
array of 2, and substript mycrc[j1] in the loop.
That's not a good
On Mon, 23 Oct 2006, Tom Lane wrote:
Hmm. Maybe store the CRCs into a global array somewhere?
uint32 results[NTESTS];
for ...
{
INIT/COMP/FIN_CRC32...
results[j] = mycrc;
}
This still adds a bit of overhead to the outer loop, but not
On Thu, 26 Oct 2006, Alvaro Herrera wrote:
Jeff Trout wrote:
On Oct 26, 2006, at 3:23 PM, Martijn van Oosterhout wrote:
On Thu, Oct 26, 2006 at 03:15:00PM -0400, Andrew Dunstan wrote:
Perhaps people who use other platforms could look for these flags
in the
output of
perl -e
I was trying to compile 8.2beta3 on openbsd, and ran into an interesting
issue. My account on the particular openbsd box has some restrictive
ulimit settings, so I don't have a lot of memory to work with. I was
getting an out of memory issue linking postgres, while I did not before.
I figured
On Fri, 17 Nov 2006, Tom Lane wrote:
Peter Eisentraut [EMAIL PROTECTED] writes:
I don't see any comparable arguments about this full-text search stuff.
In particular I don't see any arguments why a change would necessary at
all, including why moving to core would be necessary in the first
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. Ulimit
I adjusted my buildfarm config (mongoose) to attempt to build HEAD
--with-libxml. I added the following to build-farm.conf:
if ($branch eq 'HEAD' || $branch ge 'REL8_3')
{
push(@{$conf{config_opts}},
--with-includes=/usr/include/et:/usr/include/libxml2);
push(@{$conf{config_opts}},
On Fri, 22 Dec 2006, Tom Lane wrote:
Jeremy Drake [EMAIL PROTECTED] writes:
As seen, I needed to add an include dir for configure to pass. However,
make check fails now with the backend crashing. This can be seen in the
buildfarm results for mongoose.
Can you provide a stack trace
On Fri, 22 Dec 2006, Tom Lane wrote:
Jeremy Drake [EMAIL PROTECTED] writes:
Can you provide a stack trace for that crash?
#0 0xb7c4dc85 in memcpy () from /lib/tls/libc.so.6
#1 0x08190f59 in appendBinaryStringInfo (str=0xbfd87f90,
data=0x841ffc0 qux, datalen=138543040
On Sat, 23 Dec 2006, Tom Lane wrote:
Peter Eisentraut [EMAIL PROTECTED] writes:
Jeremy Drake wrote:
#0 0xb7c4dc85 in memcpy () from /lib/tls/libc.so.6
#1 0x08190f59 in appendBinaryStringInfo (str=0xbfd87f90,
data=0x841ffc0 qux, datalen=138543040) at stringinfo.c:192
#2 0x0828377f
On Fri, 22 Dec 2006, Jeremy Drake wrote:
On Sat, 23 Dec 2006, Tom Lane wrote:
Peter Eisentraut [EMAIL PROTECTED] writes:
Jeremy Drake wrote:
#0 0xb7c4dc85 in memcpy () from /lib/tls/libc.so.6
#1 0x08190f59 in appendBinaryStringInfo (str=0xbfd87f90,
data=0x841ffc0 qux, datalen
On Sat, 23 Dec 2006, Tom Lane wrote:
Ah-hah, I've sussed it. sqlchar_to_unicode() calls the
mb2wchar_with_len converters, which are defined to return a *null
terminated* pg_wchar string. So even if you only ask for the conversion
of a single character, you need a 2-pg_wchar array to hold
On Sun, 31 Dec 2006, Gurjeet Singh wrote:
On 12/31/06, Andrew Dunstan [EMAIL PROTECTED] wrote:
Gurjeet Singh wrote:
BTW, I don't know how to make sure that the effect of a doc patch looks
fine
in a browser. I mean, how to view the doc/src/sgml/*.sgml in a browser,
nicely
I came across this when looking through the patches_hold queue link that
Bruce sent out.
http://momjian.us/mhonarc/patches_hold/msg00162.html
There is no patch or anything associated with it, just the suggestion that
it be put in when 8.3 devel starts up.
Just thought I'd put this back out
1 - 100 of 138 matches
Mail list logo
