[BUGS] BUG #4207: EXTRACT function
The following bug has been logged online:
Bug reference: 4207
Logged by: Jeferson Kasper
Email address: [EMAIL PROTECTED]
PostgreSQL version: 8.1.5
Operating system: Windows XP and Linux Redhat
Description:EXTRACT function
Details:
Hello.
First... sorry for poor english :)
My problem is quite simple.
the EXTRACT(field FROM source) function allows to use some kind of 'fields',
and i need to know if a time (like '07:00') is after the midday(12:00) or
not.
I know i can resolve it implementing some function like select
('07:00''12:00').. i just want to know if is difficult to implement a new
field called 'am', to use like.
select extract(AM from '07:00');
?column?
t
i hope its not difficult, and i should use it, if it become available ...
Thanks for all.
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #4186: set lc_messages does not work
On Thu, May 29, 2008 at 2:05 AM, Thomas H. [EMAIL PROTECTED] wrote: From: Thomas H. [EMAIL PROTECTED] i've just verified that the 8.3.1 msi version provided on postgres.org also does NOT contain the locale folder files. should i report this as a separate bug/problem? How exactly did you do that? My installation certainly has it. If memory serves, it's not installed by default (you have to select it in the feature list), but it's there alright. -- Dave Page EnterpriseDB UK: http://www.enterprisedb.com -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #4186: set lc_messages does not work
From: Dave Page [EMAIL PROTECTED] On Thu, May 29, 2008 at 2:05 AM, Thomas H. [EMAIL PROTECTED] wrote: From: Thomas H. [EMAIL PROTECTED] i've just verified that the 8.3.1 msi version provided on postgres.org also does NOT contain the locale folder files. should i report this as a separate bug/problem? How exactly did you do that? My installation certainly has it. If memory serves, it's not installed by default (you have to select it in the feature list), but it's there alright. hmm by just clicking through the standard settings. i've seen now that the national language support is set to do not install by default. so it is a feature, not a bug, sorry. i was under the obviously wrong impression a zip-file upgrade would be the same as an msi-upgrade. - thomas -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #4186: set lc_messages does not work
On Thu, May 29, 2008 at 12:23 PM, Thomas H. [EMAIL PROTECTED] wrote: i was under the obviously wrong impression a zip-file upgrade would be the same as an msi-upgrade. Eeep - don't do that!! That is a *very* good way to annoy the Windows Installer and trick it into thinking things need to be repaired. -- Dave Page EnterpriseDB UK: http://www.enterprisedb.com -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #4207: EXTRACT function
On Thu, May 29, 2008 at 07:01:46AM +, Jeferson Kasper wrote:
the EXTRACT(field FROM source) function allows to use some kind of 'fields',
and i need to know if a time (like '07:00') is after the midday(12:00) or
not.
I know i can resolve it implementing some function like select
('07:00''12:00').. i just want to know if is difficult to implement a new
field called 'am', to use like.
select extract(AM from '07:00');
What's wrong with just doing:
SELECT extract(hour FROM date) 12;
Sam
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #4186: set lc_messages does not work
Thomas H. wrote: From: Thomas H. [EMAIL PROTECTED] what i noticed: if i delete the folder share/locale/de/ the system messages are back to english - but that can't be THE solution, can it? :) well, it actually was the solution, at least to the weird part of the problem: there are two versions of win32 binaries available on postgres.org. there's the installer msi version, and there is the installerless zip version. the installer version does NOT install the folder share/locale/! so when using the msi installer, postgres has no translations at all - thus the fallback to english. Are you sure you didn't just skip enabling National Language Support? It's not included by default, but should be available. so at least that explains the changed behaviour. nevertheless, LC_MESSAGES seems to be defunct - with the locale folder present, pg always picks the os' language and ignores the lc_message value. This looks like I can reproduce though, at least on cvs head. Did this work for you in previous versions? //Magnus -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
[BUGS] BUG #4208: Server crashes on insert into gist index
The following bug has been logged online:
Bug reference: 4208
Logged by: Ron Mackley
Email address: [EMAIL PROTECTED]
PostgreSQL version: 8.2.6
Operating system: Linux {hostname removed} 2.6.18-53.1.13.el5 #1 SMP Mon
Feb 11 13:27:27 EST 2008 x86_64 x86_64 x86_64 GNU/Linux
Description:Server crashes on insert into gist index
Details:
We've been seeing infrequent crashes of the postgres. This is version 8.2.6
running on Red Hat Enterprise 5.1 on x64 using redhat issued RPMs.
We captured a core file and here is the stack trace:
(gdb) bt
#0 0x00615b5a in pfree (pointer=0x2aaaccaff318) at mcxt.c:585
#1 0x2aaace72ab59 in cube_inter (fcinfo=0x7fff102205f0) at cube.c:898
#2 0x00602b14 in DirectFunctionCall2 (func=0x2aaace72aa00
cube_inter, arg1=46913066890008, arg2=5) at fmgr.c:888
#3 0x2aaace72a73b in g_cube_picksplit (fcinfo=value optimized out) at
cube.c:571
#4 0x0060224f in FunctionCall2 (flinfo=0x2aaaccaff318,
arg1=46913066890008, arg2=5) at fmgr.c:1162
#5 0x0044d6e6 in gistSplitByKey (r=0x2aaace6b6d40,
page=0x2aaaccafe8a0 \017, itup=0x3628200, len=83,
giststate=0x7fff10221800, v=0x7fff10221420,
entryvec=0x36269e0, attno=0) at gistsplit.c:306
#6 0x00444b15 in gistSplit (r=0x2aaace6b6d40, page=0x2aaaccafe8a0
\017, itup=0x3628200, len=83, giststate=0x7fff10221800) at gist.c:943
#7 0x004454ff in gistmakedeal (state=0x7fff10221780,
giststate=0x7fff10221800) at gist.c:329
#8 0x00445d4b in gistdoinsert (r=0x2aaace6b6d40, itup=0x362aa90,
freespace=0, giststate=0x7fff10221800) at gist.c:278
#9 0x00446115 in gistinsert (fcinfo=value optimized out) at
gist.c:242
#10 0x00601eec in FunctionCall6 (flinfo=0x75000,
arg1=46913066890008, arg2=5, arg3=5, arg4=0, arg5=4, arg6=0) at fmgr.c:1275
#11 0x0045a03f in index_insert (indexRelation=0x2aaace6b6d40,
values=0x7fff10223f90, isnull=0x7fff10224090 , heap_t_ctid=0x360256c,
heapRelation=0x2aaace6af020, check_uniqueness=0 '\0') at indexam.c:196
#12 0x005082bf in ExecInsertIndexTuples (slot=0x36011b8,
tupleid=0x360256c, estate=0x3600d10, is_vacuum=0 '\0') at execUtils.c:1116
#13 0x005006f1 in ExecutorRun (queryDesc=value optimized out,
direction=value optimized out, count=0) at execMain.c:1401
#14 0x005880d7 in ProcessQuery (parsetree=value optimized out,
plan=0x35b2ff8, params=0x0, dest=0x35b36d0, completionTag=0x7fff10224440 )
at pquery.c:157
#15 0x00588311 in PortalRunMulti (portal=0x35f63e0, dest=0x35b36d0,
altdest=0x35b36d0, completionTag=0x7fff10224440 ) at pquery.c:1150
#16 0x00588b74 in PortalRun (portal=0x35f63e0,
count=9223372036854775807, dest=0x35b36d0, altdest=0x35b36d0,
completionTag=0x7fff10224440 ) at pquery.c:700
#17 0x00584a9f in exec_simple_query (
query_string=0x35b2650 INSERT INTO user_attribute_vectors
(\client_id\, \survey_id\, \user_id\, \attribute_vector\) VALUES(1,
1, 9180,
E'(0.924332429795696,0.568812924744321,0.568812924744321,-0.599309532325997,
-1.462648746...) at postgres.c:939
#18 0x00585f22 in PostgresMain (argc=4, argv=value optimized out,
username=0x35396f0 signalmatch-production) at postgres.c:3424
#19 0x0055f1c7 in ServerLoop () at postmaster.c:2934
#20 0x0055fdda in PostmasterMain (argc=5, argv=0x3519bb0) at
postmaster.c:966
#21 0x005208e3 in main (argc=5, argv=value optimized out) at
main.c:188
(gdb)
And more information about the table:
sp_hub_production=# select count(*) from user_attribute_vectors;
count
---
6057
(1 row)
sp_hub_production=# \d user_attribute_vectors
Table public.user_attribute_vectors
Column | Type | Modifiers
--+-+---
--
id | integer | not null default
nextval('user_attribute_vectors_id_seq'::regclass)
user_id | integer |
client_id| integer |
survey_id| integer |
attribute_vector | cube|
Indexes:
user_attribute_vectors_pkey PRIMARY KEY, btree (id)
index_user_attribute_vectors_on_attribute_vector_gist gist
(attribute_vector)
index_user_attribute_vectors_on_user_id btree (user_id)
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #4186: set lc_messages does not work
Magnus Hagander [EMAIL PROTECTED] writes: Thomas H. wrote: so at least that explains the changed behaviour. nevertheless, LC_MESSAGES seems to be defunct - with the locale folder present, pg always picks the os' language and ignores the lc_message value. This looks like I can reproduce though, at least on cvs head. Did this work for you in previous versions? Maybe we were using a different build of gettext in the previous releases, one that didn't look at the same info as the current code? Anyway the patch mentioned at the start of the thread http://archives.postgresql.org/pgsql-patches/2008-02/msg00038.php purports to fix this. It doesn't seem to have gotten reviewed though. regards, tom lane -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #4208: Server crashes on insert into gist index
Ron Mackley [EMAIL PROTECTED] writes: We've been seeing infrequent crashes of the postgres. This is version 8.2.6 running on Red Hat Enterprise 5.1 on x64 using redhat issued RPMs. We captured a core file and here is the stack trace: (gdb) bt #0 0x00615b5a in pfree (pointer=0x2aaaccaff318) at mcxt.c:585 #1 0x2aaace72ab59 in cube_inter (fcinfo=0x7fff102205f0) at cube.c:898 #2 0x00602b14 in DirectFunctionCall2 (func=0x2aaace72aa00 cube_inter, arg1=46913066890008, arg2=5) at fmgr.c:888 #3 0x2aaace72a73b in g_cube_picksplit (fcinfo=value optimized out) at cube.c:571 Hmmm ... just looking at the code, I bet what is happening is that the swap path in cube_inter is taken, and then the comparisons in PG_FREE_IF_COPY get confused and try to pfree values that were not separately allocated. But if that's the story, why does cube_inter not show a crash rate approaching 50%? Maybe most people only use it on cubes of the same dimensionality. Does your gist index contain cubes of varying numbers of dimensions? regards, tom lane -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #4208: Server crashes on insert into gist index
Tom, Thanks for the quick response. No: sp_hub_production=# select distinct cube_dim(attribute_vector) from user_attribute_vectors; cube_dim -- 5 (1 row) In the past we had a problem where runt vectors found their way into the table, but we deleted them and try to detect them on their way in. This happened once before and then stopped. That's when we started capturing core files. I suspect that it happens when our user base grows enough to force a split on insert with just the right record. We will probably see a fallow period and it will happen again after we get another couple thousand users. Ron Ron Mackley Manager, Software Development Signal Patterns [EMAIL PROTECTED] == The information contained in this email message may be privileged, confidential and protected from disclosure. If you are not the intended recipient, any distribution or copying is strictly prohibited. If you think that you have received this email message in error, please notify the sender by reply email and delete the message and any attachments. On 29 May 2008, at 10:54 AM, Tom Lane wrote: Ron Mackley [EMAIL PROTECTED] writes: We've been seeing infrequent crashes of the postgres. This is version 8.2.6 running on Red Hat Enterprise 5.1 on x64 using redhat issued RPMs. We captured a core file and here is the stack trace: (gdb) bt #0 0x00615b5a in pfree (pointer=0x2aaaccaff318) at mcxt.c: 585 #1 0x2aaace72ab59 in cube_inter (fcinfo=0x7fff102205f0) at cube.c:898 #2 0x00602b14 in DirectFunctionCall2 (func=0x2aaace72aa00 cube_inter, arg1=46913066890008, arg2=5) at fmgr.c:888 #3 0x2aaace72a73b in g_cube_picksplit (fcinfo=value optimized out) at cube.c:571 Hmmm ... just looking at the code, I bet what is happening is that the swap path in cube_inter is taken, and then the comparisons in PG_FREE_IF_COPY get confused and try to pfree values that were not separately allocated. But if that's the story, why does cube_inter not show a crash rate approaching 50%? Maybe most people only use it on cubes of the same dimensionality. Does your gist index contain cubes of varying numbers of dimensions? regards, tom lane -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #4208: Server crashes on insert into gist index
Ron Mackley [EMAIL PROTECTED] writes: Thanks for the quick response. No: sp_hub_production=# select distinct cube_dim(attribute_vector) from user_attribute_vectors; cube_dim -- 5 (1 row) In the past we had a problem where runt vectors found their way into the table, but we deleted them and try to detect them on their way in. Well, if there were such entries in the past then they could still exist in the index, I believe. One or two such keys lurking in dusty corners of the index would fit with the observed fact that you don't see the crash often. As a workaround, it'd probably be worth your trouble to REINDEX that index to get rid of any such entries. In any case, the swap bug is definitely real; for instance in cube's regression database try this: contrib_regression=# select cube_inter(c,'(1,2,3,4,5,6)') from test_cube; server closed the connection unexpectedly This probably means the server terminated abnormally before or while processing the request. I will go fix that ... regards, tom lane -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
[BUGS] BUG #4209: openSSL undefined symbols.
The following bug has been logged online: Bug reference: 4209 Logged by: Andrew SG Rojek Email address: [EMAIL PROTECTED] PostgreSQL version: 8.3.1 Operating system: OSX 10.5.2 Description:openSSL undefined symbols. Details: Make produced the following error messages: Undefined symbols: _SSL_write, referenced from: _SOCK_SSL_send in socket.o _SSL_get_error, referenced from: _SOCK_SSL_send in socket.o _SOCK_get_next_byte in socket.o _SSL_read, referenced from: _SOCK_get_next_byte in socket.o ld: symbol(s) not found collect2: ld returned 1 exit status make[1]: *** [psqlodbcw.la] Error 1 make: *** [all] Error 2 The following options were disabled in ./configure: --without-unixodbc --without-iodbc when the error was produced. However adding: --disable-openssl to ./configure resolves the problem but it would be preferable to build with SSL support. Is this an OSX problem with either the linker or libtool as these type of error messages seem to be a regular occurence. A. -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
[BUGS] BUG #4210: signedness of pointer targets
The following bug has been logged online: Bug reference: 4210 Logged by: Andrew SG Rojek Email address: [EMAIL PROTECTED] PostgreSQL version: 8.3.1 Operating system: OSX 10.5.2 Description:signedness of pointer targets Details: Whilst making psqlodbc-08.03.0200, make reported a large number of warnings relating to the signedness of pointers: pointer targets in assignment differ in signedness pointer targets in passing argument 2 of ... differ in signedness ... for a number of files. Is this something to be concerned about or will ODBC function reliably? -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #4209: openSSL undefined symbols.
Andrew SG Rojek [EMAIL PROTECTED] writes: Make produced the following error messages: Undefined symbols: _SSL_write, referenced from: _SOCK_SSL_send in socket.o _SSL_get_error, referenced from: _SOCK_SSL_send in socket.o _SOCK_get_next_byte in socket.o _SSL_read, referenced from: _SOCK_get_next_byte in socket.o ld: symbol(s) not found collect2: ld returned 1 exit status make[1]: *** [psqlodbcw.la] Error 1 make: *** [all] Error 2 Note for the archives that this appears to be a complaint against some unspecified version of the ODBC driver, not Postgres proper. regards, tom lane -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
[BUGS] some problem when installing postgresql
hey: I am the new one to use PostgreSql, when I install the MoteView including postgresql and postgresqlODBC and so on, I met a problem about PostgreSql installation, it shew that Failed to set permissions on the installed files. Please see the logfile in C:\Program Files\PostgreSql\8.0.0-rc 1\tmp\pgperm.log. in the pgperm.log, it says that No mapping between account names and security IDs was done.. I dont know what is problem? would you like to give me some idea on it? Thanks! Sincerely; Maggie
