[HACKERS] pg_dump -Ft failed on Windows XP
Hi, I got the following message when I ran pg_dump with -Ft option on Windows XP. > pg_dump -V pg_dump (PostgreSQL) 8.1.2 > pg_dump -Ft test > C:\backup\xxx.out pg_dump: [tar archiver] could not generate temporary file name: Permission denied pg_dump calls tmpfile() in pg_backup_tar.c:tarOpen(). Win32's tmpfile() creates the file into root folder. But non-administrator users can't create files into root folder. So, I think it fails that non-administrator users run pg_dump with -Ft option. Regards, -- Yoshiyuki Asaba [EMAIL PROTECTED] ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] phpPgAdmin looking for developers
Oooh. Based on emails I've received I should point out that phpPgAdmin is a FREE, VOLUNTEER project! It's not a paid job offer! Christopher Kings-Lynne wrote: Hi, The phpPgAdmin project has been pretty quiet for some time now. We have decided to try to build up our developer base again by recruiting some new, interested, PHP developers. The core team is still around to offer guidance, suggestions, releases, etc. however no-one seems to have much time to code anymore. If you are keen to work on a well-designed open-source PHP application, and expand your knowledge of PostgreSQL, please contact me and I'll find something for you to get started with. Regards, Chris Kings-Lynne phpPgAdmin Project Lead ---(end of broadcast)--- TIP 6: explain analyze is your friend -- Christopher Kings-Lynne Technical Manager CalorieKing Tel: +618.9389.8777 Fax: +618.9389.8444 [EMAIL PROTECTED] www.calorieking.com ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
[HACKERS] parser error when trying to connect to postges db from tomcat
Hi, Im getting this error when I try to connect to a postgresql database from a web application running on tomcat the error is from the postgersql logs ERROR: No parser with id 17555 The error below is from tomcat logs: --- (executing StatementCallback): encountered SQLException [ERROR: No parser with id 17555]; nested exception is org.postgresql.util.PSQLException: ERROR: No parser with id 17555 --- Please advise...Iv been trying to find an answer for a long time Thanks -- Danish Siddiqui ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
[HACKERS] phpPgAdmin looking for developers
Hi, The phpPgAdmin project has been pretty quiet for some time now. We have decided to try to build up our developer base again by recruiting some new, interested, PHP developers. The core team is still around to offer guidance, suggestions, releases, etc. however no-one seems to have much time to code anymore. If you are keen to work on a well-designed open-source PHP application, and expand your knowledge of PostgreSQL, please contact me and I'll find something for you to get started with. Regards, Chris Kings-Lynne phpPgAdmin Project Lead ---(end of broadcast)--- TIP 6: explain analyze is your friend
[HACKERS] Triage Coverity
I spent some time today going through the stuff on the Coverity website. I basically looked at every report outside of src/backend (due to the ereport false-positives (elog is fixed)) and src/interfaces/ecpg (due to the shear volume of probably bugs). I've sorted them into: FALSE - Not a bug, Coverity just not being smart IGNORE - Yeah, it's a bug but not worth fixing PENDING - Simple bug, easy fix or more important Especially the src/bin directory, there's a lot of resource leakage and my impression is that we knew that already and most of them just arn't worth the effort to fix. I've only marked the ones that could be fixed with a well placed free(). Also, libpq and psql got higher priority. So if anyone wants to spend time fixing lots of little buglets, now's your chance. Have a nice day, -- Martijn van Oosterhout http://svana.org/kleptog/ > From each according to his ability. To each according to his ability to > litigate. signature.asc Description: Digital signature
Re: [HACKERS] Strange results from to_timestamp
Attachment now attached. :-)
---
Bruce Momjian wrote:
>
> Interesting bug report. The problem is that sscanf(buf, "%d", &val)
> eats leading white space, but our functions were not handling that.
>
> I have applied the attached patch that fixes this:
>
> test=> select to_timestamp(' 0300','mmdd hh24mi');
> to_timestamp
>
>0300-01-01 00:00:00-05
> (1 row)
>
> test=> select to_timestamp(' 030004','mmdd hh24mi');
> to_timestamp
>
>0300-04-01 00:00:00-05
> (1 row)
>
> test=> select to_timestamp(' 040004','mmdd hh24mi');
> to_timestamp
>
>0400-04-01 00:00:00-05
> (1 row)
>
> It doesn't throw an error for too mamy format strings, but it does avoid
> the incorrect values. The fix will appear in 8.2.
>
> ---
>
> Mario Weilguni wrote:
> > mydb=# select to_timestamp(' 0300','mmdd hh24mi');
> >to_timestamp
> > ---
> > 0001-01-01 03:00:00+01 BC
> > (1 row)
> >
> > Questionable, but probably valid.
> >
> >
> >
> > mydb=# select to_timestamp(' 0300','mmdd hh24mi');
> > to_timestamp
> >
> > 0300-12-25 03:00:00+01
> > (1 row)
> >
> > This puzzles me. Where is the 25th of december coming from?
> >
> >
> >
> > mydb=# select to_timestamp(' 030004','mmdd hh24mi');
> > to_timestamp
> >
> > 0382-04-23 03:00:00+01
> > (1 row)
> >
> > Same as above.
> >
> >
> > mydb=# select to_timestamp(' 040004','mmdd hh24mi');
> > to_timestamp
> >
> > 0509-10-10 04:00:00+01
> >
> >
> > I think all except the first one should raise a warning, isn't it? Where
> > can I
> > find the source code of this function?
> >
> > Best regards,
> > Mario Weilguni
> >
> >
> > ---(end of broadcast)---
> > TIP 9: In versions below 8.0, the planner will ignore your desire to
> >choose an index scan if your joining column's datatypes do not
> >match
> >
>
> --
> Bruce Momjian http://candle.pha.pa.us
> EnterpriseDBhttp://www.enterprisedb.com
>
> + If your life is a hard drive, Christ can be your backup. +
>
> ---(end of broadcast)---
> TIP 9: In versions below 8.0, the planner will ignore your desire to
>choose an index scan if your joining column's datatypes do not
>match
>
--
Bruce Momjian http://candle.pha.pa.us
EnterpriseDBhttp://www.enterprisedb.com
+ If your life is a hard drive, Christ can be your backup. +
Index: src/backend/utils/adt/formatting.c
===
RCS file: /cvsroot/pgsql/src/backend/utils/adt/formatting.c,v
retrieving revision 1.109
diff -c -c -r1.109 formatting.c
*** src/backend/utils/adt/formatting.c 19 Apr 2006 14:48:06 - 1.109
--- src/backend/utils/adt/formatting.c 19 Apr 2006 16:07:35 -
***
*** 917,922
--- 917,923
static char *get_th(char *num, int type);
static char *str_numth(char *dest, char *num, int type);
+ static intstrspace_len(char *str);
static intstrdigits_len(char *str);
static char *str_toupper(char *buff);
static char *str_tolower(char *buff);
***
*** 1687,1697
}
static int
strdigits_len(char *str)
{
char *p = str;
! int len = 0;
while (*p && isdigit((unsigned char) *p) && len <= DCH_MAX_ITEM_SIZ)
{
len++;
--- 1688,1714
}
static int
+ strspace_len(char *str)
+ {
+ int len = 0;
+
+ while (*str && isspace((unsigned char) *str))
+ {
+ str++;
+ len++;
+ }
+ return len;
+ }
+
+ static int
strdigits_len(char *str)
{
char *p = str;
! int len;
+ len = strspace_len(str);
+ p += len;
+
while (*p && isdigit((unsigned char) *p) && len <= DCH_MAX_ITEM_SIZ)
{
len++;
***
*** 1826,1832
else
{
sscanf(inout, "%02d", &tmfc->hh);
! return 2 + SKIP_THth(suf);
}
}
break;
--- 1843,1849
else
{
sscanf(inout, "%02d", &tmfc->hh);
!
Re: [HACKERS] Strange results from to_timestamp
Interesting bug report. The problem is that sscanf(buf, "%d", &val)
eats leading white space, but our functions were not handling that.
I have applied the attached patch that fixes this:
test=> select to_timestamp(' 0300','mmdd hh24mi');
to_timestamp
0300-01-01 00:00:00-05
(1 row)
test=> select to_timestamp(' 030004','mmdd hh24mi');
to_timestamp
0300-04-01 00:00:00-05
(1 row)
test=> select to_timestamp(' 040004','mmdd hh24mi');
to_timestamp
0400-04-01 00:00:00-05
(1 row)
It doesn't throw an error for too mamy format strings, but it does avoid
the incorrect values. The fix will appear in 8.2.
---
Mario Weilguni wrote:
> mydb=# select to_timestamp(' 0300','mmdd hh24mi');
>to_timestamp
> ---
> 0001-01-01 03:00:00+01 BC
> (1 row)
>
> Questionable, but probably valid.
>
>
>
> mydb=# select to_timestamp(' 0300','mmdd hh24mi');
> to_timestamp
>
> 0300-12-25 03:00:00+01
> (1 row)
>
> This puzzles me. Where is the 25th of december coming from?
>
>
>
> mydb=# select to_timestamp(' 030004','mmdd hh24mi');
> to_timestamp
>
> 0382-04-23 03:00:00+01
> (1 row)
>
> Same as above.
>
>
> mydb=# select to_timestamp(' 040004','mmdd hh24mi');
> to_timestamp
>
> 0509-10-10 04:00:00+01
>
>
> I think all except the first one should raise a warning, isn't it? Where can
> I
> find the source code of this function?
>
> Best regards,
> Mario Weilguni
>
>
> ---(end of broadcast)---
> TIP 9: In versions below 8.0, the planner will ignore your desire to
>choose an index scan if your joining column's datatypes do not
>match
>
--
Bruce Momjian http://candle.pha.pa.us
EnterpriseDBhttp://www.enterprisedb.com
+ If your life is a hard drive, Christ can be your backup. +
---(end of broadcast)---
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match
Re: [HACKERS] Who is responsible for ECPG?
Martijn van Oosterhout writes: > I'm wondering who is responsible for ECPG since there appear to be a > number questionable statements which may or may not be bugs. Do we have > a resident expert? Michael Meskes is The Man as far as ecpg goes ... regards, tom lane ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
[HACKERS] Who is responsible for ECPG?
I'm wondering who is responsible for ECPG since there appear to be a number questionable statements which may or may not be bugs. Do we have a resident expert? Examples: src/interfaces/ecpg/ecpglib/execute.c line 871 To my untrained eye it looks like after the first time through the loop it's going to double-free nval. src/interfaces/ecpg/pgtypeslib/numeric.c line 364 A numeric is allocated but leaked if set_var_from_str fails. src/interfaces/ecpg/compatlib/informix.c line 169 Again, memory leak if risnull fails Yes, these are from the coverity report. Who knows enough about ECPG to decide what's a real bug and what's just bad assumptions? -- Martijn van Oosterhout http://svana.org/kleptog/ > From each according to his ability. To each according to his ability to > litigate. signature.asc Description: Digital signature
Re: [HACKERS] Google SoC--Idea Request
Joshua D. Drake wrote: > John DeSoi wrote: > >Proposed item: Improve PL/PHP support, especially installation on > >non-Linux platforms. PL/PHP does not currently work on OS X (not sure > >about Windows, but I doubt it). > > It definitely does NOT work on Windows. MacOSX is just a matter of us > having some time. > > >Alvaro indicated he would be willing to provide direction on this with > >testing support from me. He also said there are several other possible > >PL/PHP issues that would warrant a SoC project. > > Well my number one issue is the build process which needs to be cleaned > up but there are other more technical issues to be resolved as well. Yeah, there are also a number of possible improvements documented as tickets in the Trac site and others that currently exist only as very vague noise in my head. -- Alvaro Herrerahttp://www.CommandPrompt.com/ The PostgreSQL Company - Command Prompt, Inc. ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] Google SoC--Idea Request
John DeSoi wrote: Proposed item: Improve PL/PHP support, especially installation on non-Linux platforms. PL/PHP does not currently work on OS X (not sure about Windows, but I doubt it). It definitely does NOT work on Windows. MacOSX is just a matter of us having some time. Alvaro indicated he would be willing to provide direction on this with testing support from me. He also said there are several other possible PL/PHP issues that would warrant a SoC project. Well my number one issue is the build process which needs to be cleaned up but there are other more technical issues to be resolved as well. Joshua D. Drake John DeSoi, Ph.D. http://pgedit.com/ Power Tools for PostgreSQL ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq -- === The PostgreSQL Company: Command Prompt, Inc. === Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240 Providing the most comprehensive PostgreSQL solutions since 1997 http://www.commandprompt.com/ ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Google SoC--Idea Request
On 4/19/06, John DeSoi <[EMAIL PROTECTED]> wrote: > Alvaro indicated he would be willing to provide direction on this > with testing support from me. He also said there are several other > possible PL/PHP issues that would warrant a SoC project. Cool... let's get 'em all listed here so we can move forward. -- Jonah H. Harris, Database Internals Architect EnterpriseDB Corporation 732.331.1324 ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] Google SoC--Idea Request
Proposed item: Improve PL/PHP support, especially installation on non- Linux platforms. PL/PHP does not currently work on OS X (not sure about Windows, but I doubt it). Alvaro indicated he would be willing to provide direction on this with testing support from me. He also said there are several other possible PL/PHP issues that would warrant a SoC project. John DeSoi, Ph.D. http://pgedit.com/ Power Tools for PostgreSQL ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] how can i get the binary format of timestamp?
"[EMAIL PROTECTED]" <[EMAIL PROTECTED]> writes:
> if define HAVE_INT64_TIMESTAMP
> result is: 4E66 E642 0030 C274
> if not define HAVE_INT64_TIMESTAMP
> {
> if define INT64_IS_BUSTED result is: 6972 2142 00DB
> if not define INT64_IS_BUSTED result is: 4221 7269 DB00
> }
I think you got your cases mixed up. In the not-HAVE_INT64_TIMESTAMP
case the value would be a float8 and wouldn't be affected at all by
INT64_IS_BUSTED.
Defining both HAVE_INT64_TIMESTAMP and INT64_IS_BUSTED is not supported.
regards, tom lane
---(end of broadcast)---
TIP 3: Have you checked our extensive FAQ?
http://www.postgresql.org/docs/faq
Re: [HACKERS] concurrent transactions inside the same connection
On Wed, Apr 19, 2006 at 12:31:23PM +0300, Adrian Maier wrote: > Hello hackers, > > I have included below a fragment of a discussion from the freepascal mailing > list. Apparently, some folks expect to be able to start multiple transactions > inside the *same* database connection. Since this is not possible in postgres, > they would be forced to start more connections from the same application. > > Is such a feature possible to be implemented someday ? It's not clear what the use case is. Given the original problem was excised from the email it's not clear what they're trying to solve. Transactions can "nest", sort of. > My feeling is that this is a false problem, caused by some interbase/firebird > or delphi habits . But ... the poster claims that Oracle and SqlServer > have such a feature ( Oracle has 'named' transactions - but these > names seem to be just labels ) - is this true ? I beleive oracle can have independant subtransactions. That's something different from several concurrent transaction though. I'm not oracle expert though. Have a nice day, -- Martijn van Oosterhout http://svana.org/kleptog/ > From each according to his ability. To each according to his ability to > litigate. signature.asc Description: Digital signature
Re: [HACKERS] concurrent transactions inside the same connection
> I have included below a fragment of a discussion from the freepascal mailing > list. Apparently, some folks expect to be able to start multiple transactions [...] > inside the *same* database connection. > > My feeling is that this is a false problem, caused by some interbase/firebird > or delphi habits . But ... the poster claims that Oracle and SqlServer > have such a feature ( Oracle has 'named' transactions - but these > names seem to be just labels ) - is this true ? I can only speak for Oracle: Transaction names are just labels, that is correct. There is, however, something called an 'autonomous transaction' in PL/SQL stored procedures and triggers. A stored procedure can start a new transaction, independent from the current context. Once you return from the stored procedure, the old transaction is resumed. Yours, Laurenz Albe ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
[HACKERS] concurrent transactions inside the same connection
Hello hackers, I have included below a fragment of a discussion from the freepascal mailing list. Apparently, some folks expect to be able to start multiple transactions inside the *same* database connection. Since this is not possible in postgres, they would be forced to start more connections from the same application. Is such a feature possible to be implemented someday ? My feeling is that this is a false problem, caused by some interbase/firebird or delphi habits . But ... the poster claims that Oracle and SqlServer have such a feature ( Oracle has 'named' transactions - but these names seem to be just labels ) - is this true ? Best wishes, Adrian Maier -- Forwarded message -- From: Michael Van Canneyt <[EMAIL PROTECTED]> Subject: Re: [lazarus] FPC question To: lazarus@miraclec.com On Wed, 19 Apr 2006, Adrian Maier wrote: > On 4/19/06, Joost van der Sluis <[EMAIL PROTECTED]> wrote: >>> Is this a problem with PostgreSQL itself or the component in lazarus >>> wrapping it? >> >> It's a problem of postgres. A transaction 'block' is started with the >> sql-command 'begin', from that comand on, all queries are executed >> within that transaction. Using another connection is not possible. >> Unless, offcourse, you start a new connection. Or closes the transaction >> (commit, rollback etc) > > Please pardon me for jumping in the middle of the thread, but your > phrase made me really curious. The behaviour you described seems > to be the normal one, once you execute "begin" (transaction) . What > other behaviour would someone expect postgres to have ? To allow several concurrent transactions. Interbase/Firebird allows to start several concurrent transactions in 1 connection. AFAIK Oracle and MS-SQL too (named transactions). This is extremely handy. Michael. ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] Question on win32 semaphore simulation
> > (2) the killer function is PGSemaphoreReset(). There is no direct > > function for this in Win32 either. > > If you can do PGSemaphoreTryLock, then Reset need only be a > loop around it (cf. posix_sema.c). In current usage Reset > doesn't have to be very efficient at all, because it's only > used during backend startup to bring the semaphore to a known state. > > > (1) semctl(SETVAL, val=0) - there is no other "val" than > zero is used; > > Really? Better look again. > > If you think the SysV interface is baroque (which I don't > disagree with), then you should just get rid of it entirely > and implement pg_sema.h directly atop the Windows primitives. > I don't have a lot of sympathy for "let's implement just > part of SysV because I don't like that other part". There is > no contract saying that sysv_sema.c might not start using > SysV features it doesn't use today. That's what I was thinking when I said "option 3". It shouldn't be *too* hard, and much cleaner. //Magnus ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
