Re: [HACKERS] [BUGS] pg_service.conf ignores dbname parameter
Bruce Momjian wrote: I thought he was more concerned about removing envirnment variables that have to be tuned for each user. Let's see how he responds. Think about a web server talking to a database server. Where do you set the environment variables for that? Or where is the home directory for that? And then remember issues of su vs. su -. Environment variables are error prone when they contain information that is essential for running the program correctly. ---(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] Issue with Linux+Pentium SMP Context Switching
Two suggestions.. 1. Patch linux kernel for HT aware scheduler. 2. Try running Xeons in HTdisabled modes. See if that helps. I would say using 2.6 on it is recommended anyways.. If possible of course.. I would avoid 2.6 on a production machine. 2.6 breaks alot (not as in a bad thing, but as in not really compatible with) of things. Wait until distribution vendors are shipping production with it. Sincerely, Joshua Drake Shridhar ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster -- Command Prompt, Inc., home of Mammoth PostgreSQL - S/ODBC and S/JDBC Postgresql support, programming shared hosting and dedicated hosting. +1-503-222-2783 - [EMAIL PROTECTED] - http://www.commandprompt.com Editor-N-Chief - PostgreSQl.Org - http://www.postgresql.org
Re: [HACKERS] Why isn't DECLARE CURSOR ... FOR UPDATE supported?
Tom Lane wrote:
Rod Taylor [EMAIL PROTECTED] writes:
On Thu, 2003-12-18 at 10:20, Tom Lane wrote:
Is there any good reason for this restriction?
The help implies you can.
DECLARE name [ BINARY ] [ INSENSITIVE ] [ [ NO ] SCROLL ]
CURSOR [ { WITH | WITHOUT } HOLD ] FOR query
[ FOR { READ ONLY | UPDATE [ OF column [, ...] ] } ]
Hmm. Actually that is describing the SQL spec's syntax for DECLARE
CURSOR, in which you can name specific *columns* not tables as being
updatable through the cursor. Now that I think about it, the error
check is probably there to catch anyone who writes FOR UPDATE OF
column expecting to get the SQL spec behavior.
I'm not sure whether anyone is planning to try to converge our notion of
FOR UPDATE with the spec's. If that is going to happen someday, it'd
probably be best not to introduce directly conflicting behavior into
DECLARE CURSOR. Oh well...
regards, tom lane
Do I understand from what you are saying that we are pretty close to
being able to perform write operations on cursors? Can we, in the mean
while, lock entire rows for that purpose?
I'm having a deployment of Postgresql where the application is using MFC
CRecordset. It appears, from superficial inspection, that it uses the
same type of cursor, whether it actually intends to update it or not. I
have also not found any convinent way in MFC to tell it which rows one
intends to update. As such, I suspect it is prepared to update them all
(disclaimer - I have not tested it myself, and may speak utter bullshit
here).
The problem is that, at the moment, the ODBC driver is emulating cursors
by using the OID field, and performing seperate queries per row. This
has two significant problems:
A. One cannot create a read-write cursor for views, as views do not have
an OID field.
B. The performance for fetching 30,000 rows is terrible.
I'm looking for a way to solve these issues (especially the second one).
I may have a solution inside the ODBC driver itself (better cursors
emulation - a performance/memory tradeoff), but I would really prefer a
true solution to the problem.
My question is this - how terrible will it be if we did not lock each
individual column, but instead locked entire rows (as Tom suggested in
the begining of this thread)?
Shachar
--
Shachar Shemesh
Open Source integration consulting
Home page resume - http://www.shemesh.biz/
---(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] Why isn't DECLARE CURSOR ... FOR UPDATE supported?
Shachar Shemesh [EMAIL PROTECTED] writes: Do I understand from what you are saying that we are pretty close to being able to perform write operations on cursors? No, I didn't say that. regards, tom lane ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] [GENERAL] Backwards index scan
Tom Lane [EMAIL PROTECTED] writes: Dmitry Tkach [EMAIL PROTECTED] writes: This is because there are *lots* (a few million) of matches for x=10, and _bt_first () scans through them *all* sequentually to get to the last one. It's not a bug, but I agree that _bt_first can be inefficient if there are lots of matching keys. I think what we'd want is variant versions of _bt_search and _bt_binsrch that locate the first entry greater than the specified target key, rather than the first entry greater than or equal to it. Given such positioning, all the _bt_first cases that involve stepping over more than one entry could be improved to require no more than one step. I have committed a fix into 7.5devel to do this properly. I think this is the last case wherein btree is unnecessarily inefficient for large numbers of equal keys. 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] [pgsql-advocacy] PostgreSQL speakers needed for OSCON 2004
Alternately, maybe it's time to try to get the fundraising operation into gear. Greg? What's our status for setup? My goal is to have everything done by January 31st. Speaking of fund raising, SourceForge has just started a 'donations' system whereby people can donate money to projects. Maybe you want to enable it on the PostgreSQL project. We at the phpPgAdmin project don't really have any use for donations, but we could just forward them all through to the PostgreSQL project? Would this be at all useful? Chris ---(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] [pgsql-advocacy] PostgreSQL speakers needed for OSCON 2004
On Sun, 21 Dec 2003, Christopher Kings-Lynne wrote: Alternately, maybe it's time to try to get the fundraising operation into gear. Greg? What's our status for setup? My goal is to have everything done by January 31st. Speaking of fund raising, SourceForge has just started a 'donations' system whereby people can donate money to projects. Maybe you want to enable it on the PostgreSQL project. We at the phpPgAdmin project don't really have any use for donations, but we could just forward them all through to the PostgreSQL project? Would this be at all useful? Someone mentioned that the 'fees' were relatively high though ... that you lose a fair amount off the top *to* Sourceforge? 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] [pgsql-advocacy] PostgreSQL speakers needed for OSCON 2004
Christopher Kings-Lynne [EMAIL PROTECTED] writes: Speaking of fund raising, SourceForge has just started a 'donations' system whereby people can donate money to projects. Maybe you want to enable it on the PostgreSQL project. Uh ... there is no PostgreSQL project on SourceForge, AFAIK. regards, tom lane ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [HACKERS] [pgsql-advocacy] PostgreSQL speakers needed for OSCON 2004
[EMAIL PROTECTED] (Tom Lane) wrote: Christopher Kings-Lynne [EMAIL PROTECTED] writes: Speaking of fund raising, SourceForge has just started a 'donations' system whereby people can donate money to projects. Maybe you want to enable it on the PostgreSQL project. Uh ... there is no PostgreSQL project on SourceForge, AFAIK. Uh, you might be surprised http://pgsql.sourceforge.net/ http://sourceforge.net/projects/pgsql/ -- (format nil [EMAIL PROTECTED] cbbrowne ntlug.org) http://cbbrowne.com/info/sgml.html Rules of the Evil Overlord #43. I will maintain a healthy amount of skepticism when I capture the beautiful rebel and she claims she is attracted to my power and good looks and will gladly betray her companions if I just let her in on my plans. http://www.eviloverlord.com/ ---(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] [GENERAL] Temporary tables and miscellaneous schemas
Tom Lane wrote: Bruce Momjian [EMAIL PROTECTED] writes: Tom Lane wrote: Oh, okay. I would not object to suppressing pg_temp_NNN schemas from the \dn display. That isn't what this patch does, however. OK. I read the TODO and it says only: * Have psql \dn show only visible schemas using current_schemas() That TODO was your interpretation of the discussion; I'm not sure anyone else bought into it. so that's what I did, but I think now I have to add a test so only non-visible temp schemas are suppressed, You are complicating something that could be simple. Why not just suppress schemas named 'pg_temp_XXX', period? I don't see any strong reason to display them, whether they are your own backend's temp schema or not. Arguably, the fact that temp tables are kept in a special schema is an implementation detail that most people won't care about. And there is no data that \dn can show that is really important for temp schemas. The owner column is at best misleading... OK, unless someone objects, I will head in that direction. -- 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
[HACKERS] 7.4.1 release notes updated
I have updated the 7.4.1 release notes so it has all the current changes listed. We have addressed all open 7.4.1 items so we are nearing 7.4.1 release time. -- 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
[HACKERS] Current Win32 port status
Hi all, just a small note to anyone who is interested in the status of this port. Firstly, the fork/exec changes are coming along well. The first patch, for fork/exec'ing of backends has been accepted and applied. A second patch, for fork/exec'ing of the remainder of the postgres process has just been submitted for review. Two patches (which are essentially already completed) will follow this; the first to allow some further rearrangement of the postmaster fork/execs in preparation for the Win32 CreateProcess calls, and the final patch will place the actual CreateProcess calls into the code-base. It is reasonable to expect that we will have this changes in place within a few weeks. At that point, we will be within striking distance of a Win32 port. The only remaining barriers to a running, albeit imperfect, implementation are: * signals (non-trivial, to say the least, but encouraging to see discussion occurring in this regard), * a workable pipe replacement * possible bootstrap issue between semaphores + shared memory [these, and other remaining issues to perfect the port, are listed in greater detail on http://momjian.postgresql.org/main/writings/pgsql/win32.html] FWIW, having kludged up some quick + dirty workarounds to the above points, I have actually had postgres running natively on my Win2K box, which I trust is an encouraging sign (to say the least) to anyone hanging out for this port... Merry Chirstmas all, Claudio --- Certain disclaimers and policies apply to all email sent from Memetrics. For the full text of these disclaimers and policies see a href=http://www.memetrics.com/emailpolicy.html;http://www.memetrics.com/em ailpolicy.html/a ---(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
