Re: [HACKERS] Too-many-files errors on OS X
Larry Rosenman wrote: I had to hack on the code some more for FreeBSD: (the realloc call needed the multiplication). I ran this same code on UnixWare. I feel like a moron, having missed that. Probably explains the bad file number error I was getting on AIX, too... -- Kevin Brown [EMAIL PROTECTED] ---(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] Why hash indexes suck
We could safely sort on the hash value, but I'm not sure how effective that would be, considering that we're talking about values that already hashed into the same bucket --- there's likely not to be very many distinct hash values there. I think we can safely put that on the todo list. The existing hash algorithm is very good. So I would on the contrary beleive that only a few keys share a hash value per pagesized bucket. For the equal keys case it does not matter since we want all of the rows anyways. For the equal hash value case it would probably be best to sort by ctid. TODO ?: order heap pointers inside hash index pages by hash value and ctid Andreas ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [HACKERS] CREATE DATABASE on the heap with PostgreSQL?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 jihuang wrote: | May Users forcely assign a table / database / cluster storage in RAM | purely ? NO. | or a in-directly-way , like making a RAM-Disk-Device and assign this | device as a postgreSQL cluster? YES. | I think this feature will push a lot High-Performance usage , | any suggestion ? I don't think you'll obtain this performance increase. You can write your own script that before postgres start: 1) Create the RAM disk 2) Copy the table in memory 3) Create the link between the old location to the new one and after stop postgres: 1) copy the table from RAM to DISK Regards Gaetano Mendola -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.4 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFAxDC07UpzwH2SGd4RAm3KAJ9HFgvTSqXSGCh3Xx2n6+Mfqb7AcQCgzWht CeFGnUTQrD9AWOTvwdkVr0A= =evpH -END PGP SIGNATURE- ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [HACKERS] Heads up: 7.3.6 and 7.4.2 coming soon
Tom Lane [EMAIL PROTECTED] writes: So, if you've got any fixes you wanted to get into those branches, time to get on it. I just wanted to note that IMHO a fix for the PL/PgSQL crash in 7.4.1 and HEAD (not sure about 7.3.x) that Chris Campbell recently reported should definitely be included in 7.4.2. If the bug is present in 7.3.x, it might also be worth backpatching. I'm happy to review apply the patch Chris C. included with his bug report, but due to a lack of free time I won't be able to get around to it before Friday -- if you or anyone else wants to get it done before then you're more than welcome to. Cheers, Neil ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [HACKERS] serverlog function
Tom Lane wrote: Andreas Pflug [EMAIL PROTECTED] writes: For adminstrator's convenience, I'd like to see a function that returns the serverlog. What do you mean by returns the serverlog? Are you going to magically recover data that has gone to stderr or the syslogd daemon? If so, how? And why wouldn't you just go and look at the log file, instead? I'd like to see the serverlog even if I can't go and look at the log file, because I don't have file access to the server. Regards, Andreas ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [HACKERS] Postres dilemma
Tom Lane wrote: Joshua D. Drake [EMAIL PROTECTED] writes: Why are you running a vacuum every 45 seconds? Increase your fsm_pages and run it every hour. If I understood his description correctly, he's turning over 10% of a 500-row table every minute. So waiting an hour would mean 3000 dead rows in a 500-live-row table, which seems excessive. I'd agree with running a vacuum on this specific table every five minutes or so. Given that he is doing more than enough vacuums, I think that the problem is probably not table bloat, but index bloat (ie, from a constantly shifting range of live index keys, which pre-7.4 btrees didn't handle well at all). This is just speculation though, without proof as yet. Another information to know is if there are connection in the unfamous state: Idle in transaction. Is usefull if the OP show us the vacuum verbose output. Regards Gaetano Mendola ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Heads up: 7.3.6 and 7.4.2 coming soon
On Mon, 23 Feb 2004, Neil Conway wrote: Tom Lane [EMAIL PROTECTED] writes: So, if you've got any fixes you wanted to get into those branches, time to get on it. I just wanted to note that IMHO a fix for the PL/PgSQL crash in 7.4.1 and HEAD (not sure about 7.3.x) that Chris Campbell recently reported should definitely be included in 7.4.2. If the bug is present in 7.3.x, it might also be worth backpatching. I'm happy to review apply the patch Chris C. included with his bug report, but due to a lack of free time I won't be able to get around to it before Friday -- if you or anyone else wants to get it done before then you're more than welcome to. We're looking at a 7.3 for next Monday, so if you can do it over the weekend, that would be great ... Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email: [EMAIL PROTECTED] Yahoo!: yscrappy ICQ: 7615664 ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
[HACKERS] Failures with windows port
Hi, I checked out the windows port to play with. It compiled file but 'make check' produced attached regression diff. I am using the nightly snapshot. Is it too early to look at these failures or did I do something wrong? I was following usual ./configure;make procedure after installing mingw. Shridhar parallel group (13 tests): text varchar oid char name float4 int2 boolean int8 int4 float8 bit numeric boolean ... FAILED char ... FAILED name ... FAILED varchar ... FAILED text ... FAILED int2 ... FAILED int4 ... FAILED int8 ... FAILED oid ... FAILED float4 ... FAILED float8 ... FAILED bit ... FAILED numeric ... FAILED test strings ... FAILED test numerology ... FAILED parallel group (20 tests): lseg path time timetz circle comments reltime abstime point tinterval polygon box inet interval timestamp timestamptz date type_sanity oidjoins opr_sanity point... FAILED lseg ... FAILED box ... FAILED path ... FAILED polygon ... FAILED circle ... FAILED date ... FAILED time ... FAILED timetz ... FAILED timestamp... FAILED timestamptz ... FAILED interval ... FAILED abstime ... FAILED reltime ... FAILED tinterval... FAILED inet ... FAILED comments ... FAILED oidjoins ... FAILED type_sanity ... FAILED opr_sanity ... FAILED test geometry ... FAILED test horology ... FAILED test insert ... FAILED test create_function_1... ok test create_type ... FAILED test create_table ... ok test create_function_2... ok test copy ... ok parallel group (7 tests): create_aggregate create_operator triggers constraints vacuum inherit create_misc constraints ... FAILED triggers ... FAILED create_misc ... ok create_aggregate ... ok create_operator ... ok inherit ... FAILED vacuum ... FAILED parallel group (2 tests): create_view create_index create_index ... FAILED create_view ... FAILED test sanity_check ... FAILED test errors ... FAILED test select ... FAILED parallel group (18 tests): select_into select_having update transactions namespace case select_implicit select_distinct_on arrays union select_distinct random portals join aggregates hash_index btree_index subselect select_into ... ok select_distinct ... FAILED select_distinct_on ... FAILED select_implicit ... FAILED select_having... FAILED subselect... FAILED union... FAILED case ... FAILED join ... FAILED aggregates ... FAILED transactions ... FAILED random ... failed (ignored) portals ... FAILED arrays ... FAILED btree_index ... FAILED hash_index ... FAILED update ... FAILED namespace... FAILED test privileges ... FAILED test misc ... FAILED parallel group (5 tests): portals_p2 cluster foreign_key rules select_views select_views ... FAILED portals_p2 ... FAILED rules... FAILED foreign_key ... FAILED cluster ... FAILED parallel group (14 tests): copy2 truncate temp sequence rowtypes domain polymorphism rangefuncs limit plpgsql prepare conversion without_oid alter_table limit... FAILED plpgsql ... FAILED copy2... FAILED temp ... FAILED domain ... FAILED rangefuncs ... FAILED prepare ... FAILED without_oid ... FAILED conversion ... FAILED truncate ... FAILED alter_table ... FAILED sequence ... FAILED polymorphism ... FAILED rowtypes ... FAILED test stats... FAILED ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [HACKERS] serverlog function (log_destination file)
Andreas Pflug wrote: Tom Lane wrote: Andreas Pflug [EMAIL PROTECTED] writes: For adminstrator's convenience, I'd like to see a function that returns the serverlog. What do you mean by returns the serverlog? Are you going to magically recover data that has gone to stderr or the syslogd daemon? Hm, what I missed is that pg_ctl's -l parameter converts to a simple stderr redirection, and it's hardly possible to find out where it's going. This could be solved by a file log_destination option or a freopen(...,stderr) from a guc variable. Regards, 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] Slony-I goes BETA (possible bug)
I tend to agree with you that spurious SYNC's aren't the end of the world. The idea of using notify to tell the syncThread somthing happened is probably the right way to do it, but at this time a little invasive. We need more time to investigate how to avoid notice storms during high update activity on the master. Jan On 6/6/2004 2:33 PM, Jeff Davis wrote: On Sun, 2004-06-06 at 10:32, Jan Wieck wrote: You are right. The local slon node checks every -s milliseconds (commandline switch) if the sequence sl_action_seq has changed, and if so generate a SYNC event. Bumping a sequence alone does not cause this, only operations that invoke the log trigger on replicated tables do. Speaking of this, this would also mean that there is a gap between the last sl_action_seq bumping operation and the commit of that transaction. If the local slon will generate the sync right in that gap, the changes done in that transaction will not be replicated until the next transaction triggers another sync. I am not sure how to effectively avoid this problem without blindly creating SYNC events in a maybe less frequent interval. Suggestions? A couple thoughts occur to me: Spurious SYNCs might not be the end of the world, because if someone is using replication, they probably don't mind the unneeded costs of a SYNC when the database is not being used heavily. If it is being used heavily, the SYNCs will have to happen anyway. Also, it might be possibly to make use of NOTIFY somehow, because notifications only occur after a transaction commits. Perhaps you can issue a notify for each transaction that modifies a replicated table and slon could listen for that notification? That way, it wouldn't SYNC before the transaction commits and miss the uncommitted data. Regards, Jeff Davis -- #==# # It's easier to get forgiveness for being wrong than for being right. # # Let's break this rule - forgive me. # #== [EMAIL PROTECTED] # ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Failures with windows port
Shridhar Daithankar wrote: Hi, I checked out the windows port to play with. It compiled file but 'make check' produced attached regression diff. I am using the nightly snapshot. Is it too early to look at these failures or did I do something wrong? I was following usual ./configure;make procedure after installing mingw. We need more information. In particular, we would need to know . what version of Windows, Mingw, MSys . what is in your regression.diff (if you send it, you should probably zip it up first). cheers andrew ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] serverlog function (log_destination file)
Andreas Pflug [EMAIL PROTECTED] writes: Hm, what I missed is that pg_ctl's -l parameter converts to a simple stderr redirection, and it's hardly possible to find out where it's going. This could be solved by a file log_destination option or a freopen(...,stderr) from a guc variable. Any such patch would be rejected, because it would break the ability to pipe stderr into another program (such as logrotate). And what of the syslog case? 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] serverlog function
Andreas Pflug wrote: Tom Lane wrote: Andreas Pflug [EMAIL PROTECTED] writes: For adminstrator's convenience, I'd like to see a function that returns the serverlog. What do you mean by returns the serverlog? Are you going to magically recover data that has gone to stderr or the syslogd daemon? If so, how? And why wouldn't you just go and look at the log file, instead? I'd like to see the serverlog even if I can't go and look at the log file, because I don't have file access to the server. Understand. Unfortunately, we don't allow such functionality. The only solution I can think of is to use syslog and send the logs to a machine where you do have access. -- 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 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] serverlog function (log_destination file)
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Tom Lane Sent: 07 June 2004 14:30 To: Andreas Pflug Cc: PostgreSQL Development Subject: Re: [HACKERS] serverlog function (log_destination file) Andreas Pflug [EMAIL PROTECTED] writes: Hm, what I missed is that pg_ctl's -l parameter converts to a simple stderr redirection, and it's hardly possible to find out where it's going. This could be solved by a file log_destination option or a freopen(...,stderr) from a guc variable. Any such patch would be rejected, because it would break the ability to pipe stderr into another program (such as logrotate). And what of the syslog case? I see the problems with the existing mechanisms, but just to float an idea - what about adding a GUC variable that can be used to specify an amount of shared memory to use as a fifo area in which a copy of the log output is stored for return to clients that might want it (accessing it via internal functions)? Regards, Dave ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [HACKERS] serverlog function (log_destination file)
Tom Lane wrote: Andreas Pflug [EMAIL PROTECTED] writes: Hm, what I missed is that pg_ctl's -l parameter converts to a simple stderr redirection, and it's hardly possible to find out where it's going. This could be solved by a file log_destination option or a freopen(...,stderr) from a guc variable. Any such patch would be rejected, because it would break the ability to pipe stderr into another program (such as logrotate). And what of the syslog case? Might it be sensible to have pg_ctl write its log destination (if any) out to a file in the data dir? That plus the log_destination setting might provide enough info at least for some common cases. cheers andrew ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [pgsql-hackers-win32] [HACKERS] Failures with windows port
Andrew Dunstan wrote: Shridhar Daithankar wrote: Hi, I checked out the windows port to play with. It compiled file but 'make check' produced attached regression diff. I am using the nightly snapshot. Is it too early to look at these failures or did I do something wrong? I was following usual ./configure;make procedure after installing mingw. We need more information. In particular, we would need to know . what version of Windows, Mingw, MSys Windows 2000 Professional, MingW 3.1.0.1, MSys 1.0.10 . what is in your regression.diff (if you send it, you should probably zip it up first). http://www.hserus.net/~shridhar/regression.diffs.gz http://www.hserus.net/~shridhar/regression.out HTH Shridhar ---(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] serverlog function
Bruce Momjian wrote: Andreas Pflug wrote: I'd like to see the serverlog even if I can't go and look at the log file, because I don't have file access to the server. Understand. Unfortunately, we don't allow such functionality. The only solution I can think of is to use syslog and send the logs to a machine where you do have access. What I mean is not how to set up a log solution, but how to offer a convenient way for the windows spoiled admins who like to have a gui for all kind of stuff, and just wants to hit a button show server log, regardless of server location and platform type. This is a request that was recommended for pgadmin3. AFAICS, we have some alternatives: - try to grab the currently created files/syslog/eventlog. Seems hard to do, because we'd depend on additional external tools. - redirect stderr to a postgresql.conf known file. Disadvantage: breaks piping. - maintain a sharedMem for the latest messages. Disadvantage: limited space, no access to older entries after postmaster restart. - additional log_destination file. Disadvantage: Yet Another File besides the redirected stderr, but this seems a minor problem. Regards, 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: [pgsql-hackers-win32] [HACKERS] Failures with windows port
Shridhar Daithankar wrote: Andrew Dunstan wrote: Shridhar Daithankar wrote: Hi, I checked out the windows port to play with. It compiled file but 'make check' produced attached regression diff. I am using the nightly snapshot. Is it too early to look at these failures or did I do something wrong? I was following usual ./configure;make procedure after installing mingw. We need more information. In particular, we would need to know . what version of Windows, Mingw, MSys Windows 2000 Professional, MingW 3.1.0.1, MSys 1.0.10 . what is in your regression.diff (if you send it, you should probably zip it up first). http://www.hserus.net/~shridhar/regression.diffs.gz http://www.hserus.net/~shridhar/regression.out Uh, were did you get this snapshot? Hold old was it? These newline problems were fixed perhaps 2 weeks ago. -- 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] serverlog function (log_destination file)
Dave Page [EMAIL PROTECTED] writes: ... what about adding a GUC variable that can be used to specify an amount of shared memory to use as a fifo area in which a copy of the log output is stored for return to clients that might want it (accessing it via internal functions)? No, that's a nonstarter, because having the postmaster log into shared memory means that the postmaster probably goes down too anytime a backend crashes. The shared area would have to have a mutual-exclusion lock, and we definitely do not want the postmaster participating in any lock protocols. If I were trying to solve Andreas' problem, I'd pipe stderr to some program that stores recent log output in a file that I know the location of and can read from the hypothetical log-grabber function. Actually I don't see that there's any need to involve Postgres itself in this issue at all --- seems like the only agreement needed is between the GUI and the postmaster launching script about where the log file is. regards, tom lane ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [HACKERS] serverlog function
On Mon, Jun 07, 2004 at 16:06:53 +0200, Andreas Pflug [EMAIL PROTECTED] wrote: AFAICS, we have some alternatives: You could also pipe the logs to a program that writes them to a table in the database. As long as the logging level wasn't set so high that inserting the log entries was logged. This should be a fairly simple program to write and could be provided to people that wanted to provide this feature for their server. ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [HACKERS] serverlog function (log_destination file)
-Original Message- From: Tom Lane [mailto:[EMAIL PROTECTED] Sent: 07 June 2004 15:32 To: Dave Page Cc: Andreas Pflug; PostgreSQL Development Subject: Re: [HACKERS] serverlog function (log_destination file) If I were trying to solve Andreas' problem, I'd pipe stderr to some program that stores recent log output in a file that I know the location of and can read from the hypothetical log-grabber function. Actually I don't see that there's any need to involve Postgres itself in this issue at all --- seems like the only agreement needed is between the GUI and the postmaster launching script about where the log file is. Thanks Tom. I wonder if we (the pgAdmin team) finally need to bite the proverbial bullet and write a helper daemon that can allow access to logs as well as config files and pg_ctl etc. as an optional extra component. Regards, Dave. ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [pgsql-hackers-win32] [HACKERS] Failures with windows port
Bruce Momjian wrote: http://www.hserus.net/~shridhar/regression.diffs.gz http://www.hserus.net/~shridhar/regression.out Uh, were did you get this snapshot? Hold old was it? These newline problems were fixed perhaps 2 weeks ago. ftp://ftp.postgresql.org/pub/dev/postgresql-snapshot.tar.gz It is timestamped at 6/7/2004, 8:09 AM. Anyways, I will install flex and bison and use CVS. I was just being lazy to opt for a snapshot.. Shridhar ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [HACKERS] serverlog function (log_destination file)
Dave Page [EMAIL PROTECTED] writes: Thanks Tom. I wonder if we (the pgAdmin team) finally need to bite the proverbial bullet and write a helper daemon that can allow access to logs as well as config files and pg_ctl etc. as an optional extra component. Red Hat's RHDB group already did a fair amount of work on such a tool: see Control Center available from http://sources.redhat.com/rhdb/ IIRC it's all in Java and thus at least theoretically portable to Windows. At the moment Red Hat is devoting no resources to it (and so I think it's stuck in the 7.3 time frame) but I'd be very happy to see someone else pick it up and work on it. 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] serverlog function (log_destination file)
Tom Lane wrote: If I were trying to solve Andreas' problem, I'd pipe stderr to some program that stores recent log output in a file that I know the location of and can read from the hypothetical log-grabber function. Actually I don't see that there's any need to involve Postgres itself in this issue at all --- seems like the only agreement needed is between the GUI and the postmaster launching script about where the log file is. What if there's no file access (e.g. only db admin, not sys admin, no file sharing, firewalled with only 5432 port access or similar)? I'd like a solution that needs just enabling in postgresql.conf and a button in pgadmin3 (probably phppgadmin would follow soon), on any platform. Regards, Andreas ---(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] serverlog function (log_destination file)
Andreas Pflug [EMAIL PROTECTED] writes: What if there's no file access If you don't have any access to the machine then you are not really a DBA, you only play one on TV. You can't for example start and stop the postmaster remotely. So I don't have a lot of sympathy for the notion that the logs have to be externally accessible, and none whatever for the notion that this has to be possible in every configuration. regards, tom lane ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [pgsql-hackers-win32] [HACKERS] Failures with windows port
Shridhar Daithankar wrote:
Bruce Momjian wrote:
http://www.hserus.net/~shridhar/regression.diffs.gz
http://www.hserus.net/~shridhar/regression.out
Uh, were did you get this snapshot? Hold old was it? These newline
problems were fixed perhaps 2 weeks ago.
ftp://ftp.postgresql.org/pub/dev/postgresql-snapshot.tar.gz
It is timestamped at 6/7/2004, 8:09 AM.
Anyways, I will install flex and bison and use CVS. I was just being lazy to opt
for a snapshot..
That is certainly new enough. We added a MinGW workaround to fix a
problem with extra newlines coming from psql, but you might have a
configuration that doesn't need the workaround.
Do you need this line in psql/print.c?
#ifndef __MINGW32__
/* for some reason MinGW outputs an extra newline, so this supresses it */
fputc('\n', fout);
#endif
That might be the cause of your problem? If you have it try removing it and recompile.
--
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: [pgsql-hackers-win32] [HACKERS] Failures with windows port
Bruce Momjian wrote:
Shridhar Daithankar wrote:
Bruce Momjian wrote:
http://www.hserus.net/~shridhar/regression.diffs.gz
http://www.hserus.net/~shridhar/regression.out
Uh, were did you get this snapshot? Hold old was it? These newline
problems were fixed perhaps 2 weeks ago.
ftp://ftp.postgresql.org/pub/dev/postgresql-snapshot.tar.gz
It is timestamped at 6/7/2004, 8:09 AM.
Anyways, I will install flex and bison and use CVS. I was just being lazy to opt
for a snapshot..
That is certainly new enough. We added a MinGW workaround to fix a
problem with extra newlines coming from psql, but you might have a
configuration that doesn't need the workaround.
Do you need this line in psql/print.c?
#ifndef __MINGW32__
/* for some reason MinGW outputs an extra newline, so this supresses it */
fputc('\n', fout);
#endif
That might be the cause of your problem? If you have it try removing it and recompile.
No it is not. A quick #if 0...#endif around it and recompile produced 87
failures out of 95 test, one being ignored.
Leaving it for a full build as I am calling it a day. Will give it another go
tomorrow morning..
Shridhar
---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?
http://www.postgresql.org/docs/faqs/FAQ.html
Re: [pgsql-hackers-win32] [HACKERS] Failures with windows port
Shridhar Daithankar wrote:
Bruce Momjian wrote:
Shridhar Daithankar wrote:
Bruce Momjian wrote:
http://www.hserus.net/~shridhar/regression.diffs.gz
http://www.hserus.net/~shridhar/regression.out
Uh, were did you get this snapshot? Hold old was it? These newline
problems were fixed perhaps 2 weeks ago.
ftp://ftp.postgresql.org/pub/dev/postgresql-snapshot.tar.gz
It is timestamped at 6/7/2004, 8:09 AM.
Anyways, I will install flex and bison and use CVS. I was just being
lazy to opt for a snapshot..
That is certainly new enough. We added a MinGW workaround to fix a
problem with extra newlines coming from psql, but you might have a
configuration that doesn't need the workaround.
Do you need this line in psql/print.c?
#ifndef __MINGW32__
/* for some reason MinGW outputs an extra newline, so this
supresses it */
fputc('\n', fout);
#endif
That might be the cause of your problem? If you have it try removing
it and recompile.
No it is not. A quick #if 0...#endif around it and recompile produced
87 failures out of 95 test, one being ignored.
Leaving it for a full build as I am calling it a day. Will give it
another go tomorrow morning..
What you would need to test is not #ifdefing the whole thing out -
rather you would need to enable the fputc by removing the #ifndef and
#endif lines.
cheers
andrew
---(end of broadcast)---
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Case preserving - suggestions
Robert Treat wrote: On Sunday 06 June 2004 13:47, Shachar Shemesh wrote: Hi list, A postgresql migration I am doing (the same one for which the OLE DB driver was written) has finally passed the proof-of-concept stage (phew). I now have lots and lots of tidbits, tricks and tips for SQL Server migration, which I would love to put online. Is pgFoundry the right place? I understand that the code snippets section is not yet operative, but I would still love to put it online ASAP (i.e. - before I forget), and to have it all in one place. We have a couple of articles about sql server migration up on techdocs now, so that seems the most appropriate place for documenting the process you went through. Robert Treat We wrote a new data type (a tinyint replacement), that will not be part of postgresql any time soon. We need to put the code up somewhere. We wrote a perl script that takes the output of the database dump done by MS-SQL, and converts it into an SQL script for postgres (including yanking the data from the MS-SQL tables, and inlining it into the Postgresql script using copy). That needs to go somewhere. It is highly likely that people will find bugs, or want to make additions, to the above two, so source control seems like a necessary idea. In short, I think a pgFoundry project seems better suited for our needs than static documentation. Shachar -- Shachar Shemesh Lingnu Open Source Consulting http://www.lingnu.com/ ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] serverlog function (log_destination file)
Tom Lane wrote: Andreas Pflug [EMAIL PROTECTED] writes: What if there's no file access If you don't have any access to the machine then you are not really a DBA, you only play one on TV. However you may call me, I can think of many cases where I'd like to look at the server log, without wanting to change the configuration or start/stop the postmaster. The error message sent to the application might be lost, or an interference with another app might have caused troubles, so a collected log is fine for such cases, preferrably displayed by the same tool I'm tuning my queries with. What you're telling me is that people should have a telnet session to the linux box and tail /usr/data/pgsql/serverlog, while they're working with comfortable gui tools otherwise. Sound dissatisfying. The rhdb control center seems fine for a sysadmin-dbadmin who's going to install and reconfigure a machine, but I certainly don't want this for SQL centric work. And a Java GUI is a bad idea on win32 either... Regards, Andreas ---(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] Case preserving - suggestions
Shachar Shemesh wrote: Robert Treat wrote: On Sunday 06 June 2004 13:47, Shachar Shemesh wrote: Hi list, A postgresql migration I am doing (the same one for which the OLE DB driver was written) has finally passed the proof-of-concept stage (phew). I now have lots and lots of tidbits, tricks and tips for SQL Server migration, which I would love to put online. Is pgFoundry the right place? I understand that the code snippets section is not yet operative, but I would still love to put it online ASAP (i.e. - before I forget), and to have it all in one place. We have a couple of articles about sql server migration up on techdocs now, so that seems the most appropriate place for documenting the process you went through. Robert Treat We wrote a new data type (a tinyint replacement), that will not be part of postgresql any time soon. We need to put the code up somewhere. We wrote a perl script that takes the output of the database dump done by MS-SQL, and converts it into an SQL script for postgres (including yanking the data from the MS-SQL tables, and inlining it into the Postgresql script using copy). That needs to go somewhere. It is highly likely that people will find bugs, or want to make additions, to the above two, so source control seems like a necessary idea. In short, I think a pgFoundry project seems better suited for our needs than static documentation. Shachar Feel free to apply for a pgFoundry project - most are approved very quickly. cheers andrew ---(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] serverlog function
Andreas wrote: AFAICS, we have some alternatives: - try to grab the currently created files/syslog/eventlog. Seems hard to do, because we'd depend on additional external tools. - redirect stderr to a postgresql.conf known file. Disadvantage: breaks piping. - maintain a sharedMem for the latest messages. Disadvantage: limited space, no access to older entries after postmaster restart. - additional log_destination file. Disadvantage: Yet Another File besides the redirected stderr, but this seems a minor problem. Another alternative would be to add code to the admin tool to get the log via scp or a similar method. IMHO PostgreSQL is doing the right thing here by using the OS logging, and breaking that isn't a good idea when there are other ways to solve the problem. ---(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] serverlog function (log_destination file)
If I were trying to solve Andreas' problem, I'd pipe stderr to some program that stores recent log output in a file that I know the location of and can read from the hypothetical log-grabber function. Actually I don't see that there's any need to involve Postgres itself in this issue at all --- seems like the only agreement needed is between the GUI and the postmaster launching script about where the log file is. Thanks Tom. I wonder if we (the pgAdmin team) finally need to bite the proverbial bullet and write a helper daemon that can allow access to logs as well as config files and pg_ctl etc. as an optional extra component. It would certainly make things a lot easier for the box admin if you did this as extension functions in pg instead of a separate daemon (even if these are not installed in pg by default, but have to be installed manually. Better if they are included by default, of course, from the easy-to-admin perspective). Then it's just one set of firewall rules, one process to check if it's running, etc. Specifically about the logs, I still think there is a lot of value to being able to read the logs remotely even if you can't restart postmaster. Looking at the server logs can help you debug the database client (for example when the app won't give you the full error msg, but it goes in the server log). It won't help you if it's a postmaster problem (since you won't get to it), but there are a lot of other situations where it will. (This is, btw, how MSSQL does it at least - you can view the server log remotely if the server starts. If not, you'll have to go to the log viewer on the server) //Magnus ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] aliases, c in HAVING clause?
[EMAIL PROTECTED] (David Fetter) writes: I bumped across this several times, and am wondering what SQL99 and SQL200x have to say about column numbers or aliases in HAVING. SQL99 not only does not allow them in GROUP BY or HAVING, but it doesn't allow them in ORDER BY either, thereby eliminating the entire wart from the language. I doubt that SQL200x will reverse field on this decision. In retrospect it was an error for us to allow aliases in GROUP BY, as this has caused so much confusion about where they are legal. If it weren't for backwards-compatibility concerns, I'd vote for adopting the SQL99 definition (no aliases in any of these clauses). are there good reasons why the above shouldn't work? Well, you showed one: interpreting 2 2 as anything other than a constant expression is just plain weird. But the real reason why this is bogus is that it violates the fundamental conceptual model of how SELECT works. The SELECT output list is not supposed to be computed until after all the other steps are complete, and therefore it's improper to assume its results are available in GROUP BY or HAVING. regards, tom lane ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [HACKERS] Slony-I goes BETA (possible bug)
On Mon, 2004-06-07 at 06:20, Jan Wieck wrote: I tend to agree with you that spurious SYNC's aren't the end of the world. The idea of using notify to tell the syncThread somthing happened is probably the right way to do it, but at this time a little invasive. We need more time to investigate how to avoid notice storms during high update activity on the master. There was discussion a while back about improving notify, and one suggestion was to make it use shared memory so no disk writes are involved (I believe the current implementation uses a table somehow). If that was implemented, than we would have no problem with a notice storm, right? It wouldn't use much shared memory since the slon daemon can retrieve the notices just as fast as the backend can send them, right? Backtracking a little, I'm still wondering how exactly a replicated sequence is supposed to behave, do you have some comments about that? I don't understand exactly why it's useful. Regards, Jeff ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] CREATE DATABASE on the heap with PostgreSQL?
Gaetano Mendola [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED]... If you access a table more frequently then other and you have enough RAM your OS will mantain that table on RAM, don't you think ? BTW if you trust on your UPS I'm sure you are able to create a RAM disk and place that table in RAM. Regards Gaetano Mendola RAMdisks still need a hard disk drive to operate. I am talking here about entirely diskless configurations. Well, maybe as I suspected there is no technical explanation why this design decision has been made. When I have more time I will run a bechmark to check to which extent it does make a difference. I mean running the application from RAM and letting the DBMS know about it instead of letting the OS figure it out. ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
[HACKERS] Tool to read data files
Are there any tools available to dump datafiles for debugging purposes? I think there is a corruption problem in Postgresql 7.4.2 with and only with the Ltree module. I've seen broken ltree entries in my database, and there were no updates on the tables. This occurs once or twice a day, at random times. The value of the ltree attribute is not junk as I would expect with a corruption, but some parts are missing. I've wrote some sort of watchdog and waited until the problem occured, then copied the datafile to a different location. Are there any tools available for debugging such problems? Even a simple dump to stdout would be helpful. Thanks! Regards, Mario Weilguni p.s. I've checked the hardware before going online with that database, RAM is definitly ok, and the rest of the hardware should work fine as well. The table was vacuumed full, but vacuum did not report any errors. ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] [GENERAL] CREATE DATABASE on the heap with PostgreSQL?
Albretch wrote: Gaetano Mendola [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED]... If you access a table more frequently then other and you have enough RAM your OS will mantain that table on RAM, don't you think ? BTW if you trust on your UPS I'm sure you are able to create a RAM disk and place that table in RAM. Regards Gaetano Mendola RAMdisks still need a hard disk drive to operate. I am talking here about entirely diskless configurations. I asked this question not long after 7.4 debuted. In general the basic answer I got was: 1) Especially with 7.5 and the ARC, small tables which can be stored entirely in RAM and are frequently used will end up being fully cached there anyway. Presumably, complex updates would still cause I/O bottlenecks, but read performance should not be any different than for a RAM-based table. 2) Given the upcoming release of ARC, there is no real reason to consider having a table reside only in memory (doing so may impact the performance of other tables in the database as well). 3) HEAP tables are not planned. PostgreSQL is focused on data integrity and reliability, and this is a can of worms regarding these topics which is best left untouched. Best Wishes, Chris Travers Metatron Technology Consulting ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [HACKERS] Is indexing broken for bigint columns?
-Original Message- From: Nigel J. Andrews [mailto:[EMAIL PROTECTED] Sent: Tuesday, February 24, 2004 3:33 PM To: Dann Corbit Cc: PostgreSQL-development Subject: Re: [HACKERS] Is indexing broken for bigint columns? Dann, Did you mean to forward this to -hackers? Yes. Was my posting inappropriate? Is there a way to reply on that site? (My lynx didn't show me a link that looked likely in the neighbourhood of that glib comment). Scroll to the bottom, and there is a response form. On Tue, 24 Feb 2004, Dann Corbit wrote: http://www.phpbuilder.com/columns/smith20010821.php3?page=3 -- Nigel Andrews ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
[HACKERS] vacuumdb: vacuuming of database testdonors failed: ERROR: invalid memory alloc request size 3221225472
Hello, Using community PostgreSQL 7.4.2 I have tried to vacuum this database to no avail. Everytime I try I get this referenced errror. I even dumped and restored to a new database an get the same error. I was also able to reindex the database but no help there. Not much to say on google... Databaes is about 50 megs of mostly text. Less than 5 megs in large objects. Hardware/OS is: Dual Athlon MP 2800 3 Gig ECC Ram 3Ware Hardware Raid 7 SATA Drives in a RAID 10 (1 hot spare). Fedora Core 1 Any thoughts? Sincerely, Joshua D. Drake -- Command Prompt, Inc., home of Mammoth PostgreSQL - S/ODBC and S/JDBC Postgresql support, programming shared hosting and dedicated hosting. +1-503-667-4564 - [EMAIL PROTECTED] - http://www.commandprompt.com PostgreSQL Replicator -- production quality replication for PostgreSQL ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] vacuumdb: vacuuming of database testdonors failed:
Without more information about what the data is, there is really no way to even guess. Can you make the database available so it can be looked at? Hello, Using community PostgreSQL 7.4.2 I have tried to vacuum this database to no avail. Everytime I try I get this referenced errror. I even dumped and restored to a new database an get the same error. I was also able to reindex the database but no help there. Not much to say on google... Databaes is about 50 megs of mostly text. Less than 5 megs in large objects. Hardware/OS is: Dual Athlon MP 2800 3 Gig ECC Ram 3Ware Hardware Raid 7 SATA Drives in a RAID 10 (1 hot spare). Fedora Core 1 Any thoughts? Sincerely, Joshua D. Drake -- Command Prompt, Inc., home of Mammoth PostgreSQL - S/ODBC and S/JDBC Postgresql support, programming shared hosting and dedicated hosting. +1-503-667-4564 - [EMAIL PROTECTED] - http://www.commandprompt.com PostgreSQL Replicator -- production quality replication for PostgreSQL ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
[HACKERS] sequences and addval('myseq', value)
I have an idea, let me know what you all think.
rather than do:
select sum( field) from largetable
I want (need) to be able to do something like this:
select setval('myseq', select sum(field) from largetable);
and in a trigger
SELECT addval('myseq', field_size);
I have already created this function and am testing it. I basically took
nextval and assigned byval to a parameter and removed the value
caching code.
Anyway, I'm not quite getting the idea of caching sequence values. I
understand the performance benefits, but it seems problematic across
multiple backends, almost ensuring holes in the sequence of numbers.
---(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] Tool to read data files
Mario Weilguni [EMAIL PROTECTED] writes: Are there any tools available to dump datafiles for debugging purposes? I often use pg_filedump, available here: http://sources.redhat.com/rhdb/ I think there is a corruption problem in Postgresql 7.4.2 with and only with the Ltree module. Could be; I doubt anyone has tested ltree harder than running its regression test for quite awhile. It could be suffering bit rot from some of the changes in 7.4 (or even an earlier release). regards, tom lane ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
