On fre, 2010-10-08 at 16:13 -0700, Bryson Holland wrote:
> what other information do you need from me to make this useful?
Platform, version, command line
> configure: WARNING: uuid.h: present but cannot be compiled
> configure: WARNING: uuid.h: check for missing prerequisite headers?
> confi
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
> 2 days ago I made a bug report through the bug reporting form on
> postgresql.org regarding some unusual bloat in my TOAST tables, but it still
> hasn't shown up on this ML, so I guess it's stuck in the moderation queue.
> Could someone look
Tom Lane writes:
> You would need to take that up with whoever packages Postgres for
> Ubuntu. It sounds like they have some glitch in the package setup.
> AFAIK, whoever that is doesn't read this list, which is mainly for
> upstream Postgres development.
I think Martin Pitt reads this list, he'
Adam Matan writes:
> I'm using postgresql 8.3 in my Ubuntu 8.04 dekstop computer. I have tried to
> install postgresql 8.4 for some testing, and removed it afterwards
> using *apt-get purge*.
> But still, pg_config remains with the removed version, after postresql
> restart and even total reboot:
Adam Matan writes:
> But still, pg_config remains with the removed version, after postresql
> restart and even total reboot:
>
> $ pg_config
> BINDIR = /usr/lib/postgresql/8.4/bin
[...]
> This creates confusion with external software packages trying to use pgxs,
> for example.
> Any ideas how t
황수진 wrote:
>
> postgres=# \encoding
> EUC_KR
> postgres=# CREATE DATABASE 수진이_친구;
> WARNING: could not determine encoding for locale "Korean_Korea.949": codeset
> is
> "CP949"
> 상세정보: Please report this to http://www.postgresql.org/mailpref/pgsql-bugs
i discovered records in my postgresql database missing every 6 - 8 months. i supsect those not updated or amended are the ones that are gone, still wondering the real reason behind ? i doubt is lack of vaccum as my transactions are minnimal, inserting about 200 records each month and updating abou
On 2005-05-11, Vincent Vanwynsberghe <[EMAIL PROTECTED]> wrote:
> The AIX 5.3 provide the structure sockaddr_storage :
>
> struct sockaddr_storage {
> ushort_t__ss_family;/* address family */
> char__ss_pad1[_SS_PAD1SIZE]; /* pad up to alignment
> field */
>
Vincent Vanwynsberghe <[EMAIL PROTECTED]> writes:
> The AIX 5.3 provide the structure sockaddr_storage :
> ...
> In Postgress this structure sockaddr_storage is filled with the structure
> sockaddr_un but the size of sockaddr_storage
> is less then the size of sockaddr_un and cause a memory overfl
PROTECTED]; pgsql-bugs@postgresql.org
> Subject: Re: [BUGS] Bug Report with Postgres 7.4 on AIX 5.3
>
>
> Vincent Vanwynsberghe <[EMAIL PROTECTED]> writes:
> > In our platform the sizeof of struct sockaddr_un is 1025 and
> the sizeof of
> > SockAddr is 144.
>
> Doesn&#x
Vincent Vanwynsberghe <[EMAIL PROTECTED]> writes:
> In our platform the sizeof of struct sockaddr_un is 1025 and the sizeof of
> SockAddr is 144.
Doesn't AIX provide struct sockaddr_storage? That struct has to be at
least as large as any of the other platform-specific sockaddr structs.
On Fri, Jan 14, 2005 at 09:50:32PM -0400, Elvis E. Henriquez A. wrote:
Hi,
Please keep the copy to the list when replying.
> C:\Documents and Settings\Elvis>psql -h localhost -U postgres -f Update13.sql
> prueba
> could not find a "psql" to execute
> Password:
> could not find a "psql" to execu
On Tue, Jan 11, 2005 at 07:27:44AM -0400, Elvis E. Henriquez A. wrote:
> PostgreSQL RC4 Command prompt functions on Windows (Windows 2000
> Professional - Spanish with SP4) still displays a message in the format:
> could not find a "functionname" to execute when executing a psql, pg_dump,
> created
Andrew Grillet <[EMAIL PROTECTED]> writes:
> Original bug I was trying to report is that 7.4.5 builds OK on Freebsd
> 4.10 and runs fine, but if you try "createlang" (eg to install plpgsql)
> it fails because of undefined symbol "downcase_truncate_identifier".
I think you are trying to load a 7.
Ralf Burger <[EMAIL PROTECTED]> writes:
> ./postgresql-8.0.0beta2/bin/psql template1
> ./postgresql-8.0.0beta2/bin/psql: error while loading shared libraries:
> ./postgresql-8.0.0beta2/bin/psql: undefined symbol: PQserverVersion
You're linking against an old (pre-8.0) libpq. Check your ldconfig
s
Mark Round <[EMAIL PROTECTED]> writes:
> I am trying to compile Postgres-8.0.0beta1 on Solaris 8/x86, using Sun's
> C compiler, and get the following error which told me to contact you :-
> "../../../../src/include/storage/s_lock.h", line 654: #error: PostgreSQL
> does not have native spinlock s
"Douglas M. Westfall" <[EMAIL PROTECTED]> writes:
> 1) table contains a valid inet field
> 2) query works fine in pgsql 7.2 & 7.3
> 3) query no longer works in pgsql 7.4
> select * from where ilike '%%' ;
> ERROR: Unable to identify an operator '~~*' for types 'inet' and '"unknown"'
>
On Sat, 22 Nov 2003, Douglas M. Westfall wrote:
> Yes, I have searched the archives, and searches for 'inet' or 'ilike' or
> 'inet+ilike' and 'inet&ilike' return 0 results each.
>
> Have I missed something?
I believe your problem is that you were relying on a cast from inet to
text (on which ilik
Yes, I have searched the archives, and searches for 'inet' or 'ilike' or
'inet+ilike' and 'inet&ilike' return 0 results each.
Have I missed something?
Regards,
DougW
On Thu, 2003-11-20 at 23:09, Douglas M. Westfall wrote:
> If PostgreSQL failed to compile on your computer or you found a bug tha
Nuts, my sincere apologies on this one. This is the one server in our
entire farm that is not 7.3.4. I'm upgrading right now.
Sorry for the inconvenience!
On Wed, 8 Oct 2003, Joe Conway wrote:
> Branden R. Williams wrote:
> >
"Branden R. Williams" <[EMAIL PROTECTED]> writes:
> When using the replace() function, it appears that some of the output is
> filtered through a printf variant.
This was fixed as of 7.3.3.
regards, tom lane
---(end of broadcast)---
Branden R. Williams wrote:
POSTGRESQL BUG REPORT TEMPLATE
Your name : Branden R. Williams
Your email addres
On Thu, 2003-10-02 at 00:54, Tom Lane wrote:
> Arguile <[EMAIL PROTECTED]> writes:
> > Simplest case to test is:
> > pg_ctl start -D /valid/db/dir -l /invalid/dir
> > pg_ctl: /invalid/dir: No such file or directory
> > postmaster successfully started
>
> > Postmaster hasn't started and
Arguile <[EMAIL PROTECTED]> writes:
> Simplest case to test is:
> pg_ctl start -D /valid/db/dir -l /invalid/dir
> pg_ctl: /invalid/dir: No such file or directory
> postmaster successfully started
> Postmaster hasn't started and the error could probably use some work.
If you don't spec
Added to TODO:
* Have pg_dump -c clear the database using dependency
information
---
Preston Landers wrote:
>
>
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > Tom Lane wrote:
> >> The correct use of dependency information would be to sort the DROPs
> >> into an order that should succeed *without* CASCADE. (This will
> >> actually happen for free AIUI, once pg_dump uses dependency info fully
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> The correct use of dependency information would be to sort the DROPs
>> into an order that should succeed *without* CASCADE. (This will
>> actually happen for free AIUI, once pg_dump uses dependency info fully.
>> DROPping in the rever
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > Once pg_dump starts using the dependency information, it seems it could
> > do the drops in the proper order, and when it detects
> > mutually-dependent tables, it can use a single DROP CASCADE to remove
> > them all --- seems like tha
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Once pg_dump starts using the dependency information, it seems it could
> do the drops in the proper order, and when it detects
> mutually-dependent tables, it can use a single DROP CASCADE to remove
> them all --- seems like that is a TODO.
You missed m
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > Should we be using CASCADE? Seems that is going to double-drop some
> > tables.
>
> It kinda scares me too. If you are loading into a database that already
> has stuff in it, seems like CASCADE could lead to dropping stuff that is
>
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Should we be using CASCADE? Seems that is going to double-drop some
> tables.
It kinda scares me too. If you are loading into a database that already
has stuff in it, seems like CASCADE could lead to dropping stuff that is
not part of the dataset being
This is a tough one. The CASCADE shouldn't be needed because the clean
should be done in an ordering so that dependency is honored. Of course,
that doesn't fix problems with mutually-dependent tables.
Should we be using CASCADE? Seems that is going to double-drop some
tables.
Hi Stephan,
>
> Only a bad database superuser should be able to do anything of the sort
> because normal users shouldn't be allowed to use CREATE FUNCTION with C
> language functions (it's untrusted), are you seeing something different?
>
I am sorry!
I really did not perceive that only one adm
Diego Linke - GAMK <[EMAIL PROTECTED]> writes:
> The problem is that postgresql when calls a function in external C,
> calls with user of the postgres.
The ability to create C functions is reserved to superusers, for exactly
this reason. If you have the rights to make the backend execute
arbitrar
On Thu, 14 Aug 2003, Diego Linke - GAMK wrote:
> Your name : Diego Linke
> Your email address : [EMAIL PROTECTED]
>
> System Configuration
> -
> Architecture (example: Intel Pentium) : Intel
>
> Operating System (example: Linux 2.0.26 ELF) : NetB
Dear Tom,
>
>
> > If I gave you access to an SGI running PostgreSQL 7.3.2, would you
> > be willing to log in and explore the problem "live"?
>
> You bet. Do you have gdb installed?
Thank you so much.
WRT to gdb, it's not available. However, you can use dbx, SGI's
debugger. It's similar so yo
> If I gave you access to an SGI running PostgreSQL 7.3.2, would you
> be willing to log in and explore the problem "live"?
You bet. Do you have gdb installed?
regards, tom lane
---(end of broadcast)---
TIP 5: Have you che
Dear Tom,
>
>
> "Robert E. Bruccoleri" <[EMAIL PROTECTED]> writes:
> > The PostgreSQL backend core dumps reproducibly with a set of LOCK commands that
> > would normally deadlock.
>
> Can't duplicate that here, using either 7.3 branch or CVS tip. You sure
> you have a clean build?
Oh yes, the
Dear Neil,
>
> On Thu, 2003-03-20 at 19:26, Robert E. Bruccoleri wrote:
> > MIPS Pro 7.4 and MIPS Pro 7.3.1.3, 64 bit compilation model.
>
> I've seen some other people having troubles with PostgreSQL compiled
> with Mips Pro on IRIX/MIPS -- does the problem persist if you recompile
> PostgreSQL
On Thu, 2003-03-20 at 19:26, Robert E. Bruccoleri wrote:
> MIPS Pro 7.4 and MIPS Pro 7.3.1.3, 64 bit compilation model.
I've seen some other people having troubles with PostgreSQL compiled
with Mips Pro on IRIX/MIPS -- does the problem persist if you recompile
PostgreSQL with gcc?
Cheers,
Neil
"Robert E. Bruccoleri" <[EMAIL PROTECTED]> writes:
> The PostgreSQL backend core dumps reproducibly with a set of LOCK commands that
> would normally deadlock.
Can't duplicate that here, using either 7.3 branch or CVS tip. You sure
you have a clean build?
regards, tom lan
On Tue, 2001-11-27 at 16:39, TONY J.Y. wrote:
> However, I got a fatal running error. There is an error when my SQL
> string length exceeds 8190 Bytes.
PostgreSQL 7.0.x and earlier have a restriction of 8k for a text field.
7.1.x doesn't. You should upgrade.
Markus Bertheau
msg03166/pgp00
Joel G Guevara writes:
> I am using PostgreSQL version 6.5 (included in Red Hat Linux 6.2).
bug report: version is too old
--
Peter Eisentraut [EMAIL PROTECTED] http://funkturm.homeip.net/~peter
---(end of broadcast)---
TIP 3: if posting/re
"Frank Contrepois" <[EMAIL PROTECTED]> writes:
> everything work fine if the query"FOR riga IN SELECT * FROM fr_tab_conv1
> WHERE ordre >= or AND gnum = gn AND glettre = gl ORDER BY ordre DESC LOOP"
> return something if not:
This is fixed in 7.1.2.
regards, tom lane
I will see if I can narrow things down a bit. The advantage of the complicated
query was that it was killing the backend making the problem obvious.
Just using to_char with 'RN' doesn't always do that. Sometimes I get warings
during the queries that hint at memory corruption.
I am pretty sure tha
On Fri, 15 Dec 2000, Bruce Momjian wrote:
> I think this is fixed in the current snapshot.
>
> > I am getting problems when using to_char to convert an int4 to roman numeral
> > and to_char to convert a timestamp to a string in a view. The errors
> > vary, but it looks like there is some sort o
I think this is fixed in the current snapshot.
>
> POSTGRESQL BUG REPORT TEMPLATE
>
>
>
> Your name :
IIRC, the temp-table support was new and still a little flaky in 6.5.*.
I'd suggest updating to 7.0.3.
regards, tom lane
> to_char gives incorrect day conversion of the date 2000/03/26.
This is fixed in the current (development) sources.
- Thomas
Martin Renters <[EMAIL PROTECTED]> writes:
> Backend crash with attached script
> The original issue that triggered this was an attempt to implement field
> auditing in 7.0beta3. It worked fine as long as the fields were not NULL.
> I've simplified the code as much as possible to only print valu
Eko Purwanto <[EMAIL PROTECTED]> writes:
> I think there is a bug when processing VIEW containing view name or
> table name WITH SPACE.
I believe this is fixed in current sources.
regards, tom lane
51 matches
Mail list logo
