I am sure I set binary mode. Even with that and an identical
file length, I figured I should confirm a good transfer before
posting; hence the md5sum on both sides.
Both sides were built from the source. Here at home I don't
have the info on what configure switches were used, but I did
both the
Hi,
PostgreSql 8.1 RC1 ( --with-perl --with-python) passed all tests on
Slackware Linux 10.2 (kernel 2.4.31, x86)
Regards,
Adrian Maier
---(end of broadcast)---
TIP 1: if posting/reading through Usenet, please send an appropriate
s
Andrew Dunstan <[EMAIL PROTECTED]> writes:
> Hmm. Windows reports an offset size of 4 bytes on a dump I just made ...
> is that relevant? What governs it?
[ looks again... ] Hm, that is a 40Gb dump Kevin is complaining of,
isn't it. Do our Windows builds have LARGEFILE support?
Greg Stark <[EMAIL PROTECTED]> writes:
> I happen to think that except for the rare assertion that has major
> performance impact all the assertions should be on in production builds. The
> goal of assertions is to catch corruption quickly and that's something that's
> just as important in producti
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> Jonah H. Harris wrote:
>> Does anyone have a copy of xlogdump updated for 8.1? If so, please send me a
>> copy. Otherwise I'll update it and forward the diffs.
> We should definitely consider completing it and including it in contrib.
There is already
Hmm. Windows reports an offset size of 4 bytes on a dump I just made ...
is that relevant? What governs it?
cheers
andrew
Kevin Grittner wrote:
Posting here because it may be a 8.1 pre-release problem. I'll take
it to the admin list if it looks like it's not.
File dumped from 8.1beta3 us
"Kevin Grittner" <[EMAIL PROTECTED]> writes:
> File dumped from 8.1beta3 using pg_dump -Fc on Linux box.
> This dump restored successfully onto 8.1RC1 on Linux box.
> File FTP'd to Windows box; attempt to restore onto 8.1RC1 fails with:
> pg_restore [archiver] file offset in dump file is too large
Bruce Momjian writes:
> Jim C. Nasby wrote:
>
> > My assumption is that the asserts that are currently in place fall into
> > one of two categories: either they check for something that if false
> > could result in data corruption in the heap, or they check for something
> > that shouldn't happe
I agree.
On 11/1/05, Alvaro Herrera <[EMAIL PROTECTED]> wrote:
Jonah H. Harris wrote:> Does anyone have a copy of xlogdump updated for 8.1? If so, please send me a
> copy. Otherwise I'll update it and forward the diffs.We should definitely consider completing it and including it in contrib.--Alvaro
On 11/1/05 2:38 PM, "Jim C. Nasby" <[EMAIL PROTECTED]> wrote:
>
> FWIW, most databases I've used limit NUMERIC to 38 digits, presumably to
> fit length info into 1 or 2 bytes. So there's something to be said for a
> small numeric type that has less overhead and a large numeric (what we
> have toda
Jonah H. Harris wrote:
> Does anyone have a copy of xlogdump updated for 8.1? If so, please send me a
> copy. Otherwise I'll update it and forward the diffs.
We should definitely consider completing it and including it in contrib.
--
Alvaro Herrera Valdivia, Chile ICBM: S 39º 49' 17.7",
What about the Google Core Dumper? :)
http://sourceforge.net/projects/goog-coredumper/
Chris
Peter Eisentraut wrote:
Martijn van Oosterhout wrote:
3. Add either a GUC or a command line switch or PGOPTION switch to
automatically invoke and attach gdb on certain types of error.
Obviously you
Does anyone have a copy of xlogdump updated for 8.1? If so, please send me a copy. Otherwise I'll update it and forward the diffs.
-Jonah
Posting here because it may be a 8.1 pre-release problem. I'll take
it to the admin list if it looks like it's not.
File dumped from 8.1beta3 using pg_dump -Fc on Linux box.
This dump restored successfully onto 8.1RC1 on Linux box.
File FTP'd to Windows box; attempt to restore onto 8.1RC1 fails w
Simon Riggs <[EMAIL PROTECTED]> writes:
> Anybody like to work out a piece of SQL to perform data profiling and
> derive the distribution of values with trailing zeroes?
Don't forget leading zeroes. And all-zero (we omit digits entirely in
that case). I don't think you can claim that zero isn't
[EMAIL PROTECTED] (Alvaro Herrera) writes:
> Chris Browne wrote:
>> [EMAIL PROTECTED] ("Jim C. Nasby") writes:
>>
>> > On Tue, Nov 01, 2005 at 11:23:55AM -0300, Alvaro Herrera wrote:
>> >> Tom Lane wrote:
>> >> > "Jim C. Nasby" <[EMAIL PROTECTED]> writes:
>> >> > > AFAIK they're not using subtran
"Jim C. Nasby" <[EMAIL PROTECTED]> writes:
> On Tue, Nov 01, 2005 at 05:40:35PM -0500, Tom Lane wrote:
>> Maybe if we had a few other datatypes that could also use the feature.
>> [ thinks... ] inet/cidr comes to mind but I don't see any others.
>> The case seems a bit weak :-(
> Would varchar(25
On Tue, 2005-11-01 at 23:16 +0100, Martijn van Oosterhout wrote:
lots of useful things, thank you.
> > So, assuming I have this all correct, means we could reduce the on disk
> > storage for NUMERIC datatypes to the following struct. This gives an
> > overhead of just 2.5 bytes, plus the loss of
"Jim C. Nasby" <[EMAIL PROTECTED]> writes:
> FWIW, most databases I've used limit NUMERIC to 38 digits, presumably to
> fit length info into 1 or 2 bytes. So there's something to be said for a
> small numeric type that has less overhead and a large numeric (what we
> have today).
I don't think it'
On Tue, Nov 01, 2005 at 05:40:35PM -0500, Tom Lane wrote:
> Martijn van Oosterhout writes:
> > You are proposing a fourth type, say VARLENA2 which looks a lot like a
> > verlena but it's not. I think the shear volume of code that would need
> > to be checked is huge. Also, things like pg_attribute
On Tue, 2005-11-01 at 16:54 -0500, Tom Lane wrote:
> Simon Riggs <[EMAIL PROTECTED]> writes:
> > varlen is int32 to match the standard varlena header. However, the max
> > number of digits of the datatype is less than the threshold at which
> > values get toasted. So no NUMERIC values ever get toas
On Tue, Nov 01, 2005 at 11:16:58PM +0100, Martijn van Oosterhout wrote:
> Consider the algorithm: A number is stored as base + exponent. To
> multiply two numbers you can multiply the bases and add the exponents.
> OTOH, if you store the decimal inside the data, now you have to extract
> it again b
Martijn van Oosterhout writes:
> You are proposing a fourth type, say VARLENA2 which looks a lot like a
> verlena but it's not. I think the shear volume of code that would need
> to be checked is huge. Also, things like pg_attribute would need
> changing because you have to represent this new stat
On Tue, Nov 01, 2005 at 04:54:11PM -0500, Tom Lane wrote:
> It might be reasonable to restrict the range of NUMERIC to the point
> that we could fit the weight/sign/dscale into 2 bytes instead of 4,
> thereby saving 2 bytes per NUMERIC. I'm not excited about the other
> aspects of this, though.
F
On Tue, Nov 01, 2005 at 09:22:17PM +, Simon Riggs wrote:
> varlen is int32 to match the standard varlena header. However, the max
> number of digits of the datatype is less than the threshold at which
> values get toasted. So no NUMERIC values ever get toasted - in which
> case, why worry about
Simon Riggs <[EMAIL PROTECTED]> writes:
> varlen is int32 to match the standard varlena header. However, the max
> number of digits of the datatype is less than the threshold at which
> values get toasted. So no NUMERIC values ever get toasted - in which
> case, why worry about matching the size of
Hi Richard,
Dunno if you'll see this via the list, but your email address seems to
be bouncing messages from me:
dev@archonet.com on 01/11/2005 20:48
The message cannot be delivered due to a configuration error
on the server. Please contact your Administrator.
< s1.u
Currently, the overhead of NUMERIC datatype is 8 bytes. Each value is
stored on disk as
typedef struct NumericData
{
int32 varlen; /* Variable size (std varlena header) */
int16 n_weight; /* Weight of 1st digit */
uint16 n_sign_dscale; /* Sign + display
Chris Browne wrote:
> [EMAIL PROTECTED] ("Jim C. Nasby") writes:
>
> > On Tue, Nov 01, 2005 at 11:23:55AM -0300, Alvaro Herrera wrote:
> >> Tom Lane wrote:
> >> > "Jim C. Nasby" <[EMAIL PROTECTED]> writes:
> >> > > AFAIK they're not using subtransactions at all, but I'll check.
> >> >
> >> > Well
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi Lamar,
On Mon, 31 Oct 2005, Lamar Owen wrote:
So thinking that:
* Beta and RC RPMs are used only by testers
* We use the beta and RC steps to build the new RPM sets, so that means
that actually they are not production quality looking from th
[EMAIL PROTECTED] ("Jim C. Nasby") writes:
> AFAIK they're not using subtransactions at all, but I'll check.
Are they perchance using pl/PerlNG?
We discovered a problem with Slony-I's handling of subtransactions
which was exposed by pl/PerlNG, which evidently wraps its SPI calls
inside subtransac
[EMAIL PROTECTED] ("Jim C. Nasby") writes:
> On Tue, Nov 01, 2005 at 11:23:55AM -0300, Alvaro Herrera wrote:
>> Tom Lane wrote:
>> > "Jim C. Nasby" <[EMAIL PROTECTED]> writes:
>> > > AFAIK they're not using subtransactions at all, but I'll check.
>> >
>> > Well, yeah, they are ... else you'd neve
"Jim C. Nasby" <[EMAIL PROTECTED]> writes:
> Doesn't clog use the same code?
Yeah, but all three of your examples were referencing pg_subtrans,
as proven by the stack traces and the contents of the shared control
block.
Even though the bug seems completely clog.c's fault, this is not a
coincidenc
I wrote:
> Even though the bug seems completely clog.c's fault,
s/clog.c/slru.c/ of course :-(
regards, tom lane
---(end of broadcast)---
TIP 6: explain analyze is your friend
On Tue, Nov 01, 2005 at 11:23:55AM -0300, Alvaro Herrera wrote:
> Tom Lane wrote:
> > "Jim C. Nasby" <[EMAIL PROTECTED]> writes:
> > > AFAIK they're not using subtransactions at all, but I'll check.
> >
> > Well, yeah, they are ... else you'd never have seen this failure.
>
> Maybe it's in plpgsq
On Tue, Nov 01, 2005 at 11:23:55AM -0300, Alvaro Herrera wrote:
> Tom Lane wrote:
> > "Jim C. Nasby" <[EMAIL PROTECTED]> writes:
> > > AFAIK they're not using subtransactions at all, but I'll check.
> >
> > Well, yeah, they are ... else you'd never have seen this failure.
>
> Maybe it's in plpgsq
On Tue, Nov 01, 2005 at 12:33:39PM +0100, Peter Eisentraut wrote:
> Martijn van Oosterhout wrote:
> > 3. Add either a GUC or a command line switch or PGOPTION switch to
> > automatically invoke and attach gdb on certain types of error.
> > Obviously you can only do this where stdin, stdout and std
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> The "Debug" destreceiver has a pretty bad name. In fact for PL/php it
> collides with a PHP symbol. Does anyone mind if I rename it to, say,
> DestDebug?
If you do that, you should rename all the values of the enum
(DestNone, etc). For consistency, a
On Tue, 1 Nov 2005, Peter Eisentraut wrote:
Marc G. Fournier wrote:
Also, which port of autoconf are you using? We're still stuck at
2.59, so if you are using the newer port available in FreeBSD, you
may be being bitten by that as well ...
If you're using something newer than 2.59, you're do
Hackers,
The "Debug" destreceiver has a pretty bad name. In fact for PL/php it
collides with a PHP symbol. Does anyone mind if I rename it to, say,
DestDebug?
--
Alvaro Herrerahttp://www.advogato.org/person/alvherre
"El sabio habla porque tiene algo que decir;
el tonto,
[EMAIL PROTECTED] writes:
> We'll have to add a check for ELF_SYSTEM in our own configure script.
> Wouldn't this be a problem for pgxs-compiled modules as well ?
No, because they import the PG installation's Makefile.global. If you
are importing Makefile.shlib and not Makefile.global, you are do
Marc G. Fournier wrote:
> Also, which port of autoconf are you using? We're still stuck at
> 2.59, so if you are using the newer port available in FreeBSD, you
> may be being bitten by that as well ...
If you're using something newer than 2.59, you're doing something
weird...
ftp://ftp.gnu.org/
On Tue, Nov 01, 2005 at 09:10:24AM -0500, Tom Lane wrote:
> [EMAIL PROTECTED] writes:
> > I'm having troubles building postgis HEAD on freebsd
> > using the new autoconf-based scripts.
>
> FreeBSD which, exactly? It makes a difference, because AFAICS from
> configure newer versions of FreeBSD use
Isn't the point about autoconf that the user should not have to run it,
or even have it installed? Only the package creator should have to care
about autoconf versions, surely, or else it is pointless.
cheers
andrew
Marc G. Fournier wrote:
Also, which port of autoconf are you using? We'r
Also, which port of autoconf are you using? We're still stuck at 2.59, so
if you are using the newer port available in FreeBSD, you may be being
bitten by that as well ...
On Tue, 1 Nov 2005, Tom Lane wrote:
[EMAIL PROTECTED] writes:
I'm having troubles building postgis HEAD on freebsd
Tom Lane wrote:
bigtest:
! $(SHELL) ./pg_regress --schedule=$(srcdir)/serial_schedule
--multibyte=$(MULTIBYTE) --load-language=plpgsql numeric_big $(NOLOCALE)
bigcheck:
! $(SHELL) ./pg_regress --temp-install --top-builddir=$(top_builddir)
--temp-port=$(TEMP_PORT
--- Tom Lane <[EMAIL PROTECTED]> escreveu:
> If you don't see your favorite platform already listed as tested
> for 8.1 at
>
http://developer.postgresql.org/docs/postgres/supported-platforms.html
> then please give it a try and send in your results.
>
[EMAIL PROTECTED]:~# uname -a
Linux foobar 2
Tom Lane wrote:
> "Jim C. Nasby" <[EMAIL PROTECTED]> writes:
> > AFAIK they're not using subtransactions at all, but I'll check.
>
> Well, yeah, they are ... else you'd never have seen this failure.
Maybe it's in plpgsql EXCEPTION clauses.
--
Alvaro Herrera Valdivia, Chile ICBM: S 39º 4
[EMAIL PROTECTED] writes:
> I'm having troubles building postgis HEAD on freebsd
> using the new autoconf-based scripts.
FreeBSD which, exactly? It makes a difference, because AFAICS from
configure newer versions of FreeBSD use ELF, and the link switches
are different then.
> The Makefile.shlib
Andrew Dunstan <[EMAIL PROTECTED]> writes:
> This has refreshed my fading memory. The patch seems like the best
> solution. Is there any objection to applying it?
Putting the switch at the end seems certain to fail on some platforms
(some versions of getopt are fussier than others).
> bigtes
Salman Razzaq <[EMAIL PROTECTED]> writes:
> I want to store default values of arguments in pg_proc catalog. i have to
> add a column in the table. but what will be the type of column as to store
> all the datatypes. do you think 'Datum' can be stored as it.
Don't bother worrying about that until y
This has refreshed my fading memory. The patch seems like the best
solution. Is there any objection to applying it?
(Petr, I assume you intended to send this to a mailing list also)
cheers
andrew
Original Message
Subject: Re: regression failures on WIndows in machines wit
On Sun, Oct 30, 2005 at 11:49:41AM -0500, Gregory Maxwell wrote:
> On 10/26/05, Christopher Kings-Lynne <[EMAIL PROTECTED]> wrote:
> > > iconv -c -f UTF8 -t UTF8
> > recode UTF-8..UTF-8 < dump_in.sql > dump_out.sql
>
> I've got a file with characters that pg won't accept that recode does
> not f
Martijn van Oosterhout wrote:
> 3. Add either a GUC or a command line switch or PGOPTION switch to
> automatically invoke and attach gdb on certain types of error.
> Obviously you can only do this where stdin, stdout and stderr have
> not been redirected.
Samba has a configuration parameter that
I want to store default values of arguments in pg_proc catalog. i have toadd a column in the table. but what will be the type of column as to storeall the datatypes. do you think 'Datum' can be stored as it.
I'm having troubles building postgis HEAD on freebsd
using the new autoconf-based scripts.
The Makefile.shlib file copied by pgsql sources
adds a -Bforcearchive flag to LINK.shared with
arch is freebsd, but the flag seems to be
unsupported (this is from 7.2.1 to 8.0.0)
Weird enough PostgreSQL bui
56 matches
Mail list logo
