Re: [HACKERS] 2PC: discussion in comp.arch
From Bill Todd's post: This is the simple 'two-phase commit, presumed-abort' mechanism. It has no problems guaranteeing distributed consistency, but does suffer from the problem that if the coordinator *never* recovers some of the other nodes may be left 'in doubt' about the fate of the transaction. In practice, with replicated data 'never' recovering is virtually impossible, but just waiting for some human to replace failed hardware can stall things enough that a more complex 'three-phase commit' model exists where nodes need not wait for the coordinator to recover. Another manner in which that issue is addressed is by having a 'back-up' coordinator to which coordination responsibility can be transferred; a third is by having a robust coordinator - e.g., whose storage can be 'failed over' to another separate system which can continue operation. This is exactly what some of us have been saying here. As long as the co-ordinator is capable of recovering, there is no danger of in-doubt transactions stalling a subordinate indefinitely. While I'm not sure if any database system implements 3PC, certainly 2PC-PA is implemented by most database vendors (and is part of the XA standard). Presumed Abort (PA) is preferred to Presumed Commit (PC) because PA involves less log sync operations for the common case of read-only transactions. 2PC certainly has various real-world applications, as with the integration of message-queueing systems. Alternatively, if there is a plan to support serious federated capabilities within pgsql (by expanding the current dblink prototype for instance) the issue of 2PC will come into play if pgsql supports remote write operations. Anyways, this is all moot if integration with enterprise transaction systems is not an important goal of pgsql. If there is no explicit need for such features amongts users of pgsql, I see no need in polluting the codebase with unnecessary complexity. Let's just not confuse no need for XYZ functionality with XYZ functionality is lame and can never work in practice. -- Pip-pip Sailesh http://www.cs.berkeley.edu/~sailesh ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [HACKERS] dblink for Oracle - question ...
On Monday 23 June 2003 21:54, Hans-Jürgen Schönig wrote: A few days ago I have posted a pre-beta version of dblink_ora which is supposed to solve some problems we had here at Cybertec (getting data from an Oracle DB and merge it with PostgreSQL). I have implemented a simple piece of code (more proof of concept than production). Since I have not got too much response (just one posting off list) I expect that there are not too many people who are in need of this feature. Am I right or is there somebody out there who wants to see it in contrib? If there is serious interest in this feature we'd make it work with PostgreSQL's build system and we'd add some documentation as well as some more code. If not we will keep using it for internal purposes. I suggest you make the code available from a web site and let techdocs.postgresql.org point to it. That way it will be availble for most of the people even if it does not make into contrib immediately. Shridhar ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] [GENERAL] PlPython
elein kirjutas T, 24.06.2003 kell 00:42: There is a realtively clean hack one can use to convert plpython functions to plpythonu manually - just rename the language for the time of loading functions - do as superuser update pg_language set lanname = 'plpython' where lanname = 'plpythonu'; LOAD YOUR Pl/Python FUNCTIONS ; update pg_language set lanname = 'plpythonu' where lanname = 'plpython'; PS: I've built and tested the plpython patch against 7.3.2 and am happy it does not affect the features I count on. As it should. The untrusted language gives you *more* power, not less. The untrusted status means that the user has to be trusted to use that much power. Hannu ---(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] vacuum bug
Hi, I was running a long-running vacuum full, and then halfway thru that our background vacuum process started. As well as this, there was light activity on a users table from which vacuum full was removing 9 rows. Then vacuum full failed after a while: ERROR: simple_heap_update: tuple concurrently updated 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] Dllist public/private part
Tom Lane [EMAIL PROTECTED] wrote: Mendola Gaetano [EMAIL PROTECTED] writes: I'm improving the Dllist in these direction: AFAIR, catcache.c is the *only* remaining backend customer for Dllist, and so any improvement for Dllist that breaks catcache is hardly an improvement, no? 1) Avoid if statements in insertion/remove phase, for instance now the AddHeader appear like this: shrug ... unless you can convert DLAddHead into a inline macro, I doubt there'll be any visible performance difference. 2) Not using a malloc but using a special malloc that not perform a malloc for each request but do a BIG malloc at first request... It would make more sense to migrate Dllist to use palloc. That's not compatible with its use in frontend libpq; I've been speculating about splitting off libpq to have a separate implementation instead of trying to share code. I believe libpq only uses Dllist for the pending-notify-events list, for which the code is poorly optimized anyway (we don't need a doubly-linked list for that). This mean that is waste of time work on dllist. I seen that exist a TODO list about features, exist a list about: code to optimize ? Regards Gaetano Mendola ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
[HACKERS] Index expressions: how to recreate
I noticed the new expression functionality of indices and while implementing them in pgadmin3 was wonderingnow to extract the definition from the catalog. Consider an index that looks like this: CREATE INDEX foo ON bar (numcol, length(txtcol), intcol2, length(txtcol2)) Looking at pg_index: indkey will contain 1 0 4 indclass contains 1988 1978 1978 1978 (numeric, int, int, int) pg_get_expr(indexprs, indrelid) will deliver (length((txtcol)::text) AND (length(((txtcol2)::text))) indclass contains what I'd expect, but indkey shows only 3 columns and/or expressions. So I'd recreate the index as being defined as CREATE INDEX foo ON bar (numcol, (length(txtcol) AND length(txtcol2)), intcol2) which obviously isn't correct (and wouldn't execute either, AND with int operands) Why is indexprs not a text array containing , length(txtcol), , length(txtcol2) ? Regards, Andreas ---(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] Is Patch Ok for deferred trigger disk queue?
Tom Lane wrote: Stephan Szabo [EMAIL PROTECTED] writes: As a side question, it looks to me that the code stores the first trigger records in memory and then after some point starts storing all new records on disk. Is this correct? I'd wonder if that's really what you want in general, since I'd think that the earliest ones are the ones you're least likely to need until end of transaction (or set constraints in the fk case) whereas the most recent ones are possibly going to be immediate triggers which you're going to need as soon as the statement is done. Good point. It would be better to push out stuff from the head of the queue, hoping that stuff near the end might never need to be written at all. regards, tom lane Hmmm I see your point. I will change the patch to write the head to disk and reenter when the development branch splits off. Also I've noticed that there is an fd.h which has file routines which I should be using rather than the stdio routines. I will also clean up those errors. Thank you, - Stuart ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] dblink for Oracle - question ...
On Mon, 23 Jun 2003, Hans-Jürgen Schönig wrote: A few days ago I have posted a pre-beta version of dblink_ora which is supposed to solve some problems we had here at Cybertec (getting data from an Oracle DB and merge it with PostgreSQL). I have implemented a simple piece of code (more proof of concept than production). Since I have not got too much response (just one posting off list) I expect that there are not too many people who are in need of this feature. Am I right or is there somebody out there who wants to see it in contrib? If there is serious interest in this feature we'd make it work with PostgreSQL's build system and we'd add some documentation as well as some more code. If not we will keep using it for internal purposes. I'm interested. Am I the guy from off list though? :-) Whether it's in /contrib or on gborg is no biggie for me though. ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
[HACKERS] help needed with yacc/bison
Hi there,
attached archive contains simple parser demonstrating our
problem. untar it, make, make test
Good test:
echo -n 12 34.1234 ... | ./parser
INTEGER:'12'
CHAR: ' '
VERSION:'34.1234'
CHAR: ' '
DOT:'.'
DOT:'.'
DOT:'.'
Wrong:
echo -n 12 34.1234. ... | ./parser
INTEGER:'12'
CHAR: ' '
yyerror: syntax error, unexpected CHAR, expecting INTEGER
The problem is recognizing VERSION
(from gram.y)
version:
INTEGER DOT INTEGER{ $$ = strconcat($1, $3, $2); }
| version DOT INTEGER { $$ = strconcat($1, $3, $2); }
;
For last query '34.1234.' we want to print VERSION '34.1234' and
return DOT.
This is just an test example, actually we know workaround
for this case, but we need something simple and universal :)
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 4: Don't 'kill -9' the postmaster
Re: [HACKERS] help needed with yacc/bison
Sorry,
forgot to attach archive :)
Oleg
On Tue, 1 Jul 2003, Oleg Bartunov wrote:
Hi there,
attached archive contains simple parser demonstrating our
problem. untar it, make, make test
Good test:
echo -n 12 34.1234 ... | ./parser
INTEGER:'12'
CHAR: ' '
VERSION:'34.1234'
CHAR: ' '
DOT:'.'
DOT:'.'
DOT:'.'
Wrong:
echo -n 12 34.1234. ... | ./parser
INTEGER:'12'
CHAR: ' '
yyerror: syntax error, unexpected CHAR, expecting INTEGER
The problem is recognizing VERSION
(from gram.y)
version:
INTEGER DOT INTEGER{ $$ = strconcat($1, $3, $2); }
| version DOT INTEGER { $$ = strconcat($1, $3, $2); }
;
For last query '34.1234.' we want to print VERSION '34.1234' and
return DOT.
This is just an test example, actually we know workaround
for this case, but we need something simple and universal :)
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 4: Don't 'kill -9' the postmaster
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
ex.tar.gz
Description: Binary data
---(end of broadcast)---
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] dblink for Oracle - question ...
On Mon, 2003-06-23 at 16:24, Hans-Jürgen Schönig wrote: A few days ago I have posted a pre-beta version of dblink_ora which is supposed to solve some problems we had here at Cybertec (getting data from an Oracle DB and merge it with PostgreSQL). I have implemented a simple piece of code (more proof of concept than production). If I'm not mistaken, the request was that you and Joe would merge the code with standard dblink and integrate both into the backend for 7.5. http://fts.postgresql.org/db/msg.html?mid=1504725 -- Rod Taylor [EMAIL PROTECTED] PGP Key: http://www.rbt.ca/rbtpub.asc signature.asc Description: This is a digitally signed message part
Re: [HACKERS] Dllist public/private part
Mendola Gaetano wrote: Tom Lane [EMAIL PROTECTED] wrote: Mendola Gaetano [EMAIL PROTECTED] writes: I'm improving the Dllist in these direction: AFAIR, catcache.c is the *only* remaining backend customer for Dllist, and so any improvement for Dllist that breaks catcache is hardly an improvement, no? 1) Avoid if statements in insertion/remove phase, for instance now the AddHeader appear like this: shrug ... unless you can convert DLAddHead into a inline macro, I doubt there'll be any visible performance difference. 2) Not using a malloc but using a special malloc that not perform a malloc for each request but do a BIG malloc at first request... It would make more sense to migrate Dllist to use palloc. That's not compatible with its use in frontend libpq; I've been speculating about splitting off libpq to have a separate implementation instead of trying to share code. I believe libpq only uses Dllist for the pending-notify-events list, for which the code is poorly optimized anyway (we don't need a doubly-linked list for that). I certainly would like to see Dllist removed too. This mean that is waste of time work on dllist. I seen that exist a TODO list about features, exist a list about: code to optimize ? What TODO item where you looking at? -- 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] cvs build failure
Hi, I'm trying to build cvs, but it fails: bison -y -d preproc.y preproc.y:6214: fatal error: maximum table size (32767) exceeded make[4]: *** [preproc.h] Error 1 make[4]: Leaving directory `/home/bert/src/pgsql/src/interfaces/ecpg/preproc' What's the problem? -- Markus Bertheau. Berlin, Berlin. Germany. ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [HACKERS] cvs build failure
what version of bison are you using? I believe we require 1.875 these days. LER --On Tuesday, July 01, 2003 21:39:59 +0200 Markus Bertheau [EMAIL PROTECTED] wrote: Hi, I'm trying to build cvs, but it fails: bison -y -d preproc.y preproc.y:6214: fatal error: maximum table size (32767) exceeded make[4]: *** [preproc.h] Error 1 make[4]: Leaving directory `/home/bert/src/pgsql/src/interfaces/ecpg/preproc' What's the problem? -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 972-414-9812 E-Mail: [EMAIL PROTECTED] US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749 ---(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] cvs build failure
, 01.07.2003, 21:41, Larry Rosenman : what version of bison are you using? I believe we require 1.875 these days. 1.35. I'll upgrade. Thanks. -- Markus Bertheau. Berlin, Berlin. Germany. ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [HACKERS] cvs build failure
On Tue, Jul 01, 2003 at 09:39:59PM +0200, Markus Bertheau wrote: bison -y -d preproc.y preproc.y:6214: fatal error: maximum table size (32767) exceeded make[4]: *** [preproc.h] Error 1 make[4]: Leaving directory `/home/bert/src/pgsql/src/interfaces/ecpg/preproc' What's the problem? You need to install bison-1.875 or later. I think there were RPMs on www.joeconway.com if you are in a Redhat-ish system, or you can get it from GNU ftp's if you are not. -- Alvaro Herrera (alvherre[a]dcc.uchile.cl) La conclusion que podemos sacar de esos estudios es que no podemos sacar ninguna conclusion de ellos (Tanenbaum) ---(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] Urgent : Regarding Submission of Code
First, read the developer's FAQ. Second, you probably will want to look at /contrib and see if it can be made into a loadable module. I am not sure we would want to have the datacube stuff in the main backend source tree. --- Srikanth M wrote: Hi! We have written two new files by name datacube.c in tcop directory and datacube.h in include directory. We have even changed some exsisting files. We have made a patch of the files that have been changed. But how should we send the new files datacube.c, and datacube.h along with the patch. Is there any specific procedure to send the files we have written. Please tell the procedure of submitting a new file along with the patch. bye Srikanth. ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED] -- 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] vacuum bug
Christopher Kings-Lynne [EMAIL PROTECTED] writes: I was running a long-running vacuum full, and then halfway thru that our background vacuum process started. As well as this, there was light activity on a users table from which vacuum full was removing 9 rows. There would be *zero* activity on a table undergoing vacuum full, unless your app has found a way around vacuum full's exclusive lock. You sure this wasn't a plain vacuum? Then vacuum full failed after a while: ERROR: simple_heap_update: tuple concurrently updated Were you doing VACUUM ANALYZEs? It's possible for two concurrent VACUUM ANALYZEs of the same table to get this failure from trying to concurrently update the same row in pg_statistic. (The cure for this seems worse than the disease: AFAICS you'd have to prevent *all* concurrent updates of pg_statistic by grabbing a table-level lock. So we just live with one of the analyzes reporting a failure. All the useful work gets done anyway, by one transaction or the other.) regards, tom lane ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [HACKERS] Index expressions: how to recreate
Andreas Pflug [EMAIL PROTECTED] writes: I noticed the new expression functionality of indices and while implementing them in pgadmin3 was wonderingnow to extract the definition from the catalog. The best way is to use pg_get_indexdef(indexOID), same as pg_dump and psql do. CREATE INDEX foo ON bar (numcol, length(txtcol), intcol2, length(txtcol2)) indkey will contain 1 0 4 Actually it should be read as 1 0 4 0. The output converter for int2vector suppresses trailing zeroes, for largely-historical reasons. regards, tom lane ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [HACKERS] cvs build failure
CVS checks for an old bison, though it just throws a warning, not an error. --- Markus Bertheau wrote: ? ???, 01.07.2003, ? 21:41, Larry Rosenman ?: what version of bison are you using? I believe we require 1.875 these days. 1.35. I'll upgrade. Thanks. -- Markus Bertheau. Berlin, Berlin. Germany. ---(end of broadcast)--- TIP 8: explain analyze is your friend -- 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] help needed with yacc/bison
Oleg Bartunov kirjutas T, 01.07.2003 kell 15:49:
Hi there,
attached archive contains simple parser demonstrating our
problem. untar it, make, make test
Good test:
echo -n 12 34.1234 ... | ./parser
INTEGER:'12'
CHAR: ' '
VERSION:'34.1234'
CHAR: ' '
DOT:'.'
DOT:'.'
DOT:'.'
Wrong:
echo -n 12 34.1234. ... | ./parser
INTEGER:'12'
CHAR: ' '
yyerror: syntax error, unexpected CHAR, expecting INTEGER
The problem is recognizing VERSION
(from gram.y)
version:
INTEGER DOT INTEGER{ $$ = strconcat($1, $3, $2); }
| version DOT INTEGER { $$ = strconcat($1, $3, $2); }
removing the line above seems to fix your problem ;)
;
For last query '34.1234.' we want to print VERSION '34.1234' and
return DOT.
you can't return DOT as version is str and DOT is opr
This is just an test example, actually we know workaround
for this case, but we need something simple and universal :)
please describe the problem with some more samples, as it will make it
easier which kind of universal you are searching for ;)
Hannu
---(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] Is Patch Ok for deferred trigger disk queue?
On Tue, 1 Jul 2003, Stuart wrote: Tom Lane wrote: Stephan Szabo [EMAIL PROTECTED] writes: As a side question, it looks to me that the code stores the first trigger records in memory and then after some point starts storing all new records on disk. Is this correct? I'd wonder if that's really what you want in general, since I'd think that the earliest ones are the ones you're least likely to need until end of transaction (or set constraints in the fk case) whereas the most recent ones are possibly going to be immediate triggers which you're going to need as soon as the statement is done. Good point. It would be better to push out stuff from the head of the queue, hoping that stuff near the end might never need to be written at all. regards, tom lane Hmmm I see your point. I will change the patch to write the head to disk and reenter when the development branch splits off. Also I've noticed that there is an fd.h which has file routines which I should be using rather than the stdio routines. I will also clean up those errors. Hmm, it also looks like the original patch broke deferred foreign keys. You'd not have noticed it since I'd forgotten the case in question for the foreign key regression tests. I'm going to make a patch for the tests since we should be testing that in any case. ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
[HACKERS] make check fails: user postgres doesn't exist
Hi, make check fails, and I have absolutely no idea where to look: running on port 65432 with pid 631 == creating database regression == createdb: could not connect to database template1: FATAL: user postgres does not exist pg_regress: createdb failed make: *** [check] 2 -- Markus Bertheau. Berlin, Berlin. Germany. ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [HACKERS] make check fails: user postgres doesn't exist
On Tue, Jul 01, 2003 at 10:28:12PM +0200, Markus Bertheau wrote: Subject: [HACKERS] make check fails: user postgres doesn't exist From: Markus Bertheau [EMAIL PROTECTED] To: [EMAIL PROTECTED] X-Mailer: Ximian Evolution 1.4.0 Date: 01 Jul 2003 22:28:12 +0200 Hi, make check fails, and I have absolutely no idea where to look: running on port 65432 with pid 631 == creating database regression == createdb: could not connect to database template1: FATAL: user postgres does not exist pg_regress: createdb failed make: *** [check] 2 simply add the user. in a unix environment, and specifically Red Hat (though it may apply in other places), you use the 'adduser' program, which has a good man page. try 'man -k passwd' or 'man -k user' or something for hints on your platform. regards, J -- || Jeff - http://zoidtechnologies.com/ || GNUPG Fingerprint: A607 0F19 7C75 1305 67E4 BDFF 26BD 606E 3517 2A42 ---(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] make check fails: user postgres doesn't exist
On Tue, Jul 01, 2003 at 11:09:15PM +0200, Markus Bertheau wrote: Subject: Re: [HACKERS] make check fails: user postgres doesn't exist From: Markus Bertheau [EMAIL PROTECTED] To: Jeff [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] X-Mailer: Ximian Evolution 1.4.0 Date: 01 Jul 2003 23:09:15 +0200 ?? ??, 01.07.2003, ?? 22:53, Jeff ??: On Tue, Jul 01, 2003 at 10:28:12PM +0200, Markus Bertheau wrote: make check fails, and I have absolutely no idea where to look: running on port 65432 with pid 631 == creating database regression == createdb: could not connect to database template1: FATAL: user postgres does not exist pg_regress: createdb failed make: *** [check] 2 simply add the user. in a unix environment, and specifically Red Hat (though it may apply in other places), you use the 'adduser' program, which has a good man page. try 'man -k passwd' or 'man -k user' or something for hints on your platform. The user postgres exists, but that wouldn't help, because I'm running make check as a user. And the postgres user that is meant is the postgres user that has nothing to do with the system postgres user, I think. ah, ok in that case you need to configure pg appropriately.. maybe you need to 'map' your current username to 'postgres'.. I dunno :) just trying to be helpful is all.. I shall step aside and let others respond. regards, J -- || Jeff - http://zoidtechnologies.com/ || GNUPG Fingerprint: A607 0F19 7C75 1305 67E4 BDFF 26BD 606E 3517 2A42 pgp0.pgp Description: PGP signature
Re: [HACKERS] make check fails: user postgres doesn't exist
Are you looking for: gmake installcheck LER --On Tuesday, July 01, 2003 17:21:37 -0400 Jeff [EMAIL PROTECTED] wrote: On Tue, Jul 01, 2003 at 11:09:15PM +0200, Markus Bertheau wrote: Subject: Re: [HACKERS] make check fails: user postgres doesn't exist From: Markus Bertheau [EMAIL PROTECTED] To: Jeff [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] X-Mailer: Ximian Evolution 1.4.0 Date: 01 Jul 2003 23:09:15 +0200 ?? ??, 01.07.2003, ?? 22:53, Jeff ??: On Tue, Jul 01, 2003 at 10:28:12PM +0200, Markus Bertheau wrote: make check fails, and I have absolutely no idea where to look: running on port 65432 with pid 631 == creating database regression == createdb: could not connect to database template1: FATAL: user postgres does not exist pg_regress: createdb failed make: *** [check] 2 simply add the user. in a unix environment, and specifically Red Hat (though it may apply in other places), you use the 'adduser' program, which has a good man page. try 'man -k passwd' or 'man -k user' or something for hints on your platform. The user postgres exists, but that wouldn't help, because I'm running make check as a user. And the postgres user that is meant is the postgres user that has nothing to do with the system postgres user, I think. ah, ok in that case you need to configure pg appropriately.. maybe you need to 'map' your current username to 'postgres'.. I dunno :) just trying to be helpful is all.. I shall step aside and let others respond. regards, J -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 972-414-9812 E-Mail: [EMAIL PROTECTED] US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749 ---(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] 7.4 feature freeze is here
The Postgres core committee would like to announce that we are now in feature-freeze mode for the 7.4 release. All patches already received in pgsql-patches will be considered in the usual fashion (and yes, we'll allow some slack for fixing problems in them). New features arriving in the future will be held for 7.5. Feel free to keep sending patches that fix bugs or improve documentation; only new features are out. The plan is to spend the next two weeks cleaning things up (bug fixes, documentation, etc) with a formal beta release scheduled on or about July 15. Final release of 7.4 will be whenever it seems ready, as usual. regards, tom lane ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] make check fails: user postgres doesn't exist
Markus Bertheau [EMAIL PROTECTED] writes: make check fails, and I have absolutely no idea where to look: running on port 65432 with pid 631 == creating database regression == createdb: could not connect to database template1: FATAL: user postgres does not exist (scratches head...) make check should automatically adopt your current username as the postgres superuser name, AFAIK. Perhaps there is some conflict in your environment settings? Do you have PGUSER defined, and if so is it different from your login name? You can dig around in the logs left in src/test/regress/log/ to see what make check was doing. initdb's report of the username it thought it was using would be worth looking at, in particular. regards, tom lane ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] make check fails: user postgres doesn't exist
, 01.07.2003, 23:30, Tom Lane : Markus Bertheau [EMAIL PROTECTED] writes: make check fails, and I have absolutely no idea where to look: running on port 65432 with pid 631 == creating database regression == createdb: could not connect to database template1: FATAL: user postgres does not exist (scratches head...) make check should automatically adopt your current username as the postgres superuser name, AFAIK. Perhaps there is some conflict in your environment settings? Do you have PGUSER defined, and if so is it different from your login name? Exactly that was the case, thanks. -- Markus Bertheau. Berlin, Berlin. Germany. ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Index expressions: how to recreate
Tom Lane wrote: Andreas Pflug [EMAIL PROTECTED] writes: I noticed the new expression functionality of indices and while implementing them in pgadmin3 was wonderingnow to extract the definition from the catalog. The best way is to use pg_get_indexdef(indexOID), same as pg_dump and psql do. So far for the SQL window, which will show just a plain (and hopefully nicely formatted. readable) sql query to recreate the index. Still, a verbose display of the indexes property is not possible this way, unless I parse the pg_get_indexdef output... pg_get_indexdef converts that string to a list of nodes (not surprising), while pg_get_expr whill join these list elements with an explicit and (according to a comment, needed for partial index). Do I need to retrieve indexprs and split it myself (counting brackets) or is there a pg_xxx function that could help me (pg_get_element(indexprs, 0...n)) ? Actually it should be read as 1 0 4 0. The output converter for int2vector suppresses trailing zeroes, for largely-historical reasons. Ok, I understand that, because indkey[n4] will deliver 0 too, and indnatts will show that 4 arguments are needed. Regards, Andreas ---(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] Is Patch Ok for deferred trigger disk queue?
Stuart wrote: Tom Lane wrote: Stephan Szabo [EMAIL PROTECTED] writes: As a side question, it looks to me that the code stores the first trigger records in memory and then after some point starts storing all new records on disk. Is this correct? I'd wonder if that's really what you want in general, since I'd think that the earliest ones are the ones you're least likely to need until end of transaction (or set constraints in the fk case) whereas the most recent ones are possibly going to be immediate triggers which you're going to need as soon as the statement is done. Good point. It would be better to push out stuff from the head of the queue, hoping that stuff near the end might never need to be written at all. regards, tom lane Hmmm I see your point. I will change the patch to write the head to disk and reenter when the development branch splits off. Also I've noticed that there is an fd.h which has file routines which I should be using rather than the stdio routines. I will also clean up those errors. While you are still at it, can you make the arbitrarily choosen trigger queue size a config parameter? It is much easier to do tuning without the need to recompile the backend. Jan -- #==# # 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 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [HACKERS] make check fails: user postgres doesn't exist
Markus Bertheau [EMAIL PROTECTED] writes: make check fails, and I have absolutely no idea where to look: (scratches head...) make check should automatically adopt your current username as the postgres superuser name, AFAIK. Perhaps there is some conflict in your environment settings? Do you have PGUSER defined, and if so is it different from your login name? Exactly that was the case, thanks. Hmm, seems like a misfeature in pg_regress. I guess adopting PGUSER from the environment is a good thing to do in the make installcheck case, but maybe it should drop it (along with the other environment variables that could affect connections) in the make check case. Peter, any thoughts about that? regards, tom lane ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [HACKERS] cvs build failure
Markus Bertheau [EMAIL PROTECTED] writes: what version of bison are you using? I believe we require 1.875 these days. 1.35. I'll upgrade. Thanks. I believe 'configure' will bleat about a too-old bison, but it won't refuse to proceed --- and the warning is easy to miss in the pages of output that configure produces. I was against having configure error out if bison is too old, since you might not need it at all (if building from a tarball). But it seems like we still have the problem. Maybe make configure act as though bison is missing? Not sure. It seems like that could create unnecessary problems in other cases. regards, tom lane ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Index expressions: how to recreate
Andreas Pflug [EMAIL PROTECTED] writes: Tom Lane wrote: The best way is to use pg_get_indexdef(indexOID), same as pg_dump and psql do. [ doesn't want to parse the pg_get_indexdef output... ] Well, I guess if you just want one column it's kind of a pain. pg_get_indexdef converts that string to a list of nodes (not surprising), while pg_get_expr whill join these list elements with an explicit and (according to a comment, needed for partial index). Do I need to retrieve indexprs and split it myself (counting brackets) or is there a pg_xxx function that could help me (pg_get_element(indexprs, 0...n)) ? There isn't any real good way to do it, and I'd discourage you from writing client-side code that roots around in those fields anyway. It's much too likely to break in future versions. Does anyone else think it's reasonable to define a backend function along the lines of pg_get_indexdef(indexoid, columnnumber) that retrieves just the column-name-or-expression for the indicated column of the index? I'm not eager to do it if just one person wants it, but if there's more than one potential user... regards, tom lane ---(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] cvs build failure
On Tue, Jul 01, 2003 at 06:12:31PM -0400, Tom Lane wrote: I believe 'configure' will bleat about a too-old bison, but it won't refuse to proceed --- and the warning is easy to miss in the pages of output that configure produces. Maybe it should throw an error and refuse to continue if the version is too old, but the message be verbose enough to let the user know of a separate switch to configure that would allow it to continue the configuration ignoring the bison version. Somethink like $ ./configure error: your bison is too old. Use --ignore-bison if you don't need it $ ./configure --ignore-bison [succeeds] I've seen similar things in other projects... -- Alvaro Herrera (alvherre[a]dcc.uchile.cl) Major Fambrough: You wish to see the frontier? John Dunbar: Yes sir, before it's gone. ---(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] cvs build failure
Tom Lane wrote: Markus Bertheau [EMAIL PROTECTED] writes: what version of bison are you using? I believe we require 1.875 these days. 1.35. I'll upgrade. Thanks. I believe 'configure' will bleat about a too-old bison, but it won't refuse to proceed --- and the warning is easy to miss in the pages of output that configure produces. I was against having configure error out if bison is too old, since you might not need it at all (if building from a tarball). But it seems like we still have the problem. Maybe make configure act as though bison is missing? Not sure. It seems like that could create unnecessary problems in other cases. One trick would be to set YACC to some special value like bison.too.old and test for that when YACC is actually called from the Makefile. -- 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] cvs build failure
Usual installs don't need bison because the tarball has pregenerated bison output files. --- Alvaro Herrera wrote: On Tue, Jul 01, 2003 at 06:12:31PM -0400, Tom Lane wrote: I believe 'configure' will bleat about a too-old bison, but it won't refuse to proceed --- and the warning is easy to miss in the pages of output that configure produces. Maybe it should throw an error and refuse to continue if the version is too old, but the message be verbose enough to let the user know of a separate switch to configure that would allow it to continue the configuration ignoring the bison version. Somethink like $ ./configure error: your bison is too old. Use --ignore-bison if you don't need it $ ./configure --ignore-bison [succeeds] I've seen similar things in other projects... -- Alvaro Herrera (alvherre[a]dcc.uchile.cl) Major Fambrough: You wish to see the frontier? John Dunbar: Yes sir, before it's gone. ---(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 8: explain analyze is your friend
Re: [HACKERS] cvs build failure
Bruce Momjian [EMAIL PROTECTED] writes: Tom Lane wrote: Maybe make configure act as though bison is missing? Not sure. It seems like that could create unnecessary problems in other cases. One trick would be to set YACC to some special value like bison.too.old and test for that when YACC is actually called from the Makefile. I kinda like Alvaro's suggestion of an --ignore-bison-version option to configure to suppress checking the version, but otherwise error out if we think bison is too old. The advantage to that is that you could manually override the automatic check if you had reason to know it was wrong (eg, you could see it'd misparsed the bison version string, or something). Also, it'd make sense to include that option by default in RPM builds, where you'd know you had up-to-date bison output files already included in the SRPM. 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] cvs build failure
Larry Rosenman [EMAIL PROTECTED] writes: what version of bison are you using? I believe we require 1.875 these days. It would be nice to be able to say --without-ecpg at configure time. Ecpg is the only part of pg that requires this version of bison and and is not a core part of the project, or is it? Regards, Manuel. ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] cvs build failure
Tom Lane wrote: Bruce Momjian [EMAIL PROTECTED] writes: Tom Lane wrote: Maybe make configure act as though bison is missing? Not sure. It seems like that could create unnecessary problems in other cases. One trick would be to set YACC to some special value like bison.too.old and test for that when YACC is actually called from the Makefile. I kinda like Alvaro's suggestion of an --ignore-bison-version option to configure to suppress checking the version, but otherwise error out if we think bison is too old. The advantage to that is that you could manually override the automatic check if you had reason to know it was wrong (eg, you could see it'd misparsed the bison version string, or something). Also, it'd make sense to include that option by default in RPM builds, where you'd know you had up-to-date bison output files already included in the SRPM. I can see making a new bison required only when the version is *devel. That way, folks testing CVS and even the *devel snapshots would need a new bison, but our normal users wouldn't. -- 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] cvs build failure
, 02.07.2003, 00:42, Tom Lane : Bruce Momjian [EMAIL PROTECTED] writes: Tom Lane wrote: Maybe make configure act as though bison is missing? Not sure. It seems like that could create unnecessary problems in other cases. One trick would be to set YACC to some special value like bison.too.old and test for that when YACC is actually called from the Makefile. I kinda like Alvaro's suggestion of an --ignore-bison-version option to configure to suppress checking the version, but otherwise error out if we think bison is too old. The advantage to that is that you could manually override the automatic check if you had reason to know it was wrong (eg, you could see it'd misparsed the bison version string, or something). Also, it'd make sense to include that option by default in RPM builds, where you'd know you had up-to-date bison output files already included in the SRPM. But it seems weird to require a switch for the normal case, i.e. a tarball build, and not require it for a cvs build. I don't see overriding as an advantage, too, because misparsing of the bison version string would just be a bug that had to be fixed, imo. You can as well modify configure in that case to make it compile, and send the patch to the bison version parser in afterwards. Maybe add a comment to the Makefile where bison is called that gives a hint to the user in case bison fails. -- Markus Bertheau. Berlin, Berlin. Germany. ---(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] cvs build failure
On Wed, Jul 02, 2003 at 12:56:11AM +0200, Markus Bertheau wrote: But it seems weird to require a switch for the normal case, i.e. a tarball build, and not require it for a cvs build. Yeah, I agree. Maybe the configure script should be built different for the releases, so users downloading tarballs don't need to use a switch, but people getting from CVS or snapshots do. Maybe add a comment to the Makefile where bison is called that gives a hint to the user in case bison fails. Not too many people read Makefiles these days, specially when autotools are involved (BTW, Postgres makefiles are very nice, but I don't think people reads them anyway). What would be the user looking for? The symbol in question is called $(YACC), perhaps not too intuitive. Another suggestion would be to capture bison's error code for the table-too-large error and give an informational message about bison version. -- Alvaro Herrera (alvherre[a]dcc.uchile.cl) Ni aun el genio muy grande llegaria muy lejos si tuviera que sacarlo todo de su propio interior (Goethe) ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [HACKERS] cvs build failure
Bruce Momjian [EMAIL PROTECTED] writes: I can see making a new bison required only when the version is *devel. That way, folks testing CVS and even the *devel snapshots would need a new bison, but our normal users wouldn't. Even then, if they're using a snapshot they shouldn't need it. Perhaps a combination of your idea and Alvaro's: set things up so that we fail only when bison is actually invoked by the makefiles, plus provide a way to override the version check if it's wrong. regards, tom lane ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] cvs build failure
, 02.07.2003, 01:10, Alvaro Herrera : On Wed, Jul 02, 2003 at 12:56:11AM +0200, Markus Bertheau wrote: Maybe add a comment to the Makefile where bison is called that gives a hint to the user in case bison fails. Not too many people read Makefiles these days Sorry, I meant an echo statement to communicate that message to stdout. Another suggestion would be to capture bison's error code for the table-too-large error and give an informational message about bison version. -- Markus Bertheau. Berlin, Berlin. Germany. ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [HACKERS] PHP/PgSQL *and* libpq ...
Marc G. Fournier wrote: On Wed, 25 Jun 2003, Robert Treat wrote: Seems like we should also allow for a windows specific distribution of libpq as well. I thought that the win32 stuff was being included as part of the base distribution? IF so, wouldn't such already be included in any libpq.tar.gz we created? Is there a reason why we'd need a libpq-win.tar.gz (assuming that that is what you are suggesting?) ... ? I think he meant a separate binary, somehow installer-wrapped libpq.dll - right? Honestly I think that doesn't do much for windows. It would only do if we would add many other, more or less dependant interfaces, like ODBC, Pgtcl, Pgperl?, JDBC, MyDBC ... but then we get into all the license, packaging, distribution hassle. Jan Robert Treat On Tuesday 24 June 2003 10:43 pm, Bruce Momjian wrote: Added to TODO: * Allow creation of a libpq-only tarball --- The Hermit Hacker wrote: Just a side bar to the whole thread about PHP/MySQL ... I realize that libpq is intwined with the backend right now, but if anyone could think of a way of at least adding a make target that would create a libpq.tar.gz distribution, I believe it would go a long way towards making it easier for ppl to add/compile in PgSQL support into PHP ... right now, to do so, you have to download an 8Meg file to get libpq ... if it could be reduced to a .5Meg tar.gz file: svr1# du -sk libpq 532 libpq it would be less onerous to download and add the support in ... ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html -- #==# # 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 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] cvs build failure
Tom Lane wrote: Bruce Momjian [EMAIL PROTECTED] writes: I can see making a new bison required only when the version is *devel. That way, folks testing CVS and even the *devel snapshots would need a new bison, but our normal users wouldn't. Even then, if they're using a snapshot they shouldn't need it. Perhaps a combination of your idea and Alvaro's: set things up so that we fail only when bison is actually invoked by the makefiles, plus provide a way to override the version check if it's wrong. I don't see a reason to have a flag to turn it off --- has anyone reported that the version check failed? -- 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
[HACKERS] New position and new location
Dear PostgreSQL community, it is with great pleasure that I would like to let you all know that I recently joined Afilias, a domain name registry services company that runs the .info top level domain and also provides core registry services to .org and a variety of other country code TLDs. (http://www.afilias.info). Afilias is a committed user of the PostgreSQL database system, and a very good example for how far this open source project has come. To ensure that this choice continues to be a good one in the future, my duties will include to improve PostgreSQL and contribute those improvements, enhancements and conceptual work back to the community. The next couple of weeks will be a bit turbulent as I will be working out of Afilias' USA office, and hence will be moving soon to suburban Philadelphia. Regards, Jan -- #==# # 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 4: Don't 'kill -9' the postmaster
Re: [HACKERS] vacuum bug
There would be *zero* activity on a table undergoing vacuum full, unless your app has found a way around vacuum full's exclusive lock. You sure this wasn't a plain vacuum? Hmm...correct. So I don't know what happened. Then vacuum full failed after a while: ERROR: simple_heap_update: tuple concurrently updated Were you doing VACUUM ANALYZEs? The background vacuum was doing analyze, the full one was not. It's possible for two concurrent VACUUM ANALYZEs of the same table to get this failure from trying to concurrently update the same row in pg_statistic. (The cure for this seems worse than the disease: AFAICS you'd have to prevent *all* concurrent updates of pg_statistic by grabbing a table-level lock. So we just live with one of the analyzes reporting a failure. All the useful work gets done anyway, by one transaction or the other.) Hmmm...I don't see why I would have had two concurrent analyzes going on... I guess there's not enough info to diagnose it anyway... Chris ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Urgent : Regarding Submission of Code
First, read the developer's FAQ. Second, you probably will want to look at /contrib and see if it can be made into a loadable module. I am not sure we would want to have the datacube stuff in the main backend source tree. Why not? It's in SQL99... Chris ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Urgent : Regarding Submission of Code
Yes, I was wrong. I now see it can't be a loadable module. I actually thought it was for data warehousing and not standard SQL. --- Christopher Kings-Lynne wrote: First, read the developer's FAQ. Second, you probably will want to look at /contrib and see if it can be made into a loadable module. I am not sure we would want to have the datacube stuff in the main backend source tree. Why not? It's in SQL99... Chris ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED] -- 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]
[HACKERS] Setting locale per connection
Hi all,
I'm new to the list, so don't flame at the first date ;).
I usually use PostgreSQL for multiple languages, so I needed to
set locale per connection, or can change the locale on the fly.
I don't know if there is any such ability integrated in or not,
so I have wrote my 10lines function as a wrapper around
setlocale, that is attached. So what I do is just a simple
SELECT locale('LC_COLLATE', 'fa_IR'); at connection time. Let
me know if there is any standard way already implemented.
Another silly question, isn't any way to get rid of seqscan, when
doing 'SELECT count(*) FROM tab;'?
Yours,
behdad
--
Behdad Esfahbod 11 Tir 1382, 2003 Jul 2
http://behdad.org/ [Finger for Geek Code]
If you do a job too well, you'll get stuck with it.
#include pgsql/postgres.h
#include locale.h
bool
pgbe_setlocale (void *cat, void *loc)
{
int category;
void *catstr;
if (!loc)
return false;
if (cat)
catstr = VARDATA (cat);
else
catstr = LC_ALL; /* default to LC_ALL */
#define CHECKCATEGORY(s, i) if (!strcmp (s, catstr)) category = i;
/* *INDENT-OFF* */
CHECKCATEGORY (LC_ALL, LC_ALL) else
CHECKCATEGORY (LC_COLLATE, LC_COLLATE) else
CHECKCATEGORY (LC_CTYPE,LC_CTYPE) else
CHECKCATEGORY (LC_MESSAGES, LC_MESSAGES)else
CHECKCATEGORY (LC_MONETARY, LC_MONETARY)else
CHECKCATEGORY (LC_NUMERIC, LC_NUMERIC) else
CHECKCATEGORY (LC_TIME, LC_TIME)else
return false;
/* *INDENT-ON* */
#undef CHECKCATEGORY
return setlocale (category, VARDATA (loc)) ? true : false;
}
---(end of broadcast)---
TIP 8: explain analyze is your friend
Re: [HACKERS] PHP/PgSQL *and* libpq ...
On Tue, 1 Jul 2003, Jan Wieck wrote: Marc G. Fournier wrote: On Wed, 25 Jun 2003, Robert Treat wrote: Seems like we should also allow for a windows specific distribution of libpq as well. I thought that the win32 stuff was being included as part of the base distribution? IF so, wouldn't such already be included in any libpq.tar.gz we created? Is there a reason why we'd need a libpq-win.tar.gz (assuming that that is what you are suggesting?) ... ? I think he meant a separate binary, somehow installer-wrapped libpq.dll - right? Honestly I think that doesn't do much for windows. It would only do if we would add many other, more or less dependant interfaces, like ODBC, Pgtcl, Pgperl?, JDBC, MyDBC ... but then we get into all the license, packaging, distribution hassle. Well, actually, I believe Dave already does up the ODBC driver in binary form ... And dont' we have a 'native, non-cygwin' libpq already? ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Setting locale per connection
On Wed, Jul 02, 2003 at 07:22:51AM +0430, Behdad Esfahbod wrote: Another silly question, isn't any way to get rid of seqscan, when doing 'SELECT count(*) FROM tab;'? No :-( If you want to do that frequently, you should try to find another way to keep the count. -- Alvaro Herrera (alvherre[a]dcc.uchile.cl) Crear es tan dificil como ser libre (Elsa Triolet) ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [HACKERS] Setting locale per connection
I usually use PostgreSQL for multiple languages, so I needed to
set locale per connection, or can change the locale on the fly.
I don't know if there is any such ability integrated in or not,
so I have wrote my 10lines function as a wrapper around
setlocale, that is attached. So what I do is just a simple
SELECT locale('LC_COLLATE', 'fa_IR'); at connection time. Let
me know if there is any standard way already implemented.
Don't know the answer to that one..
Another silly question, isn't any way to get rid of seqscan, when
doing 'SELECT count(*) FROM tab;'?
No, there's not. Due to PostgreSQL design restrictions. Just avoid doing
it, or use a trigger to keep a summary table or something.
Chris
---(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] Setting locale per connection
On Wed, 2 Jul 2003, Behdad Esfahbod wrote:
I'm new to the list, so don't flame at the first date ;).
I usually use PostgreSQL for multiple languages, so I needed to
set locale per connection, or can change the locale on the fly.
I don't know if there is any such ability integrated in or not,
so I have wrote my 10lines function as a wrapper around
setlocale, that is attached. So what I do is just a simple
SELECT locale('LC_COLLATE', 'fa_IR'); at connection time. Let
me know if there is any standard way already implemented.
Hmm, I'd think there'd be some potential for danger there. I don't play
with the locale stuff, but if the collation changes and you've got indexed
text (varchar, char) fields, wouldn't the index no longer necessarily be
in the correct order?
---(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] Setting locale per connection
On Tue, 1 Jul 2003, Stephan Szabo wrote:
On Wed, 2 Jul 2003, Behdad Esfahbod wrote:
I'm new to the list, so don't flame at the first date ;).
I usually use PostgreSQL for multiple languages, so I needed to
set locale per connection, or can change the locale on the fly.
I don't know if there is any such ability integrated in or not,
so I have wrote my 10lines function as a wrapper around
setlocale, that is attached. So what I do is just a simple
SELECT locale('LC_COLLATE', 'fa_IR'); at connection time. Let
me know if there is any standard way already implemented.
Hmm, I'd think there'd be some potential for danger there. I don't play
with the locale stuff, but if the collation changes and you've got indexed
text (varchar, char) fields, wouldn't the index no longer necessarily be
in the correct order?
I read in the FAQ that indexes for text fields is used just if
default C locale is used during initdb, well, humm, is not the
case on most distros. BTW, such a function is really needed to
make Unicode collation algorithms effective. I may be able to
convince my provider to define the function, but I can't convince
him to start the backend with my desired locale!
--
Behdad Esfahbod 11 Tir 1382, 2003 Jul 2
http://behdad.org/ [Finger for Geek Code]
If you do a job too well, you'll get stuck with it.
---(end of broadcast)---
TIP 7: don't forget to increase your free space map settings
Re: [HACKERS] cvs build failure
Bruce Momjian [EMAIL PROTECTED] writes: I don't see a reason to have a flag to turn it off --- has anyone reported that the version check failed? Since that version check has only been in CVS tip a month or two, and has not seen a release cycle, it'd be folly to think it's bulletproof. 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] Setting locale per connection
On Wed, 2 Jul 2003, Behdad Esfahbod wrote:
On Tue, 1 Jul 2003, Stephan Szabo wrote:
On Wed, 2 Jul 2003, Behdad Esfahbod wrote:
I'm new to the list, so don't flame at the first date ;).
I usually use PostgreSQL for multiple languages, so I needed to
set locale per connection, or can change the locale on the fly.
I don't know if there is any such ability integrated in or not,
so I have wrote my 10lines function as a wrapper around
setlocale, that is attached. So what I do is just a simple
SELECT locale('LC_COLLATE', 'fa_IR'); at connection time. Let
me know if there is any standard way already implemented.
Hmm, I'd think there'd be some potential for danger there. I don't play
with the locale stuff, but if the collation changes and you've got indexed
text (varchar, char) fields, wouldn't the index no longer necessarily be
in the correct order?
I read in the FAQ that indexes for text fields is used just if
default C locale is used during initdb, well, humm, is not the
Indexes are only used for LIKE queries on the C locale, but they
should be used for standard =, , , etc queries in the other locales
so you may still run into trouble.
---(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] cvs build failure
Tom Lane wrote: Bruce Momjian [EMAIL PROTECTED] writes: I don't see a reason to have a flag to turn it off --- has anyone reported that the version check failed? Since that version check has only been in CVS tip a month or two, and has not seen a release cycle, it'd be folly to think it's bulletproof. But do we add the ability to turn it off when we have no evidence it will ever be needed, and if we hook it only to *devel versions? This would turn off the make failure when an old bison is called from the makefile? -- 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] cvs build failure
Bruce Momjian [EMAIL PROTECTED] writes: This would turn off the make failure when an old bison is called from the makefile? Rephrase that as this would give bison the right to fail of its own accord, rather than our prejudging its ability to cope. Given bison's on-again-off-again track record in recent releases, I don't think it's wise to wire in a non-overridable assumption that bison X is broken and bison = X is good. A hint that bison X might be broken is fine --- but let's not pretend that configure is smarter than the user. regards, tom lane ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [HACKERS] cvs build failure
Tom Lane wrote: Bruce Momjian [EMAIL PROTECTED] writes: This would turn off the make failure when an old bison is called from the makefile? Rephrase that as this would give bison the right to fail of its own accord, rather than our prejudging its ability to cope. Given bison's on-again-off-again track record in recent releases, I don't think it's wise to wire in a non-overridable assumption that bison X is broken and bison = X is good. A hint that bison X might be broken is fine --- but let's not pretend that configure is smarter than the user. I just don't like to add bloat/document another configure option that has a _very_ limited usefulness. Can we not document it and just print it when we report the bison failure? Should we just allow an environment variable to over-ride it? -- 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 8: explain analyze is your friend
Re: [HACKERS] Setting locale per connection
Stephan Szabo [EMAIL PROTECTED] writes: On Wed, 2 Jul 2003, Behdad Esfahbod wrote: so I have wrote my 10lines function as a wrapper around setlocale, that is attached. Hmm, I'd think there'd be some potential for danger there. I don't play with the locale stuff, but if the collation changes and you've got indexed text (varchar, char) fields, wouldn't the index no longer necessarily be in the correct order? Indeed, this is exactly why Postgres goes out of its way to prevent you from changing the backend's collation setting on-the-fly. The proposed function is a great way to shoot yourself in the foot :-(. If you doubt it, check the archives from two or three years ago when we did not have the interlock to force LC_COLLATE to be frozen at initdb time ... regards, tom lane ---(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
