On Fri, 11 Jan 2013, Tom Lane wrote:
pgbuildf...@jdrake.com writes:
Well, that's darn interesting in itself, because the error message looks
like it should be purely a linker issue. (And I note that your other
buildfarm animal mongoose uses icc but is working anyway, so that's
definitely
On Wed, 28 Nov 2012, Tom Lane wrote:
Andrew Dunstan and...@dunslane.net writes:
On 11/28/2012 02:14 PM, Alvaro Herrera wrote:
Okapi has been failing sporadically on ecpg, and I wonder if it's
related to this change.
Well, it looks like the make is broken and missing a clear dependency
On Wed, 28 Nov 2012, Tom Lane wrote:
Jeremy Drake pgbuildf...@jdrake.com writes:
While we're talking about odd issues that only seem to happen on Okapi,
does anyone know of anything I can do to diagnose the pg_upgrade failure
on the 9.2 branch? There are no rogue (non-buildfarm-related
On Sun, 4 Sep 2011, Tom Lane wrote:
What I would suggest is to see whether a more recent x86 version shows
the problem or not. If not, let's just write it off as an already-fixed
compiler bug.
I have installed the most recent version in the home directory of a
purpose-made user on that
On Mon, 5 Sep 2011, Bruce Momjian wrote:
Jeremy Drake wrote:
I think tomorrow I'll try to get the 9.0 compiler set up on a clean VM,
and if the issue duplicates there, I can see about setting up SSH access
if anyone is still interested in investigating this further.
What would we
On Sun, 4 Sep 2011, Tom Lane wrote:
Jeremy Drake jere...@jdrake.com writes:
I didn't see any changes that looked like they affected
CurrentMemoryContext, but I attached the compressed context diff in case
you want to look at it.
Right now I have a feeling that this is a compiler bug
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 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 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 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 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 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 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 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 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
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, 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
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, 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 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 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 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
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
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 *)
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
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
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 Sun, 18 Mar 2007, Tom Lane wrote:
another icc crash|
2007-02-03 10:50:01 | 1
icc internal error |
2007-03-16 16:30:01 |29
These on mongoose are most likely a result of flaky
On Fri, 16 Mar 2007, Andrew Dunstan wrote:
OK, for anyone that wants to play, I have created an extract that contains a
summary of every non-CVS-related failure we've had. It's a single table
looking like this:
CREATE TABLE mfailures (
sysname text,
snapshot timestamp without time
On Fri, 2 Mar 2007, Tom Lane wrote:
Jeremy Drake [EMAIL PROTECTED] writes:
On several occasions I have wanted to input integers in hexadecimal rather
than in decimal in PostgreSQL. I notice that there is a to_hex function,
but there is not (AFAIK) a way to provide an integer
On several occasions I have wanted to input integers in hexadecimal rather
than in decimal in PostgreSQL. I notice that there is a to_hex function,
but there is not (AFAIK) a way to provide an integer in hexadecimal.
I have written a pure-sql implementation of some functions to input
integers in
On Sun, 25 Feb 2007, Tom Lane wrote:
Jeremy Drake [EMAIL PROTECTED] writes:
psql:bogus_varattno_error.sql:23: ERROR: bogus varattno for OUTER var: 5
Any ideas what is causing this?
This looks pretty nearly related to stuff I've been hacking on recently,
so I suppose I broke something
The attached sql file creates some table infrastructure and then tries to
explain a query. I get the following error on CVS HEAD:
psql:bogus_varattno_error.sql:23: ERROR: bogus varattno for OUTER var: 5
In my real data, when I attempt to run the query I get the error:
ERROR: invalid attribute
On Sat, 24 Feb 2007, Warren Turkal wrote:
The interesting thing about Git is that is has two way sync support for a SVN
repository also. You could run a Git repository pushing changes in real time
to a SVN repository and present a CVS frontend also. I would like to try
converting the CVS
On Sat, 24 Feb 2007, Warren Turkal wrote:
On Saturday 24 February 2007 00:32, Jeremy Drake wrote:
Use cvsup, or if you don't want to go through the effort of getting that
set up, use rsync:
rsync -avzCH --delete rsync.postgresql.org::pgsql-cvs cvsroot/
Thanks
I made some notes about what you said about my patch, just so that I can
be sure that it is clear what it does.
On Sun, 11 Feb 2007, David Fetter wrote:
== PostgreSQL Weekly News - February 11 2007 ==
== Pending Patches ==
Jeremy Drake sent in a patch which implements regexp_replace
On Mon, 12 Feb 2007, Teodor Sigaev wrote:
Log Message:
---
Fix backend crash in parsing incorrect tsquery.
Per report from Jon Rosebaugh [EMAIL PROTECTED]
Is this a security issue? Does it need a new security release? I hope
that the answer is not this is contrib, it isn't as
On Tue, 13 Feb 2007, Peter Eisentraut wrote:
We don't treat crashes to be security issues of the kind that calls for
the full security exercise.
But if a security issue, by whatever definition of the term applies to
core, is found in contrib, it would result in the full security exercise,
On Mon, 12 Feb 2007, Tom Lane wrote:
Jeremy Drake [EMAIL PROTECTED] writes:
On Mon, 12 Feb 2007, Teodor Sigaev wrote:
Fix backend crash in parsing incorrect tsquery.
Is this a security issue? Does it need a new security release?
We looked at this and determined that the worst
On Sun, 4 Feb 2007, David Fetter wrote:
On Fri, Feb 02, 2007 at 07:01:33PM -0800, Jeremy Drake wrote:
Let me know if you see any bugs or issues with this code, and I am
open to suggestions for further regression tests ;)
I have not heard anything, so I guess at this point I should figure
On Wed, 7 Feb 2007, Tom Lane wrote:
Jeremy Drake [EMAIL PROTECTED] writes:
* Put together a patch to add these functions to core. I could put them
directly in regexp.c, so the support functions could stay static. My
concern here is that I don't know if there are any functions
If I have a multi-call SRF and a user_fctx struct allocated in the
multi_call_memory_ctx, and in the if(SRF_IS_FIRSTCALL()) block while still
in the multi_call_memory_ctx I use PG_GETARG_TEXT_P(n) to get an argument
to my function, and stash the result of this in my user_fctx struct, am I
On Tue, 6 Feb 2007, Pavel Stehule wrote:
Hello,
Currently PostgreSQL support set returning functions.
ANSI SQL 2003 goes with new type of functions - table functions. With this
syntax
CREATE FUNCTION foo() RETURNS TABLE (c1 t1, ... )
PostgreSQL equal statements are:
CREATE TYPE
I am writing a set returning function in C. There are cases where I can
know definitively, upfront, that this function will only return one row.
I have noticed, through happenstance of partially converted function, that
I can mark a normal, non-set returning function as returning SETOF
something,
On Thu, 1 Feb 2007, David Fetter wrote:
Yes, although it might have the same name, as in regex_match(pattern
TEXT, string TEXT, return_pre_and_post BOOL).
The data structure could be something like
TYPE matches (
prematch TEXT,
matchTEXT[],
postmatch TEXT
)
I just
On Fri, 2 Feb 2007, Jeremy Drake wrote:
jeremyd=# select * from regexp_matches('foobarbequebaz',
$re$(bar)(beque)$re$, false);
prematch | fullmatch | matches | postmatch
--+---+-+---
\N | \N| {bar,beque} | \N
(1 row)
I just changed
On Fri, 2 Feb 2007, Jeremy Drake wrote:
I just coded up for this:
CREATE FUNCTION regexp_matches(IN str text, IN pattern text) RETURNS
text[]
AS 'MODULE_PATHNAME', 'regexp_matches'
LANGUAGE C IMMUTABLE STRICT;
CREATE FUNCTION regexp_matches(
IN str text, IN pattern text
I am wanting to write some new C functions which leverage postgresql's
existing regexp code in an extension module. I notice that the functions
RE_compile_and_cache and RE_compile_and_execute in
src/backend/util/regexp.c contain the code necessary to connect the regexp
code in src/backend/regex
On Thu, 1 Feb 2007, Tom Lane wrote:
Jeremy Drake [EMAIL PROTECTED] writes:
Is there some specific reason that these functions are static,
Yeah: not cluttering the global namespace.
Is there a reason for not putting your new code itself into regexp.c?
Not really, I just figured it would
On Thu, 1 Feb 2007, David Fetter wrote:
On Thu, Feb 01, 2007 at 05:11:30PM -0800, Jeremy Drake wrote:
Anyway, the particular thing I was writing was a function like
substring(str FROM pattern) which instead of returning just the
first match group, would return an array of text containing
On Wed, 24 Jan 2007, Tom Lane wrote:
* For an untrusted language: must be superuser to either create or use
the language (no change from current rules). Ownership of the
pg_language entry is really irrelevant, as is its ACL.
* For a trusted language:
* if pg_pltemplate.something is ON:
On Wed, 24 Jan 2007, Peter Eisentraut wrote:
Teodor Sigaev wrote:
If there aren't objections then we plan commit patch tomorrow or
after tomorrow.
I still haven't heard any argument for why this would be necessary or
desirable at all, other than that it looks better for marketing
On Wed, 24 Jan 2007, Martijn van Oosterhout wrote:
On Wed, Jan 24, 2007 at 09:38:06PM +0100, Stefan Kaltenbrunner wrote:
sure that ISP is a bit stupid(especially wrt plpgsql) - but tsearch2 in
the current version is actually imposing some additional(often
non-trivial) complexity for things
On Wed, 24 Jan 2007, Tom Lane wrote:
[ redirecting thread from -patches to -hackers for wider comment ]
Jeremy Drake [EMAIL PROTECTED] writes:
On Wed, 24 Jan 2007, Tom Lane wrote:
Note I'm not arguing against allowing it to be on by default, I just
want to be sure there is a way
On Wed, 24 Jan 2007, Jeremy Drake wrote:
I am digging through the code looking at this, and I have a question. As
far as I can tell, there is currently no owner for a pg_language entry.
Is this correct or is ownership information stored somewhere other than
the pg_language relation? Are you
On Tue, 23 Jan 2007, Magnus Hagander wrote:
On Tue, Jan 23, 2007 at 09:31:40AM -0500, Andrew Dunstan wrote:
Magnus Hagander wrote:
Hi!
I get failures for the largeobject regression tests on my vc++ build. I
don't think this has ever worked, given that those tests are fairly new.
Any
It looks like pltcl regression tests are failing due to the recent ORDER
BY ... USING change.
http://www.pgbuildfarm.org/cgi-bin/show_log.pl?nm=mongoosedt=2007-01-09%2002:30:01
--
Horse sense is the thing a horse has which keeps it from betting on
people.
-- W. C. Fields
Seems that the contrib regression tests, namely the cash and oid tests of
the btree_gist contrib module, are failing after the recent commit to
widen the money type to 64 bits. Example:
http://www.pgbuildfarm.org/cgi-bin/show_log.pl?nm=mongoosedt=2007-01-03%2005:30:01
Also, on a slightly
On Tue, 2 Jan 2007, Jeremy Drake wrote:
Seems that the contrib regression tests, namely the cash and oid tests of
the btree_gist contrib module, are failing after the recent commit to
widen the money type to 64 bits. Example:
http://www.pgbuildfarm.org/cgi-bin/show_log.pl?nm=mongoosedt=2007
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
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
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
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 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
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
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 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
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
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, 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
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, 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
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 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
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.
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 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
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 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
1 - 100 of 138 matches
Mail list logo
