On Wed, 28 Nov 2012, Tom Lane wrote:
> Andrew Dunstan 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
> > requi
On Wed, 28 Nov 2012, Tom Lane wrote:
> Jeremy Drake 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-buildfa
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
> definitel
On Sun, 4 Sep 2011, Tom Lane wrote:
> Jeremy Drake 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 th
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 mac
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 th
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 flak
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.
Was
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 iss
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
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 *) palloc(s
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
regressi
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
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 t
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 thin
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 conve
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=mongoose&dt=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 ti
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
&g
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 RA
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:Listusers&group=pgdev&limit=500
there are currently 51 members of the group "pgdev" on the wiki.
--
"Spa
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
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 archiv
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 fo
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);
>
> Unfortuna
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 brai
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 concret
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.
http://msdn.micros
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?
> > h
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, x
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
>
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 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);
c
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
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
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
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 loo
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
> > >>outp
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 out
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 th
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
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.
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,
>
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 &qu
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
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,
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 there
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=mongoose&dt=2007-01-03%2005:30:01
Also, on a slightly off-top
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
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=mongoose&dt=2007-01-09%2002:30:01
--
Horse sense is the thing a horse has which keeps it from betting on
people.
-- W. C. Fields
--
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 fai
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
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
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 re
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
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 wi
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 r
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 re
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
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,bequ
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 FUNCTI
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 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
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 t
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
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
guarantee
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
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
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,
c
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
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 r
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
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 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 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 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 w
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 t
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 w
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 w
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
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
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 br
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
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 t
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 a
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 ab
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 &qu
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 sup
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
EXECUT
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
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 to
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 dir
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.
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
> en
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 dire
1 - 100 of 142 matches
Mail list logo
