Re: [HACKERS] PGPASSWORD and client tools
Please ignore- seems some old mail of mine got sent waaay late... Christopher Kings-Lynne wrote: While fixing the gui for pg_dump and pg_restore, I painfully noticed there's no option for the password. After some tests, I found that using the PGPASSWORD environment variable will do the job. I'm a bit irritated that it's marked "deprecated" in the docs, the .pgpass solution isn't a good one for tool managed passwords. Hopefully PGPASSWORD won't vanish until there's another solution to execute pgsql client tools... Regards, Andreas ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED] ---(end of broadcast)--- TIP 8: explain analyze is your friend ---(end of broadcast)--- TIP 3: 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] [JDBC] Strange server error with current 8.0beta driver
Tom, Your patch works for my test cases. Thanks to both you and Oliver for getting this fixed. --Barry -Original Message- From: Tom Lane [mailto:[EMAIL PROTECTED] Sent: Sunday, November 28, 2004 2:23 PM To: Oliver Jowett Cc: Barry Lind; [EMAIL PROTECTED] Subject: Re: [HACKERS] [JDBC] Strange server error with current 8.0beta driver Oliver Jowett <[EMAIL PROTECTED]> writes: >> Perhaps PerformCursorOpen should copy the query tree before planning, >> or plan in a different memory context? > Patch attached. It moves query planning inside the new portal's memory > context. With this applied I can run Barry's testcase without errors, > and valgrind seems OK with it too. I think the better solution is the first way (copy the querytree first). The problem with the way you did it is that all the temporary structures built by the planner will be left behind in the cursor's memory context, and can't be reclaimed until the cursor is destroyed. In the case of a complex query that could represent a pretty serious memory leak. It seems better to eat the cost of copying the querytree an extra time, especially since this way forms a patch that's easy to reverse whenever we fix the planner to be less cavalier about scribbling on its input. I've applied the attached patch instead (and analogously in 7.4 branch). Would you confirm it fixes the problem you see? regards, tom lane *** src/backend/commands/portalcmds.c.orig Thu Sep 16 12:58:28 2004 --- src/backend/commands/portalcmds.c Sun Nov 28 17:02:22 2004 *** *** 62,73 RequireTransactionChain((void *) stmt, "DECLARE CURSOR"); /* * The query has been through parse analysis, but not rewriting or * planning as yet. Note that the grammar ensured we have a SELECT * query, so we are not expecting rule rewriting to do anything * strange. */ ! rewritten = QueryRewrite((Query *) stmt->query); if (list_length(rewritten) != 1 || !IsA(linitial(rewritten), Query)) elog(ERROR, "unexpected rewrite result"); query = (Query *) linitial(rewritten); --- 62,82 RequireTransactionChain((void *) stmt, "DECLARE CURSOR"); /* +* Because the planner is not cool about not scribbling on its input, +* we make a preliminary copy of the source querytree. This prevents +* problems in the case that the DECLARE CURSOR is in a portal and is +* executed repeatedly. XXX the planner really shouldn't modify its +* input ... FIXME someday. +*/ + query = copyObject(stmt->query); + + /* * The query has been through parse analysis, but not rewriting or * planning as yet. Note that the grammar ensured we have a SELECT * query, so we are not expecting rule rewriting to do anything * strange. */ ! rewritten = QueryRewrite(query); if (list_length(rewritten) != 1 || !IsA(linitial(rewritten), Query)) elog(ERROR, "unexpected rewrite result"); query = (Query *) linitial(rewritten); ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [HACKERS] PGPASSWORD and client tools
While fixing the gui for pg_dump and pg_restore, I painfully noticed there's no option for the password. After some tests, I found that using the PGPASSWORD environment variable will do the job. I'm a bit irritated that it's marked "deprecated" in the docs, the .pgpass solution isn't a good one for tool managed passwords. Hopefully PGPASSWORD won't vanish until there's another solution to execute pgsql client tools... Regards, Andreas ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED] ---(end of broadcast)--- TIP 8: explain analyze is your friend
[HACKERS] beta5 rpms
In case anyone is interested, I've posted 8.0.0beta5 rpms here: http://www.joeconway.com/postgresql-8.0.0beta/ Note that these are not "official" PGDG rpms, just my own home brew. Also note that there is talk of an imminent RC1 -- hopefully I'll find time to update the rpms within a day or so after that release. Joe ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] 8.0RC1 tomorrow
Tom Lane wrote: > Mike Mascari <[EMAIL PROTECTED]> writes: > > Will ANALYZE continue to ignore columns whose data is composed entirely > > of NULL in 8.0? > > I had hoped to get to this before RC, but it looks like it won't happen. > Considering I've just been beating up on Bruce for committing stuff that > wasn't clearly a bug fix, I can't really do anything about it now ;-) TODO item? -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] 8.0RC1 tomorrow
Mike Mascari <[EMAIL PROTECTED]> writes: > Will ANALYZE continue to ignore columns whose data is composed entirely > of NULL in 8.0? I had hoped to get to this before RC, but it looks like it won't happen. Considering I've just been beating up on Bruce for committing stuff that wasn't clearly a bug fix, I can't really do anything about it now ;-) regards, tom lane ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] 7.4.6 build failures on Solaris 9 with Sun cc
On Fri, 3 Dec 2004 01:43 pm, Michael Fuhr wrote: > gcc 3.4.2 on Solaris 9 doesn't complain about this. Yes, I found Tom's response to the issue from March here: http://archives.postgresql.org/pgsql-ports/2004-03/msg9.php and this on the Sun CC forum, confirming that the compiler is borked: http://forum.sun.com/thread.jspa?threadID=20947&tstart=0 It'd be handy if they said what ID the bug had been assigned so I knew what patch to download to fix it. I'll post the info once I can find it so there's a simple "Apply patch #" answer in future. I ended up building with gcc 3.4.0, no problem. Thanks for following up. Regards, Philip. ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
Re: [HACKERS] 7.4.6 build failures on Solaris 9 with Sun cc
On Fri, Dec 03, 2004 at 11:31:19AM +1100, Philip Yarra wrote: > Hi all, before I delve too deeply into this, has anyone else tried building > 7.4.6 on Solaris 9 (sparc) ? I'm seeing build failures using Sun's cc: > > make[4]: Entering directory `/tmp/postgresql-7.4.6/src/backend/access/heap' > cc -Xa -O -v -I../../../../src/include -c -o tuptoaster.o tuptoaster.c > "tuptoaster.c", line 831: member can not have variably modified type: data > "tuptoaster.c", line 937: cannot recover from previous errors > cc: acomp failed for tuptoaster.c gcc 3.4.2 on Solaris 9 doesn't complain about this. -- Michael Fuhr http://www.fuhr.org/~mfuhr/ ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
[HACKERS] Who's in charge of torrents? [was: Easy way to download all .torrents]
I've tried emailling David Fetter to no avail; anyone know who's in charge of the torrents or anyone who can answer my original question? - Forwarded message from "Jim C. Nasby" <[EMAIL PROTECTED]> - Date: Tue, 23 Nov 2004 15:52:15 -0600 From: "Jim C. Nasby" <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] Subject: [HACKERS] Easy way to download all .torrents For a while I've been keeping a bittorrent client running with some of the common postgresql torrents that are available, but grabbing the .torrent files is a bit of a pain. Is there an easy way to download all of the appropriate .torrent files that are available? -- Jim C. Nasby, Database Consultant [EMAIL PROTECTED] Give your computer some brain candy! www.distributed.net Team #1828 Windows: "Where do you want to go today?" Linux: "Where do you want to go tomorrow?" FreeBSD: "Are you guys coming, or what?" ---(end of broadcast)--- TIP 8: explain analyze is your friend - End forwarded message - -- Jim C. Nasby, Database Consultant [EMAIL PROTECTED] Give your computer some brain candy! www.distributed.net Team #1828 Windows: "Where do you want to go today?" Linux: "Where do you want to go tomorrow?" FreeBSD: "Are you guys coming, or what?" ---(end of broadcast)--- TIP 3: 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] lwlocks and starvation
Neil Conway wrote: > On Thu, 2004-12-02 at 09:59 -0500, Bruce Momjian wrote: > > OK, either you have to own the issue or I have to add something to the > > TODO list. > > Can you add it to the TODO list and assign it to me? > Done: * Fix priority ordering of read and write light-weight locks (Neil) -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
Re: [HACKERS] lwlocks and starvation
On Thu, 2004-12-02 at 09:59 -0500, Bruce Momjian wrote: > OK, either you have to own the issue or I have to add something to the > TODO list. Can you add it to the TODO list and assign it to me? -Neil ---(end of broadcast)--- TIP 3: 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] nodeAgg perf tweak
On Thu, 2004-12-02 at 20:51 -0500, Tom Lane wrote: > No. The current code involves two pallocs per cycle, one inside the > aggregate function to construct its result value, and then one in > datumCopy to copy the result into the proper context. Ah, true -- missed the fact that PG_RETURN_INT64() does a palloc(). (We really ought to fix that on 64-bit machines...) > The fact that it's a central fix for all aggregate functions is > definitely a nice feature of your approach, but I am concerned about the > possible side-effects on user-defined aggregate functions that may not > work as you expect them to. I think it's safer to keep the aggregate > code behaving as-is and get the performance win in the individual > functions. There are not that many aggregates that we really care that > much about. Okay, fair enough :) BTW, the spec you posted in your previous message makes sense to me. -Neil ---(end of broadcast)--- TIP 3: 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] Code documentation
Great. Documentation of the source code helps many developers become more productive. --- Gevik Babakhani wrote: > I think the basis in understanding how PostgreSQL works depends > on the documentation to certain extend and the level of one's programming > and database knowledge of course. > > At this moment I am gathering information from anywhere I can get a hold > of regarding PostgresSQL. > > I have requested a repository at pgFoundry called "Postgres Knowledge Base" > I am planning to gather/write FAQ,HOW TO and KB articles. > > About the higher-level documentation of how the internals, it would be great > > if anyone could send me links, white papers, whatever documentation you > think it is > important. > > I also would like to know if anyone would be interested to have an online > browsable version > of source code? This can easily be done by doxygen to some acceptable level. > > Regards, > Gevik. > > > -Original Message- > From: Neil Conway [mailto:[EMAIL PROTECTED] > Sent: Friday, December 03, 2004 2:19 AM > To: Gevik Babakhani > Cc: pgsql-hackers > Subject: Re: [HACKERS] Code documentation > > On Thu, 2004-12-02 at 10:58 +0100, Gevik Babakhani wrote: > > I was wondering if there are any interests or plans for documenting > > various functions in the code which currently are not documented. > > I don't know of any systematic effort to do this. I try to document > undocumented code as necessary while making related changes, and I would > imagine other developers do the same. > > > I would like to start this discussion to see if we want to do this. > > It sounds like a good idea to me. Feel free to submit documentation patches > to the -patches list. > > Another area where we could stand to do better is in higher-level > documentation of how the internals of the system work. For example, > something like the Postgres95 Implementation Guide: > > http://pluto.iis.nsk.su/postgres95/impl-guide/ > > but more complete, and up-to-date. There is some documentation in this vein > (such as the README files for specific subsystems), but IMHO we could do > with more. > > -Neil > > > > > ---(end of broadcast)--- > TIP 9: 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 [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [HACKERS] Code documentation
I think the basis in understanding how PostgreSQL works depends on the documentation to certain extend and the level of one's programming and database knowledge of course. At this moment I am gathering information from anywhere I can get a hold of regarding PostgresSQL. I have requested a repository at pgFoundry called "Postgres Knowledge Base" I am planning to gather/write FAQ,HOW TO and KB articles. About the higher-level documentation of how the internals, it would be great if anyone could send me links, white papers, whatever documentation you think it is important. I also would like to know if anyone would be interested to have an online browsable version of source code? This can easily be done by doxygen to some acceptable level. Regards, Gevik. -Original Message- From: Neil Conway [mailto:[EMAIL PROTECTED] Sent: Friday, December 03, 2004 2:19 AM To: Gevik Babakhani Cc: pgsql-hackers Subject: Re: [HACKERS] Code documentation On Thu, 2004-12-02 at 10:58 +0100, Gevik Babakhani wrote: > I was wondering if there are any interests or plans for documenting > various functions in the code which currently are not documented. I don't know of any systematic effort to do this. I try to document undocumented code as necessary while making related changes, and I would imagine other developers do the same. > I would like to start this discussion to see if we want to do this. It sounds like a good idea to me. Feel free to submit documentation patches to the -patches list. Another area where we could stand to do better is in higher-level documentation of how the internals of the system work. For example, something like the Postgres95 Implementation Guide: http://pluto.iis.nsk.su/postgres95/impl-guide/ but more complete, and up-to-date. There is some documentation in this vein (such as the README files for specific subsystems), but IMHO we could do with more. -Neil ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] nodeAgg perf tweak
Neil Conway <[EMAIL PROTECTED]> writes: > - yours would mean that int8inc() and similar aggregates wouldn't ever > need to do palloc(); mine would require a palloc() every k calls to the > transition function. No. The current code involves two pallocs per cycle, one inside the aggregate function to construct its result value, and then one in datumCopy to copy the result into the proper context. Your patch reduces that to 1 + 1/k pallocs per cycle, mine to zero. The fact that it's a central fix for all aggregate functions is definitely a nice feature of your approach, but I am concerned about the possible side-effects on user-defined aggregate functions that may not work as you expect them to. I think it's safer to keep the aggregate code behaving as-is and get the performance win in the individual functions. There are not that many aggregates that we really care that much about. regards, tom lane ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [HACKERS] nodeAgg perf tweak
On Thu, 2004-12-02 at 19:07 -0500, Tom Lane wrote: > True, but you still have to palloc if it returns the second argument. Is that common? In any case, I don't see how you can _ever_ avoid a palloc if the aggregate returns the second argument. The second argument is in a per-tuple memory context: there's nothing the aggregate, or nodeAgg, can do about it. I think the tradeoffs between our patches are: - mine would apply to all aggregates, without the need to modify any of them individually - yours would mean that int8inc() and similar aggregates wouldn't ever need to do palloc(); mine would require a palloc() every k calls to the transition function. I don't really see this as a problem: in practice k will be sufficiently large that the palloc overhead should be negligible. -Neil ---(end of broadcast)--- TIP 3: 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] [PATCHES] Unicode characters above 0x10000 #2
I have backed out this patch. It is unclear it is a bug fix.
It will be saved for 8.1.
---
pgman wrote:
>
> Patch applied. Thanks.
>
> ---
>
>
> John Hansen wrote:
> > 3 times lucky?
> >
> > Last one broke utf8 G
> >
> > This one works, Too tired, sorry for the inconvenience..
> >
> > ... John
>
> Content-Description: cvs.diff
>
> [ Attachment, skipping... ]
>
> >
> > ---(end of broadcast)---
> > TIP 9: 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
> [EMAIL PROTECTED] | (610) 359-1001
> + If your life is a hard drive, | 13 Roberts Road
> + Christ can be your backup.| Newtown Square, Pennsylvania 19073
--
Bruce Momjian| http://candle.pha.pa.us
[EMAIL PROTECTED] | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup.| Newtown Square, Pennsylvania 19073
===
RCS file: /projects/cvsroot/pgsql/src/backend/utils/mb/wchar.c,v
retrieving revision 1.38
diff -c -r1.38 wchar.c
*** src/backend/utils/mb/wchar.c17 Sep 2004 21:59:57 - 1.38
--- src/backend/utils/mb/wchar.c21 Nov 2004 09:58:36 -
***
*** 343,348
--- 343,373
return (pg_euc_dsplen(s));
}
+ bool isLegalUTF8(const UTF8 *source, int len) {
+ UTF8 a;
+ const UTF8 *srcptr = source+len;
+ if(!source || (pg_utf_mblen(source) != len)) return false;
+ switch (len) {
+ default: return false;
+ /* Everything else falls through when "true"... */
+ case 6: if ((a = (*--srcptr)) < 0x80 || a > 0xBF) return false;
+ case 5: if ((a = (*--srcptr)) < 0x80 || a > 0xBF) return false;
+ case 4: if ((a = (*--srcptr)) < 0x80 || a > 0xBF) return false;
+ case 3: if ((a = (*--srcptr)) < 0x80 || a > 0xBF) return false;
+ case 2: if ((a = (*--srcptr)) > 0xBF) return false;
+ switch (*source) {
+ /* no fall-through in this inner switch */
+ case 0xE0: if (a < 0xA0) return false; break;
+ case 0xF0: if (a < 0x90) return false; break;
+ case 0xF4: if (a > 0x8F) return false; break;
+ default: if (a < 0x80) return false;
+ }
+ case 1: if (*source >= 0x80 && *source < 0xC2) return false;
+ if (*source > 0xFD) return false;
+ }
+ return true;
+ }
+
/*
* convert UTF-8 string to pg_wchar (UCS-2)
* caller should allocate enough space for "to"
***
*** 398,404
* returns the byte length of a UTF-8 word pointed to by s
*/
int
! pg_utf_mblen(const unsigned char *s)
{
int len = 1;
--- 423,429
* returns the byte length of a UTF-8 word pointed to by s
*/
int
! pg_utf_mblen(const UTF8 *s)
{
int len = 1;
***
*** 406,418
len = 1;
else if ((*s & 0xe0) == 0xc0)
len = 2;
! else if ((*s & 0xe0) == 0xe0)
! len = 3;
return (len);
}
static int
! pg_utf_dsplen(const unsigned char *s)
{
return 1; /* XXX fix me! */
}
--- 431,449
len = 1;
else if ((*s & 0xe0) == 0xc0)
len = 2;
! else if ((*s & 0xf0) == 0xe0)
! len = 3;
! else if ((*s & 0xf8) == 0xf0)
! len = 4;
! else if ((*s & 0xfc) == 0xf8)
! len = 5;
! else if ((*s & 0xfe) == 0xfc)
! len = 6;
return (len);
}
static int
! pg_utf_dsplen(const UTF8 *s)
{
return 1; /* XXX fix me! */
}
***
*** 721,728
{pg_euckr2wchar_with_len, pg_euckr_mblen, pg_euckr_dsplen, 3},
/* 3; PG_EUC_KR */
{pg_euctw2wchar_with_len, pg_euctw_mblen, pg_euctw_dsplen, 3},
/* 4; PG_EUC_TW */
{pg_johab2wchar_with_len, pg_johab_mblen, pg_johab_dsplen, 3},
/* 5; PG_JOHAB */
! {pg_utf2wchar_with_len, pg_utf_mblen, pg_utf_dsplen, 3},/* 6;
PG_UNICODE */
! {pg_mule2wchar_with_len, pg_mule_mblen, pg_mule_dsplen, 3}, /* 7;
PG_MULE_INTERNAL */
{pg_latin12wchar_with_len, pg_latin1_mblen, pg_latin1_dsplen, 1},
/* 8; PG_LATIN1 */
{pg_latin12wchar_with_len, pg_latin1_mblen, pg_latin1_dsplen, 1},
/* 9; PG_LATIN2 */
{pg_latin12wch
Re: [HACKERS] Code documentation
On Thu, 2004-12-02 at 10:58 +0100, Gevik Babakhani wrote: > I was wondering if there are any interests or plans for documenting > various functions in the code which currently are not documented. I don't know of any systematic effort to do this. I try to document undocumented code as necessary while making related changes, and I would imagine other developers do the same. > I would like to start this discussion to see if we want to do this. It sounds like a good idea to me. Feel free to submit documentation patches to the -patches list. Another area where we could stand to do better is in higher-level documentation of how the internals of the system work. For example, something like the Postgres95 Implementation Guide: http://pluto.iis.nsk.su/postgres95/impl-guide/ but more complete, and up-to-date. There is some documentation in this vein (such as the README files for specific subsystems), but IMHO we could do with more. -Neil ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [HACKERS] Ready for RC1
Tom Lane wrote: > Bruce Momjian <[EMAIL PROTECTED]> writes: > > One more issue. Until we start RC, patches that are bug fixes will > > continue to be applied. Do we want that? By going RC we are basically > > saying we need to focus on docs and packaging and we perhaps can keep > > fixes for 8.0.1. > > In my mind "RC" means "only critical bug fixes" --- ie, just because > it's a bug fix doesn't mean it won't be held for later. But RC doesn't > mean "no changes, period". It means we're trying to test the thing > without any more code churn than absolutely necessary. > > The real problem at the moment is that we should have been in an "only > bug fixes" mode for some time already, and you just pushed in two or > three patches that look more like feature additions to me (and I gather > to Peter as well). *That* is the reason people are getting antsy about > whether we are RC-ready. I honestly can't tell whether these are bug fixes or not, especially the encoding changes, so I put them in the queue and when no one says anything I apply them. -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 3: 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] 7.4.6 build failures on Solaris 9 with Sun cc
Philip Yarra <[EMAIL PROTECTED]> writes:
> Hi all, before I delve too deeply into this, has anyone else tried building
> 7.4.6 on Solaris 9 (sparc) ? I'm seeing build failures using Sun's cc:
> make[4]: Entering directory `/tmp/postgresql-7.4.6/src/backend/access/heap'
> cc -Xa -O -v -I../../../../src/include -c -o tuptoaster.o tuptoaster.c
> "tuptoaster.c", line 831: member can not have variably modified type: data
> "tuptoaster.c", line 937: cannot recover from previous errors
> cc: acomp failed for tuptoaster.c
> Which is:
> struct
> {
> struct varlena hdr;
> chardata[TOAST_MAX_CHUNK_SIZE];
> } chunk_data;
> The compiler is cc: Sun C 5.6 2004/06/02 (Sun Studio 9)
I think we've seen this before, and the workaround was to replace the
expression that defines TOAST_MAX_CHUNK_SIZE with a hand-computed
constant. Check the archives.
regards, tom lane
---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] Ready for RC1
Bruce Momjian <[EMAIL PROTECTED]> writes: > One more issue. Until we start RC, patches that are bug fixes will > continue to be applied. Do we want that? By going RC we are basically > saying we need to focus on docs and packaging and we perhaps can keep > fixes for 8.0.1. In my mind "RC" means "only critical bug fixes" --- ie, just because it's a bug fix doesn't mean it won't be held for later. But RC doesn't mean "no changes, period". It means we're trying to test the thing without any more code churn than absolutely necessary. The real problem at the moment is that we should have been in an "only bug fixes" mode for some time already, and you just pushed in two or three patches that look more like feature additions to me (and I gather to Peter as well). *That* is the reason people are getting antsy about whether we are RC-ready. regards, tom lane ---(end of broadcast)--- TIP 3: 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] Ready for RC1
Marc G. Fournier wrote: > On Thu, 2 Dec 2004, Bruce Momjian wrote: > > > One more issue. Until we start RC, patches that are bug fixes will > > continue to be applied. Do we want that? By going RC we are basically > > saying we need to focus on docs and packaging and we perhaps can keep > > fixes for 8.0.1. > > critical bug fixes should be applied through RC, so that full release is > as solid as possible ... that's generally what forces our extra RCs ... Right. My point is that minor fixes are getting in because we are still in beta, while in RC those minor fixes are held for the next minor release. -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Ready for RC1
On Thu, 2 Dec 2004, Bruce Momjian wrote: One more issue. Until we start RC, patches that are bug fixes will continue to be applied. Do we want that? By going RC we are basically saying we need to focus on docs and packaging and we perhaps can keep fixes for 8.0.1. critical bug fixes should be applied through RC, so that full release is as solid as possible ... that's generally what forces our extra RCs ... Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email: [EMAIL PROTECTED] Yahoo!: yscrappy ICQ: 7615664 ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
Re: [HACKERS] Ready for RC1
Bruce Momjian wrote: > Marc G. Fournier wrote: > > On Fri, 3 Dec 2004, Peter Eisentraut wrote: > > > > > Bruce Momjian wrote: > > >> I have applied all outstanding patches and I think we are ready to go > > >> for RC1. > > > > > > Considering that you just added at least three new and completely > > > untested features, I don't think RC1 is the way to go. > > > > I have to agree here ... I'd do a beta6 tomorrow, but "Open Items for 8.0" > > means we aren't ready for a "Release Candidate" ... > > True, I was going to just move them to TODO and push on but there has > been on agreement that is the way to go for the open items. One more issue. Until we start RC, patches that are bug fixes will continue to be applied. Do we want that? By going RC we are basically saying we need to focus on docs and packaging and we perhaps can keep fixes for 8.0.1. -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] 8.0RC1 tomorrow
Peter Eisentraut wrote: Andrew Dunstan wrote: If you have something missing from here I'm especially interested in hearing from you. I think "Linux" entries are quite useless. We need to know what distribution (and version) it is. The kernel is actually a pretty uninteresting part of the porting process. I would very much welcome your input and that of other major developers on a) how we classify farm members, b) what steps should be run for a farm test, and c) what information would be useful from a build run. Unfortunately I got hit with some unexpected issues about a month ago that have restricted my available time rather. So far I have been concentrating on getting the clients working robustly - Windows and Cygwin have been something of a challenge, as expected. The server side is extremely simple - crude even. The database is as just 2 tables like this: pgbuildfarm=# \d buildsystems Table "public.buildsystems" Column | Type | Modifiers -+--+--- name | text | not null secret | text | not null operating_system | text | not null os_version | text | not null compiler | text | not null compiler_version | text | not null architecture | text | not null status | text | not null sys_owner| text | not null owner_email | text | not null Indexes: "buildsystems_pkey" primary key, btree (name) pgbuildfarm=# \d build_status Table "public.build_status" Column |Type | Modifiers --+-+--- sysname | text| not null snapshot | timestamp without time zone | not null status| integer | stage | text| log | text| conf_sum | text| branch| text| changed_this_run | text| changed_since_success | text| Indexes: "build_status_pkey" primary key, btree (sysname, snapshot) "bs_branch_snapshot_idx" btree (branch, snapshot) "bs_sysname_branch_idx" btree (sysname, branch) Foreign-key constraints: "bs_fk" FOREIGN KEY (sysname) REFERENCES buildsystems(name) ON UPDATE CASCADE ON DELETE CASCADE These were really more or less placeholders while I got things up and running. Any constructive input is welcome. Anyone who would like to make the web site look spiffy rather than pedestrian would be especially welcome (it's done in perl + template toolkit). cheers andrew ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [HACKERS] Ready for RC1
Marc G. Fournier wrote: > On Fri, 3 Dec 2004, Peter Eisentraut wrote: > > > Bruce Momjian wrote: > >> I have applied all outstanding patches and I think we are ready to go > >> for RC1. > > > > Considering that you just added at least three new and completely > > untested features, I don't think RC1 is the way to go. > > I have to agree here ... I'd do a beta6 tomorrow, but "Open Items for 8.0" > means we aren't ready for a "Release Candidate" ... True, I was going to just move them to TODO and push on but there has been on agreement that is the way to go for the open items. -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] Updated open items list
On Thu, 2 Dec 2004, Bruce Momjian wrote: Here is an updated open items list. The first three items are the ones that are going to be closed tomorrow and moved to the TODO list. I already moved the terminal server issue to the TODO list. 'k, will watch for commits on these before doing the RC1 ... Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email: [EMAIL PROTECTED] Yahoo!: yscrappy ICQ: 7615664 ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [HACKERS] Ready for RC1
On Fri, 3 Dec 2004, Peter Eisentraut wrote: Bruce Momjian wrote: I have applied all outstanding patches and I think we are ready to go for RC1. Considering that you just added at least three new and completely untested features, I don't think RC1 is the way to go. I have to agree here ... I'd do a beta6 tomorrow, but "Open Items for 8.0" means we aren't ready for a "Release Candidate" ... Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email: [EMAIL PROTECTED] Yahoo!: yscrappy ICQ: 7615664 ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
[HACKERS] 7.4.6 build failures on Solaris 9 with Sun cc
Hi all, before I delve too deeply into this, has anyone else tried building
7.4.6 on Solaris 9 (sparc) ? I'm seeing build failures using Sun's cc:
make[4]: Entering directory `/tmp/postgresql-7.4.6/src/backend/access/heap'
cc -Xa -O -v -I../../../../src/include -c -o tuptoaster.o tuptoaster.c
"tuptoaster.c", line 831: member can not have variably modified type: data
"tuptoaster.c", line 937: cannot recover from previous errors
cc: acomp failed for tuptoaster.c
Which is:
struct
{
struct varlena hdr;
chardata[TOAST_MAX_CHUNK_SIZE];
} chunk_data;
The compiler is cc: Sun C 5.6 2004/06/02 (Sun Studio 9)
If no-one's seen this before, I'll do some digging.
Regards, Philip.
---(end of broadcast)---
TIP 3: 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] 8.0RC1 tomorrow
Andrew Dunstan wrote: > If you have something missing from here I'm especially interested in > hearing from you. I think "Linux" entries are quite useless. We need to know what distribution (and version) it is. The kernel is actually a pretty uninteresting part of the porting process. -- Peter Eisentraut http://developer.postgresql.org/~petere/ ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
Re: [HACKERS] multiline CSV fields
Tom Lane wrote:
Andrew Dunstan <[EMAIL PROTECTED]> writes:
+ if (!embedded_line_warning && (c == '\n' || c == '\r') )
+ {
+ embedded_line_warning = true;
+ elog(WARNING,
+ "CSV fields with embedded linefeed or carriage return "
+ "characters might not be able to be reimported");
+ }
What about forcibly translating them to the two-character sequences \n
or \r? Or is that not considered a CSV-compatible representation?
Not compatible AFAIK. Certainly not portably. And the warning would
still be true, because we don't do this unescaping on the way back in. I
think the way the comment in the patch suggests and previous emails have
discussed is the right way to go with this - I will attend to it after
we branch ;-)
cheers
andrew
---(end of broadcast)---
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] 8.0RC1 tomorrow
Tom Lane wrote: > We never really issued a "call for port reports" as has been past > practice. I think that Andrew Dunstan's build farm has partially > obsoleted that custom, but if you have access to a platform that > is not represented in the build farm, please do give it a try soon. The platform coverage of the build farm is currently quite limited, and all those red lines don't make me feel better. I think we still need to check all the platforms explicitly. -- Peter Eisentraut http://developer.postgresql.org/~petere/ ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
Re: [HACKERS] Ready for RC1
Bruce Momjian wrote: > I have applied all outstanding patches and I think we are ready to go > for RC1. Considering that you just added at least three new and completely untested features, I don't think RC1 is the way to go. -- Peter Eisentraut http://developer.postgresql.org/~petere/ ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [HACKERS] 8.0RC1 tomorrow
Travis P wrote:
On Dec 2, 2004, at 5:44 PM, Andrew Dunstan wrote:
http://pgfoundry.org/projects/pgbuildfarm/
I started work today on a page that lists all the members.
Ah, good. I'm not seeing it immediately, but I'll keep my eye out.
I've an AIX 5.1 system on which I could try to compile if you don't
have one in the farm, though I usually build/deploy on Linux.
current approved members:
name| os | compiler | arch | branches
--+---++--+--
cat | Linux 2.4.22 | gcc 3.3.2 | i386 |
dog | Linux 2.4.22 | gcc 3.3.2
| i386 | {HEAD,REL7_4_STABLE}
kangaroo | Mac OS X 10.3.5 | gcc 3.3 20030304 (Apple Computer, Inc. build 1495) | PowerPC G4 |
echidna | FreeBSD 6-CURRENT | gcc 3.4.2 [FreeBSD] 20040728 | x86 |
potorooo | Solaris 2.8 | gcc 3.3.2
| Ultra SPARC | {HEAD,REL7_4_STABLE}
capuchin | AIX 4.2.2 | gcc 2.8.1 | Power 2 |
spoonbill | OpenBSD 3.6-current | gcc 3.3.2
| Sparc64 | {HEAD,REL7_4_STABLE}
lionfish | Linux Debian/Sarge| gcc 3.3.4
| mipsel | {HEAD,REL7_4_STABLE}
kudu | Solaris 9 | Sun WorkShop 6 update 2 C 5.3 Patch
111680-09 | x86 | {HEAD,REL7_4_STABLE}
emu | OpenBSD 3.6-current | gcc 2.95.3
| x86/SMP | {HEAD,REL7_4_STABLE}
badger| Fedora Core 2 | GCC 3.3.3
| x86 (Athlon) | {HEAD}
canary| NetBSD 1.6| gcc 2.95.3
| x86 | {HEAD,REL7_4_STABLE}
cockatoo | FreeBSD 4.10-STABLE | gcc 2.95.4
| x86 | {HEAD,REL7_4_STABLE}
galah | FreeBSD 5.3 | gcc 3.4.2
| x86 | {HEAD,REL7_4_STABLE}
loris | Windows XP Pro| gcc 3.2.3
| x86 | {HEAD}
gibbon| Cygwin NT-5.1 | gcc 3.3.3 (cygwin special)
| x86 | {HEAD}
panda | Linux Debian sid | gcc 3.3.5
| amd64| {HEAD,REL7_4_STABLE}
viper | Fedora Core 3 | GCC 3.4.2 | x86_64 |
caribou | Linux 2.6.9 | gcc 3.3.5 | x86_64 |
shrew | Mandrake Linux 10.0 2.6.5 SMP | gcc 3.3.2 | AMD 2600x2 |
Those with nothing in the branches column have not yet reported results
(one is my test machine).
If you have something missing from here I'm especially interested in
hearing from you. (HPUX and Solaris-x86 for example). Also anyone who
has Windows machines that can be used to replace the Cygwin and Windows
hosts.
cheers
andrew
---(end of broadcast)---
TIP 9: the planner will ignore your desire to choose an index scan if your
joining column's datatypes do not match
Re: [HACKERS] multiline CSV fields
Andrew Dunstan <[EMAIL PROTECTED]> writes:
> + if (!embedded_line_warning && (c == '\n' || c == '\r') )
> + {
> + embedded_line_warning = true;
> + elog(WARNING,
> + "CSV fields with embedded linefeed or carriage
> return "
> + "characters might not be able to be
> reimported");
> + }
What about forcibly translating them to the two-character sequences \n
or \r? Or is that not considered a CSV-compatible representation?
regards, tom lane
---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] nodeAgg perf tweak
Neil Conway <[EMAIL PROTECTED]> writes: > On Thu, 2004-12-02 at 10:45 -0500, Tom Lane wrote: >> (2) I think you lose much of the performance >> benefit as soon as you have to distinguish cases (b) and (c). > Why wouldn't a simple comparison work? We're passing two arguments into > the aggregate function: (a) corresponds to returning the first argument, > and (b) corresponds to returning the second argument. True, but you still have to palloc if it returns the second argument. > Yeah, I like your approach as well (sorry, I had thought Simon's earlier > suggestion along these lines would have required adding knowledge about > builtin aggregates to advance_transition_function() itself; adding > knowledge to the aggregate implementation is a lot nicer). It needs documentation --- what I sent you was just a crude hack for testing, not something I would've committed as-is. IIRC, the spec I had in mind was "if fcinfo->context is an AggState node then the function may assume it's being called as an aggregate's transition or final function. In this case, the first argument is certainly either an initial value or the output of a prior transition function call. The function may assume that it's OK to scribble on the first argument instead of allocating a fresh object for its result." One could also imagine that the transition and final functions could make a private agreement about the contents of the state value, such that it needn't be a strictly valid Datum --- for instance it might contain pointers to additional transient storage someplace. I think that at the time we were discussing such hacks in connection with user-defined aggregates that needed a large amount of state. regards, tom lane ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [PATCHES] [HACKERS] multiline CSV fields
I wrote:
If it bothers you that much. I'd make a flag, cleared at the start of
each COPY, and then where we test for CR or LF in CopyAttributeOutCSV,
if the flag is not set then set it and issue the warning.
I didn't realise until Bruce told me just now that I was on the hook for
this. I guess i should keep my big mouth shut. (Yeah, that's gonna
happen ...)
Anyway, here's a tiny patch that does what I had in mind.
cheers
andrew
Index: copy.c
===
RCS file: /home/cvsmirror/pgsql/src/backend/commands/copy.c,v
retrieving revision 1.234
diff -c -r1.234 copy.c
*** copy.c 6 Nov 2004 17:46:27 - 1.234
--- copy.c 2 Dec 2004 23:34:20 -
***
*** 98,103
--- 98,104
static EolType eol_type; /* EOL type of input */
static int client_encoding; /* remote side's character encoding */
static int server_encoding; /* local encoding */
+ static bool embedded_line_warning;
/* these are just for error messages, see copy_in_error_callback */
static bool copy_binary; /* is it a binary copy? */
***
*** 1190,1195
--- 1191,1197
attr = tupDesc->attrs;
num_phys_attrs = tupDesc->natts;
attr_count = list_length(attnumlist);
+ embedded_line_warning = false;
/*
* Get info about the columns we need to process.
***
*** 2627,2632
--- 2629,2653
!use_quote && (c = *test_string) != '\0';
test_string += mblen)
{
+ /*
+ * We don't know here what the surrounding line end characters
+ * might be. It might not even be under postgres' control. So
+ * we simple warn on ANY embedded line ending character.
+ *
+ * This warning will disappear when we make line parsing field-aware,
+ * so that we can reliably read in embedded line ending characters
+ * regardless of the file's line-end context.
+ *
+ */
+
+ if (!embedded_line_warning && (c == '\n' || c == '\r') )
+ {
+ embedded_line_warning = true;
+ elog(WARNING,
+ "CSV fields with embedded linefeed or carriage return "
+ "characters might not be able to be reimported");
+ }
+
if (c == delimc || c == quotec || c == '\n' || c == '\r')
use_quote = true;
if (!same_encoding)
---(end of broadcast)---
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] nodeAgg perf tweak
On Thu, 2004-12-02 at 10:45 -0500, Tom Lane wrote: > (2) I think you lose much of the performance > benefit as soon as you have to distinguish cases (b) and (c). Ideally > you would use MemoryContextContains for this, but that doesn't work > reliably on pointers that point to fields of a tuple. Why wouldn't a simple comparison work? We're passing two arguments into the aggregate function: (a) corresponds to returning the first argument, and (b) corresponds to returning the second argument. If the aggregate wants to do something more than just return one of the arguments, they can copy/alloc in the current context. > I like the approach shown in my prototype patch better, because it > doesn't create any backwards-compatibility issues for existing aggregate > functions; instead individual aggregates may be rewritten to avoid > palloc's. Yeah, I like your approach as well (sorry, I had thought Simon's earlier suggestion along these lines would have required adding knowledge about builtin aggregates to advance_transition_function() itself; adding knowledge to the aggregate implementation is a lot nicer). -Neil ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
Re: [HACKERS] 8.0RC1 tomorrow
On Dec 2, 2004, at 5:44 PM, Andrew Dunstan wrote: http://pgfoundry.org/projects/pgbuildfarm/ I started work today on a page that lists all the members. Ah, good. I'm not seeing it immediately, but I'll keep my eye out. I've an AIX 5.1 system on which I could try to compile if you don't have one in the farm, though I usually build/deploy on Linux. -Travis ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] Fix for "q" with psql display paging dumps out of psql
Bruce Momjian <[EMAIL PROTECTED]> wrote: > > > You will be glad to know that 8.0 will use a different implementation > for thread handling of SIGPIPE, though your asynchronous handling of > SIGPIPE will still cause problems. So-noted. Jim ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [PATCHES] [HACKERS] Open Items
> I am going to discard these emails. We haven't solve the Win32 terminal > server problem and I think it needs to be moved to the TODO list instead. Yes, please do that. I do not think there is a problem on TS other than some missing permissions. The patch was only intended to avoid starting 2 postmasters for the same datadir. The patch is not 100% since I was told that my check would fail on Win95 and falsely assume Win95 allows a \ in the shmem name. I think that would currently not matter, but it is unclean for the future. Andreas ---(end of broadcast)--- TIP 3: 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] Fix for "q" with psql display paging dumps out of psql
Tom Lane <[EMAIL PROTECTED]> wrote: > > [EMAIL PROTECTED] (Jim Seymour) writes: > > I'm kind of wondering if anybody on the dev team noticed this and > > what, if anything, they planned to do with it? > > Can we make it "#ifdef SOLARIS7" somehow? I'm uneager to put a > performance penalty on every platform because of an admittedly > broken signal implementation on one. I don't have a problem with #ifdef'ing it in/out. But will an extra pqsignal() call at that point would incur an appreciable performance penalty? > > Also, you didn't explain what changed between 7.4.2 and 7.4.6 to > make this necessary when it wasn't before. That would involve extensive slogging though the code, identifying all the changes made between 7.4.2 and who-knows-what-version (the problem exists with 7.4.5, as well) and working-out their impact. Yeah, it's a kludgy fix. I certainly won't be offended if you don't care to address this problem--particularly if you don't care to use that fix. Jim ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [HACKERS] 8.0RC1 tomorrow
Tom Lane wrote: Travis P <[EMAIL PROTECTED]> writes: What platforms are covered by the build farm? See http://www.pgbuildfarm.org/cgi-bin/show_status.pl Also I think there is a gborg project page for it. s/gborg/pgfoundry/ http://pgfoundry.org/projects/pgbuildfarm/ I started work today on a page that lists all the members. cheers andrew ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] 8.0RC1 tomorrow
Travis P <[EMAIL PROTECTED]> writes: > What platforms are covered by the build farm? See http://www.pgbuildfarm.org/cgi-bin/show_status.pl Also I think there is a gborg project page for it. regards, tom lane ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] 8.0RC1 tomorrow
On Dec 2, 2004, at 11:08 AM, Tom Lane wrote: We never really issued a "call for port reports" as has been past practice. I think that Andrew Dunstan's build farm has partially obsoleted that custom, but if you have access to a platform that is not represented in the build farm, please do give it a try soon. What platforms are covered by the build farm? I couldn't find any info about it as I looked through the pages at http://developer.postgresql.org/ -Travis ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
[HACKERS] Updated open items list
Here is an updated open items list. The first three items are the ones that are going to be closed tomorrow and moved to the TODO list. I already moved the terminal server issue to the TODO list. --- PostgreSQL 8.0 Open Items = Current version at http://candle.pha.pa.us/cgi-bin/pgopenitems. Changes --- * Win32 o Disallow encodings like UTF8 which which PostgreSQL supports but the operating system does not * warn on COPY TO ... CSV with \r,\n in data * adjust bgwriter defaults Documentation - * synchonize supported encodings and docs * add external interfaces documentation section Fixed Since Last Beta - * fix gettext support to src/port -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [PATCHES] [HACKERS] Open Items
I am going to discard these emails. We haven't solve the Win32 terminal server problem and I think it needs to be moved to the TODO list instead. --- Zeugswetter Andreas DAZ SD wrote: > > > o fix shared memory on Win2k terminal server > > > > We might be able to just mark this as not supported. > > I have attached a patch that I think fixes this. The problem I saw > and fixed is, that the shmem created in a terminal services client is not > visible to the console (or services.msc). > > It was necessary to differenciate OS versions, this might be better put > elsewhere. > > I think in addition the system global name "sharemem.1" should be made more > pg specific, like "PostgreSQL.1". I have not done this since a new compile > would not detect a running old beta. But now would be the time (or never). > > Andreas Content-Description: shmem.win32.patch [ Attachment, skipping... ] > > ---(end of broadcast)--- > TIP 7: don't forget to increase your free space map settings -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 3: 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] Ready for RC1
I have applied all outstanding patches and I think we are ready to go for RC1. These are the open items. I think we will just have to move them to the TODO list tomorrow, except for the documentation items. --- PostgreSQL 8.0 Open Items = Current version at http://candle.pha.pa.us/cgi-bin/pgopenitems. Changes --- * Win32 o Fix shared memory on Win2k terminal server We might be able to just mark this as not supported. o Disallow encodings like UTF8 which which PostgreSQL supports but the operating system does not * adjust bgwriter defaults * synchonize supported encodings and docs * warn on COPY TO ... CSV with \r,\n in data * add external interfaces documentation section Fixed Since Last Beta - * fix gettext support to src/port -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] [pgsql-hackers-win32] [BUGS] pg_autovacuum in 8beta-dev3 small bug
Patch applied. Thanks. --- Dave Page wrote: > > > > -Original Message- > > From: [EMAIL PROTECTED] > > [mailto:[EMAIL PROTECTED] On Behalf > > Of Bruce Momjian > > Sent: 27 November 2004 04:33 > > To: [EMAIL PROTECTED] > > Cc: PostgreSQL Win32 port list; PostgreSQL-development > > Subject: Re: [pgsql-hackers-win32] [BUGS] pg_autovacuum in > > 8beta-dev3 small bug > > > > > > Can someone comment on this? > > > > -- > > - > > > > Leen Besselink wrote: > > > Hi folks, > > > > > > 8.0beta3 has pg_autovacuum included, when I want to run this as a > > > Windows service, it says you can use the -I and -R options. > > > > > > When I do that and I specify a password with '-P' > > (uppercase) then in > > > the registry it's saved as '-p' (lowercase) in the > > service-commandline > > > (ImagePath). > > This was fixed in v1.21 of pg_autovacuum.c, That rev is tagged for > beta3, so you should not be seeing this issue unless you actually have > an older version for some reason. > > http://developer.postgresql.org/cvsweb.cgi/pgsql/contrib/pg_autovacuum/p > g_autovacuum.c.diff?r1=1.20;r2=1.21;f=h > > > > Also it removes the quotes I added and I'm not so sure it > > would work > > > the way it's supposed to, without it. > > It's not so much that it strips them (that happens automagically), more > that it doesn't re-add them when it writes the command line in the > registry. The attached patch fixes that by simply quoting all options > that may need it. > > > > If you add DependOnService (a REG_MULTI_SZ an > > array-like-thingie) and > > > have the name (in this case: pgsql-8.0-beta2-dev3) of a service it > > > depends on, it will not fail to start (it will not even try, as > > > PostgreSQL is not running), when PostgreSQL already failed. > > > > > > Maybe it's an idea to specify it on the commandline (what > > service to > > > depend on). > > A -E option is added in the attached patch. > > Regards, Dave. Content-Description: pg_autovacuum.diff [ Attachment, skipping... ] > > ---(end of broadcast)--- > TIP 6: Have you searched our list archives? > >http://archives.postgresql.org -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] [PATCHES] Unicode characters above 0x10000 #2
Patch applied. Thanks. --- John Hansen wrote: > 3 times lucky? > > Last one broke utf8 G > > This one works, Too tired, sorry for the inconvenience.. > > ... John Content-Description: cvs.diff [ Attachment, skipping... ] > > ---(end of broadcast)--- > TIP 9: 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 [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
Re: [HACKERS] readline/libedit selection
Kris Jurka <[EMAIL PROTECTED]> writes: > On Thu, 2 Dec 2004, Tom Lane wrote: >> Reading between the lines, I wonder if your problem is that your copy of >> editline puts its headers in include/readline rather than >> include/editline? > Yes, this is the actual problem readline.h is indeed in > /usr/include/readline. Grumble ... they really shouldn't do that, because there's no sane upgrade path to an installation of both libraries. But I've hacked configure to look there when trying to find libedit headers. regards, tom lane ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [HACKERS] readline/libedit selection
On Thu, 2 Dec 2004, Tom Lane wrote: > Reading between the lines, I wonder if your problem is that your copy of > editline puts its headers in include/readline rather than > include/editline? > Yes, this is the actual problem readline.h is indeed in /usr/include/readline.. The missing symbols I mentioned earlier are found in both libtermcap and libcurses, so I imagine linking to curses is still the correct thing to do. Kris Jurka ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [HACKERS] 8.0RC1 tomorrow
Tom Lane wrote: The core committee has agreed that it's about time to advance to Release Candidate status (which we define as "code is frozen, but not docs nor message translation work"). Barring surprises, 8.0RC1 will be wrapped tomorrow (Friday). We never really issued a "call for port reports" as has been past practice. I think that Andrew Dunstan's build farm has partially obsoleted that custom, but if you have access to a platform that is not represented in the build farm, please do give it a try soon. Tom, Will ANALYZE continue to ignore columns whose data is composed entirely of NULL in 8.0? http://archives.postgresql.org/pgsql-performance/2004-11/msg00363.php Mike Mascari ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Error handling in plperl and pltcl
Jan,
... plus that the catch-nesting automatically represents the
subtransaction nesting. I can't really see any reason why those two
should not be bound together. Does anybody?
That depends on what you mean. As a stop-gap solution, cerntanly. But in
the long run, I still think that savepoints and exception handling
should be kept separate. Consider the following two examples:
savepoint a
spi calls
savepoint b
spi calls
savepoint c
spi calls
switch(some test)
{
case 1:
rollback b;
commit a;
break;
case 2:
rollback c;
commit a;
break;
case 3:
rollback a;
break;
default:
commit a;
}
or nested try/catch where the catch doesn't access the database:
foo()
{
try
{
spi calls;
}
catch
{
set some status;
re-throw;
}
}
and some other place in the code:
savepoint a
try
{
spi calls;
for(i = 0; i < 100; ++i)
foo();
commit a;
}
catch
{
rollback a;
}
If "normal" savepoint hanling is disabled here in favor of your
suggestion, you will get 101 subtransations although only 1 is relevant.
I still think that the concept of savepoints is fairly easy to
understand. Using it together with exception handling is a common and
well known concept and we can make it even more so by providing good
documentation and examples.
Regards,
Thomas Hallgren
---(end of broadcast)---
TIP 3: 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] readline/libedit selection
Kris Jurka <[EMAIL PROTECTED]> writes:
> This recent change to readline/libedit selection isn't quite right.
> http://archives.postgresql.org/pgsql-committers/2004-11/msg00330.php
I found the reason for not linking to libtermcap --- there was an
ancient netbsd-specific hack that wasn't general-purpose enough.
This wouldn't have anything to do with the header-file-not-found though.
regards, tom lane
*** config/programs.m4.orig Tue Nov 30 01:13:02 2004
--- config/programs.m4 Thu Dec 2 14:59:03 2004
***
*** 87,99
for pgac_lib in "" " -ltermcap" " -lncurses" " -lcurses" ; do
LIBS="${pgac_rllib}${pgac_lib} $pgac_save_LIBS"
AC_TRY_LINK_FUNC([readline], [[
! # NetBSD, OpenBSD, and Irix have a broken linker that does not
! # recognize dependent libraries
! case $host_os in netbsd* | openbsd* | irix*)
! case $pgac_lib in
! *curses*) ;;
! *) pgac_lib=" -lcurses" ;;
! esac
esac
pgac_cv_check_readline="${pgac_rllib}${pgac_lib}"
--- 87,100
for pgac_lib in "" " -ltermcap" " -lncurses" " -lcurses" ; do
LIBS="${pgac_rllib}${pgac_lib} $pgac_save_LIBS"
AC_TRY_LINK_FUNC([readline], [[
! # Older NetBSD, OpenBSD, and Irix have a broken linker that does not
! # recognize dependent libraries; assume curses is needed if we didn't
! # find any dependency.
! case $host_os in
! netbsd* | openbsd* | irix*)
! if test x"$pgac_lib" = x"" ; then
! pgac_lib=" -lcurses"
! fi ;;
esac
pgac_cv_check_readline="${pgac_rllib}${pgac_lib}"
---(end of broadcast)---
TIP 8: explain analyze is your friend
Re: [PATCHES] [HACKERS] plperl Safe restrictions
On Thu, 2004-12-02 at 02:21 -0500, Greg Stark wrote: > "Andrew Dunstan" <[EMAIL PROTECTED]> writes: > > > John wanted us to allow use of the 'locale' and 'utf8' pragmas in trusted > > code. > > You know, there's something twisted in postgres's naming scheme here. How is > it that "trusted" languages the ones that need a sandbox? and "untrusted" > languages the ones that get to run amok without restrictions? > > I would have thought it would be the other way around. It's not that you trust the language, it that you trust the PostgreSQL despite the language. -- ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [PATCHES] [HACKERS] plperl Safe restrictions
"Andrew Dunstan" <[EMAIL PROTECTED]> writes: > John wanted us to allow use of the 'locale' and 'utf8' pragmas in trusted > code. You know, there's something twisted in postgres's naming scheme here. How is it that "trusted" languages the ones that need a sandbox? and "untrusted" languages the ones that get to run amok without restrictions? I would have thought it would be the other way around. -- greg ---(end of broadcast)--- TIP 3: 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] psql and schemas
Neil Conway wrote: > On Sat, 2004-11-27 at 23:11 -0500, Bruce Momjian wrote: > > Is there a TODO here? Or a few? > > Sure: you could add a TODO item like "Improve psql schema behavior", and > assign it to me. I'll send in a patch that implements the behavior I > proposed for 8.1 Added to TODO: * Fix psql's display of schema information (Neil) -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 3: 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: Re: [HACKERS] lwlocks and starvation
Neil Conway <[EMAIL PROTECTED]> wrote on 02.12.2004, 05:55:43: > On Wed, 2004-12-01 at 21:51 -0500, Bruce Momjian wrote: > > Neil, where are we on this? Should we add comments? Add a TODO? A patch? > > I'm not sure what the right resolution is. As I said, I don't think it's > wise to apply a patch that could have a significant impact on > performance without (a) testing its performance effect and/or (b) having > any evidence that the problem it addresses actually effects anyone in > the real world. I agree, it would be unwise to apply the patch. In contrast to my comments on the nodeAgg perf tweak, changing the way lwlocks are allocated could have catastrophic effect on the whole system. We've got no evidence that it repesents a beneficial performance change, but the risk of it causing some unforeseen problem in at least one corner of the code is seems very high. I'm pleased we found this, but changing it should be deferred till at least 8.1. Perhaps a TODO item could read "investigating lwlock scheduling algorithms"? We might yet find that there is no single right answer and we need different algorithms for different locks... Best Regards, Simon Riggs ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
[HACKERS] 8.0RC1 tomorrow
The core committee has agreed that it's about time to advance to Release Candidate status (which we define as "code is frozen, but not docs nor message translation work"). Barring surprises, 8.0RC1 will be wrapped tomorrow (Friday). We never really issued a "call for port reports" as has been past practice. I think that Andrew Dunstan's build farm has partially obsoleted that custom, but if you have access to a platform that is not represented in the build farm, please do give it a try soon. regards, tom lane ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
[HACKERS] tsearch2 documentation additions
Hi there, there are several new contributed docs on tsearch2 page: # How to use tsearch2 in Japanese # Tsearch2 and Unicode/UTF-8 # Howto write my own parser for tsearch2 Thanks to Junji TERAMOTO, Markus Wollny and Valli for their work ! Regards, Oleg _ Oleg Bartunov, sci.researcher, hostmaster of AstroNet, Sternberg Astronomical Institute, Moscow University (Russia) Internet: [EMAIL PROTECTED], http://www.sai.msu.su/~megera/ phone: +007(095)939-16-83, +007(095)939-23-83 ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: Please release (was Re: [HACKERS] nodeAgg perf tweak)
On Wed, Dec 01, 2004 at 10:04:43PM -0500, Tom Lane wrote:
> "Andrew Dunstan" <[EMAIL PROTECTED]> writes:
> > I've raised this before, but would like to suggest again that there might be
> > virtue in branching earlier in the dev cycle - maybe around the time of the
> > first beta.
>
> Given the amount of patching that's gone on, branching 8.1 earlier would
> have meant a great deal more work for the committers, in the form of
> double-patching stuff.
That's because of CVS. Other systems deal with this issues in a more
committer-friendly manner.
You just have to look at how using BitKeeper has dramatically increased
the development going on at the Linux kernel. Whatever your opinion is
on Linux itself, that change alone is something to consider.
Also, committers are not the only users of our SCM tool. Consider the
autovacuum-backend-integration patch. Nobody reviewed it because it's a
lot of hassle to take the patch, apply it locally, test it, and continue
development. Because if later Matthew comes up with an updated patch,
the reviewer has trouble merging both things, and re-reviewing the new
patch ("did he change this in the new patch, or is it the same as
before?"). Branching the whole thing could mean that I can integrate
his own change history in my private tree, so I can see what went on
since the last time; and he can see what changes I did and merge it;
etc. The final step, which would be your own review and integration
into the official tree, has a better patch to begin with. Which is the
way Linux works.
I think I will start using Subversion to track Postgres, just to see how
it goes.
--
Alvaro Herrera (<[EMAIL PROTECTED]>)
"If it wasn't for my companion, I believe I'd be having
the time of my life" (John Dunbar)
---(end of broadcast)---
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: Re: Please release (was Re: [HACKERS] nodeAgg perf tweak)
Neil Conway <[EMAIL PROTECTED]> wrote on 02.12.2004, 05:05:12: > On Wed, 2004-12-01 at 19:34 +0100, [EMAIL PROTECTED] wrote: > > I regard performance testing as an essential part of the > > release process of any performance critical software. Most earlier beta > > releases were fixing functional problems and now the focus has moved to > > performance related issues. > > I don't agree. There is an important difference between fixing a > performance regression and making a performance improvement. If a change > made in 8.0 resulted in a significant, unintentional performance > regression, I think there would be grounds for fixing it (assuming the > fix was fairly noninvasive). The aggregate patch addresses a problem > that has existed for a long time (7.4 at the least); I don't see the > need to delay 8.0 to fix it. > I understand this argument, but believe it misses out one consideration. IMHO the effects of this are somewhat problematic for performance-related issues: ISTM Performance -of any product- is mainly tested during late beta. This is the first real chance to see whether the software performs, since it was unstable or incomplete before that point. Unplanned performance opportunities arise at this time in the cycle. It seems strange to me to only fix regressions that emerge, but simply ignore positive opportunities that arise. For me, the subject under discussion here is what to do with these positive opportunities; I agree with you on handling regressions. If we choose not to take opportunities, then many performance concerns are effectively only ever fixed one release behind and the group is therefore making an unconscious decision that performance is not a top-tier function of the product. My own viewpoint comes from effectively being a leading-edge user (by proxy) - I don't claim any right to an opinion on this issue for any other reason. I do have respect for robustness concerns (why else would I do PITR?), and wouldn't argue this route if the code changes we're discussing weren't well isolated and IMHO fairly non-invasive. These decisions are always a risk-benefit trade-off. If I seem to speak too loudly, please forgive me. I raise this because I honestly believe the +20% perf tweak to be of benefit to the majority, and worth a comparatively short wait to implement and test. We haven't mentioned this, but it is easy to produce custom versions for people with these tweaks in, but that approach detracts from general adoption of the software. As a result, it seems likely that *not* implementing the patch could result in greater personal benefit to me, though that's not a stance I ever take. Could we implement this using a GUC, turned off by default, memory_protect_functions = true, which does not appear in the postgresql.conf? Any potential instability would then be protected by default and partially discouraged from use. That would allow people who understood the risk to disable the robustness in favour of performance - which would be relatively safe when using the built-in aggregate functions. I'll commit to doing some hard testing on this, if we agree to implement it. Thanks, Best Regards, Simon Riggs ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
[HACKERS] Code documentation
Dear People, I was wondering if there are any interests or plans for documenting various functions in the code which currently are not documented. I would like to start this discussion to see if we want to do this. If I am the first one with this suggestion (I can't imagine) then I am very interested considering the options and future plans. Regards, Gevik ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [HACKERS] libpq and psql not on same page about SIGPIPE
Tom Lane wrote: Not really: it only solves the problem *if you change the application*, which is IMHO not acceptable. In particular, why should a non-threaded app expect to have to change to deal with this issue? But we can't safely build a thread-safe libpq.so for general use if it breaks non-threaded apps that haven't been changed. No. non-threaded apps do not need to change. The default is the old, 7.3 code: change the signal handler around the write calls. Which means that non-threaded apps are guaranteed to work without any changes, regardless of the libpq thread safety setting. Threaded apps would have to change, but how many threaded apps use libpq? They check their code anyway - either just add PQinitLib() or review (and potentialy update) their signal handling code if it match any of the gotchas of the transparent handling. -- Manfred -- Manfred ---(end of broadcast)--- TIP 8: explain analyze is your friend
[HACKERS] Code documentation
Dear People, I was wondering if there are any interests or plans for documenting various functions in the code which currently are not documented. I would like to start this discussion to see if we want to do this. If I am the first one with this suggestion (I can't imagine) then I am very interested considering the options and future plans. Regards, Gevik ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: Please release (was Re: [HACKERS] nodeAgg perf tweak)
Tom Lane wrote: "Andrew Dunstan" <[EMAIL PROTECTED]> writes: I've raised this before, but would like to suggest again that there might be virtue in branching earlier in the dev cycle - maybe around the time of the first beta. Given the amount of patching that's gone on, branching 8.1 earlier would have meant a great deal more work for the committers, in the form of double-patching stuff. And I don't know about the other committers, but I've certainly had no spare bandwidth for reviewing or applying 8.1-cycle patches anyway. So I think we made the right move to delay the branch. Core hasn't really talked about the point yet, but I suspect we'll make the branch after 8.0RC1 appears (which hopefully will be Real Soon). I do understand. Really. It just would be nice not to have development work queued for months every release cycle. But limited resources as always ... cheers andrew ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] libpq and psql not on same page about SIGPIPE
Tom Lane wrote: > Manfred Spraul <[EMAIL PROTECTED]> writes: > > Tom Lane wrote: > >> Not really: it only solves the problem *if you change the application*, > >> which is IMHO not acceptable. > > > No. non-threaded apps do not need to change. The default is the old, 7.3 > > code: change the signal handler around the write calls. Which means that > > non-threaded apps are guaranteed to work without any changes, regardless > > of the libpq thread safety setting. > > Hmm, so you propose that a thread-enabled library must contain both code > paths and choose between them on the fly? That seems like the worst of > all possible worlds --- it's not backwards compatible, it's therefore > unsafe, it's slow, *and* it'll be #ifdef hell to read. > > On a platform that has pthread_sigmask, ISTM we can use that > unconditionally and it'll work whether the calling app is threaded or > not. We only fall back to the pqsignal method if we aren't supporting > threads. There's no need for a runtime test nor for an API change. Agreed. Manfred, I guess the big question is why not use something that is automatic like I just applied? Now that the patch is in, would someone run some threaded performance tests and see if those pg_*_sigpipe routines are causing any performance problems. -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [HACKERS] libpq and psql not on same page about SIGPIPE
Manfred Spraul <[EMAIL PROTECTED]> writes: > Tom Lane wrote: >> Not really: it only solves the problem *if you change the application*, >> which is IMHO not acceptable. > No. non-threaded apps do not need to change. The default is the old, 7.3 > code: change the signal handler around the write calls. Which means that > non-threaded apps are guaranteed to work without any changes, regardless > of the libpq thread safety setting. Hmm, so you propose that a thread-enabled library must contain both code paths and choose between them on the fly? That seems like the worst of all possible worlds --- it's not backwards compatible, it's therefore unsafe, it's slow, *and* it'll be #ifdef hell to read. On a platform that has pthread_sigmask, ISTM we can use that unconditionally and it'll work whether the calling app is threaded or not. We only fall back to the pqsignal method if we aren't supporting threads. There's no need for a runtime test nor for an API change. regards, tom lane ---(end of broadcast)--- TIP 3: 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] nodeAgg perf tweak
Neil Conway <[EMAIL PROTECTED]> writes: > ISTM it would be reasonable to mandate that aggregate authors return one > of three things from their state transition functions: > (a) return the previous state value > (b) return the "next data item" value > (c) return some other value; if by a pass-by-reference type, allocated > in CurrentMemoryContext > In the case of (b), we need to copy it in advance_transition_function() > to ensure it survives to the next invocation of the state transition > function, but that should be doable. For both (a) and (c) we can assume > the value has been allocated in the per-1000-rows-transition-function > temporary context, and thus we need only copy it when we reset that > context. Well, (1) I'm uncomfortable with "mandating" that aggregate functions do anything special, and (2) I think you lose much of the performance benefit as soon as you have to distinguish cases (b) and (c). Ideally you would use MemoryContextContains for this, but that doesn't work reliably on pointers that point to fields of a tuple. I like the approach shown in my prototype patch better, because it doesn't create any backwards-compatibility issues for existing aggregate functions; instead individual aggregates may be rewritten to avoid palloc's. (In fact, you can get to a zero-pallocs-per-cycle condition, rather than reducing from two to one which is the most that the approach you suggest could save.) > I can reproduce the performance improvement with the patch you sent (I > can repost numbers if you like, but your patch and mine resulted in > about the same performance when I quickly tested it). Hmph. I'll have to repeat my test and figure out why I failed to see much benefit. I had sort of abandoned it in disgust after not getting results, but obviously I shoulda dug deeper. regards, tom lane ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
Re: [HACKERS] readline/libedit selection
Kris Jurka <[EMAIL PROTECTED]> writes: > This recent change to readline/libedit selection isn't quite right. If you see a problem you'll have to give more details ... > It doesn't link in libtermcap with libedit which leads to: Certainly it tries that. > checking for readline.h... no > configure: error: readline header not found This is a header failure, not a library failure. > And in config.log: > configure:5987: gcc -o conftest -O2 -Wall -Wmissing-prototypes > -Wpointer-arith -fno-strict-aliasing conftest.c -ledit -lcrypt -lresolv > -lcompat -lm -lutil >&5 > /usr/lib/libedit.so: undefined reference to `tgetnum' > /usr/lib/libedit.so: undefined reference to `tgoto' > /usr/lib/libedit.so: undefined reference to `tgetflag' > /usr/lib/libedit.so: undefined reference to `tputs' > /usr/lib/libedit.so: undefined reference to `tgetent' > /usr/lib/libedit.so: undefined reference to `tgetstr' This would be expected at the first probe, but surely it's not the only probe. Reading between the lines, I wonder if your problem is that your copy of editline puts its headers in include/readline rather than include/editline? regards, tom lane ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [HACKERS] lwlocks and starvation
OK, either you have to own the issue or I have to add something to the TODO list. --- Neil Conway wrote: > On Wed, 2004-12-01 at 21:51 -0500, Bruce Momjian wrote: > > Neil, where are we on this? Should we add comments? Add a TODO? A patch? > > I'm not sure what the right resolution is. As I said, I don't think it's > wise to apply a patch that could have a significant impact on > performance without (a) testing its performance effect and/or (b) having > any evidence that the problem it addresses actually effects anyone in > the real world. I'll try to run some benchmarks when I get a chance. > > I wrote up most of a patch to implement the "wake up all shared wakers > on LWLockRelease()" behavior to see how that would change performance, > but the patch has a subtle bug in it that I can't seem to find (I've > attached it -- comments welcome). > > Certainly if we decide to leave things as they are I think we ought to > document why the behavior is intentional, but I don't think we have > enough data to make that decision yet. > > -Neil > [ Attachment, skipping... ] > > ---(end of broadcast)--- > TIP 4: Don't 'kill -9' the postmaster -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [HACKERS] libpq and psql not on same page about SIGPIPE
Manfred Spraul wrote: > Tom Lane wrote: > > >Not really: it only solves the problem *if you change the application*, > >which is IMHO not acceptable. In particular, why should a non-threaded > >app expect to have to change to deal with this issue? But we can't > >safely build a thread-safe libpq.so for general use if it breaks > >non-threaded apps that haven't been changed. > > > > > > > No. non-threaded apps do not need to change. The default is the old, 7.3 > code: change the signal handler around the write calls. Which means that > non-threaded apps are guaranteed to work without any changes, regardless > of the libpq thread safety setting. > Threaded apps would have to change, but how many threaded apps use > libpq? They check their code anyway - either just add PQinitLib() or > review (and potentialy update) their signal handling code if it match > any of the gotchas of the transparent handling. So without the call we do the old non-threaded version of the code. Yea, we could do that, but I think the most recent patch is clearer. -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
