Re: [HACKERS] Visual Studio 2005, C-language function - avoiding hacks?
2010/3/9 Takahiro Itagaki itagaki.takah...@oss.ntt.co.jp: Magnus Hagander mag...@hagander.net wrote: The existing mechanism works (as demonstrated by the fact that the contrib modules work on Windows). Did we use non-standard tools except msvc in the build framework for core code? And what should I do for an external project? Yes, we use mingw. Hmmm, it means the existing mechanism can only work on limited environments. Should we make the code to be more portable for standard developers? That would definitely be good. Third party developer might not build the postgres server, but they would want to build their extension modules without mingw. Well, the tool for generating the full export of symbols is in the build tree, so perhaps we jus tneed to ship that. But usually you *don't* want that because, well, it's non-standard. And exporting all symbols makes the binary *much* larger (iirc, postgres.exe grows about 40%). It would perhaps be better to encourage (and document) how people create their own .DEF files to export the specific symbols they need. Because AFAIK, that will work if you do that - or do you know of issues with that method? -- Magnus Hagander Me: http://www.hagander.net/ Work: http://www.redpill-linpro.com/ -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Re: [COMMITTERS] pgsql: Augment WAL records for btree delete with GetOldestXmin() to
On Sun, 2010-01-31 at 16:53 -0500, Tom Lane wrote: Heikki Linnakangas heikki.linnakan...@enterprisedb.com writes: IIRC it was Greg Stark who suggested last time this was discussed that we could calculate the exact value for latestRemovedXid in the standby. When replaying the deletion record, the standby could look at all the heap tuples whose index pointers are being removed, to see which one was newest. This assumes that the standby can tell which heap tuples are being removed, which I'm not sure is true --- consider the case where the deletion record is carrying a page image instead of a list of deleted tuples. But maybe we could rejigger the representation to make sure that the info is always available. In general it sounds like a much nicer answer. I'm looking at this now since we definitely need either this or the previous patch. XLOG_BTREE_DELETE records would not carry latestRemovedXid, this would be calculated by inspection of heap tuples. XLOG_BTREE_DELETE would have a heap relid, to allow direct access to the heap without a Relation. We would check xmin, xmax and xvac. Code will look a little like heap_fetch() though disimilar enough not to use directly. We would only look at the tuple header and info. -- Simon Riggs www.2ndQuadrant.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Re: [COMMITTERS] pgsql: Augment WAL records for btree delete with GetOldestXmin() to
Simon Riggs wrote: XLOG_BTREE_DELETE records would not carry latestRemovedXid, this would be calculated by inspection of heap tuples. You might still want to keep the conservative latestRemovedXid value in the WAL record to avoid the extra work when latestRemovedXid alone allows. -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] lock mode for ControlFileLock which pg_start_backup uses
Takahiro Itagaki wrote: Fujii Masao masao.fu...@gmail.com wrote: The attached patch changes the lock mode which pg_start_backup() uses. Is it worth applying this patch? I think the patch is reasonable to represent what we are doing, even if there is no performance benefits from it. Agreed. -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] machine-readable pg_controldata?
Joe Conway m...@joeconway.com writes: I have not bothered to start a pgfoundry project yet -- thoughts? For the visibility of the project, pgfoundry is still a good idea it seems, even if you still have to register separately for the online catalogue: http://www.postgresql.org/download/products/1 Now, AFAIUI, if you want to ease the porting of the pgfoundry platform to something else, the best is not to use much of the features there (if any), but host the project at github or google code or whatever, and link from pgfoundry. For example, I've been switching the code hosting of my extensions from pgfoundry to github for some time now (switching as soon as maintenance is needed, git cvsimport is all I need to migrate). Regards, -- dim -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] machine-readable pg_controldata?
-BEGIN PGP SIGNED MESSAGE- Hash: RIPEMD160 (FWIW, my recollection of the original design intention for pg_controldata was that it was meant as a troubleshooting tool if the database wouldn't start up. I'm somewhat bemused to hear that people are trying to use it as part of production scripts. It wasn't meant to produce machine-readable output, much less to give values that you could rely on with respect to a running server.) I mostly use it to check on the progress of a PITR slave: just curious, is there a better/preferred way to get that information? - -- Greg Sabino Mullane g...@turnstep.com PGP Key: 0x14964AC8 201003091016 http://biglumber.com/x/web?pk=2529DF6AB8F79407E94445B4BC9B906714964AC8 -BEGIN PGP SIGNATURE- iEYEAREDAAYFAkuWZnAACgkQvJuQZxSWSsiqWgCglhHZ/awR5lSkjPG+yzd05ulz X6AAn0uvraweuz8pG15OybCyMzgfH3XX =QI2N -END PGP SIGNATURE- -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Re: [COMMITTERS] pgsql: Augment WAL records for btree delete with GetOldestXmin() to
On Tue, 2010-03-09 at 11:20 +0200, Heikki Linnakangas wrote: Simon Riggs wrote: XLOG_BTREE_DELETE records would not carry latestRemovedXid, this would be calculated by inspection of heap tuples. You might still want to keep the conservative latestRemovedXid value in the WAL record to avoid the extra work when latestRemovedXid alone allows. OK will do. -- Simon Riggs www.2ndQuadrant.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] ECPG, two varchars with same name on same line
On Fri, May 01, 2009 at 03:49:47PM +0300, Heikki Linnakangas wrote: ECPG constructs internal struct names for VARCHAR fields using the field name and line number it's defined on. In a contrived example, though, that's not unique. Consider the following example: ... This should now be fixed. Michael -- Michael Meskes Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org) Michael at BorussiaFan dot De, Meskes at (Debian|Postgresql) dot Org ICQ 179140304, AIM/Yahoo/Skype michaelmeskes, Jabber mes...@jabber.org VfL Borussia! Força Barça! Go SF 49ers! Use Debian GNU/Linux, PostgreSQL -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] patch (for 9.1) string functions
On Mar 9, 2010, at 6:30 AM, Pavel Stehule wrote:
this patch contains a string formatting function format
postgres=# select format('some message: % (current user: %)',
current_date, current_user);
format
some message: 2010-03-09 (current user: pavel)
(1 row)
this patch add new contrib module string functions - contains mainly
sprintf function:
Seems useful. Add it to the CommitFest so it doesn't get lost?
https://commitfest.postgresql.org/action/commitfest_view?id=6
Best,
David
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] patch (for 9.1) string functions
2010/3/9 David E. Wheeler da...@kineticode.com:
On Mar 9, 2010, at 6:30 AM, Pavel Stehule wrote:
this patch contains a string formatting function format
postgres=# select format('some message: % (current user: %)',
current_date, current_user);
format
some message: 2010-03-09 (current user: pavel)
(1 row)
this patch add new contrib module string functions - contains mainly
sprintf function:
Seems useful. Add it to the CommitFest so it doesn't get lost?
https://commitfest.postgresql.org/action/commitfest_view?id=6
https://commitfest.postgresql.org/action/patch_view?id=287
it is there
Pavel
Best,
David
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] Dyamic updates of NEW with pl/pgsql
How can a pl/pgsql trigger change the values of dynamic fields in NEW record ? By dynamic I mean that the field name is a variable in the trigger context. I've been told it's easy to do with pl/perl but I'd like to delive a pl/pgsql solution to have less dependencies. Thanks in advance. --strk; () Free GIS Flash consultant/developer /\ http://strk.keybit.net/services.html -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] patch (for 9.1) string functions
Hello
this patch contains a string formatting function format
postgres=# select format('some message: % (current user: %)',
current_date, current_user);
format
some message: 2010-03-09 (current user: pavel)
(1 row)
this patch add new contrib module string functions - contains mainly
sprintf function:
postgres=# select sprintf('some message: %10s (%10s)', current_date,
current_user);
sprintf
---
some message: 2010-03-09 ( pavel)
(1 row)
postgres=# select sprintf('some message: %10s (%-10s)', current_date,
current_user);
sprintf
---
some message: 2010-03-09 (pavel )
(1 row)
some string variadic functions
postgres=# select concat('ahaha',10,null,current_date, true);
concat
ahaha,10,,2010-03-09,t
(1 row)
postgres=# select concat_sql('ahaha',10,null,current_date, true);
concat_sql
'ahaha',10,NULL,'2010-03-09',t
(1 row)
postgres=# select concat_json('ahaha'::text,10,null,current_date, true);
concat_json
---
ahaha,10,null,2010-03-09,true
(1 row)
and some basic text function rvrs, left, right.
Regards
Pavel Stehule
stringfunc.diff
Description: Binary data
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Dyamic updates of NEW with pl/pgsql
2010/3/9 strk s...@keybit.net: How can a pl/pgsql trigger change the values of dynamic fields in NEW record ? By dynamic I mean that the field name is a variable in the trigger context. I've been told it's easy to do with pl/perl but I'd like to delive a pl/pgsql solution to have less dependencies. It isn't possible yet regards Pavel Stehule Thanks in advance. --strk; () Free GIS Flash consultant/developer /\ http://strk.keybit.net/services.html -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] patch (for 9.1) string functions
Pavel Stehule wrote: Hello this patch contains a string formatting function format Hi Pavel, This is supercool. Haven't tried it out yet but surely will, thanks! Yeb Havinga -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] patch (for 9.1) string functions
On Tue, Mar 9, 2010 at 9:30 AM, Pavel Stehule pavel.steh...@gmail.com wrote:
postgres=# select concat('ahaha',10,null,current_date, true);
concat
ahaha,10,,2010-03-09,t
why are there commas in the output?
merlin
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] patch (for 9.1) string functions
2010/3/9 Merlin Moncure mmonc...@gmail.com:
On Tue, Mar 9, 2010 at 9:30 AM, Pavel Stehule pavel.steh...@gmail.com wrote:
postgres=# select concat('ahaha',10,null,current_date, true);
concat
ahaha,10,,2010-03-09,t
why are there commas in the output?
I though so comma can be default separator - but I see - it is wrong -
separator have to be empty string.
Pavel
merlin
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] patch (for 9.1) string functions
updated version, concat function doesn't use separator
Pavel
2010/3/9 Pavel Stehule pavel.steh...@gmail.com:
2010/3/9 Merlin Moncure mmonc...@gmail.com:
On Tue, Mar 9, 2010 at 9:30 AM, Pavel Stehule pavel.steh...@gmail.com
wrote:
postgres=# select concat('ahaha',10,null,current_date, true);
concat
ahaha,10,,2010-03-09,t
why are there commas in the output?
I though so comma can be default separator - but I see - it is wrong -
separator have to be empty string.
Pavel
merlin
stringfunc.diff
Description: Binary data
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Dyamic updates of NEW with pl/pgsql
On Tue, Mar 09, 2010 at 06:59:31PM +0100, Pavel Stehule wrote: 2010/3/9 strk s...@keybit.net: How can a pl/pgsql trigger change the values of dynamic fields in NEW record ? By dynamic I mean that the field name is a variable in the trigger context. I've been told it's easy to do with pl/perl but I'd like to delive a pl/pgsql solution to have less dependencies. It isn't possible yet Any workaround you may suggest ? --strk; () Free GIS Flash consultant/developer /\ http://strk.keybit.net/services.html -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Dyamic updates of NEW with pl/pgsql
2010/3/9 strk s...@keybit.net: On Tue, Mar 09, 2010 at 06:59:31PM +0100, Pavel Stehule wrote: 2010/3/9 strk s...@keybit.net: How can a pl/pgsql trigger change the values of dynamic fields in NEW record ? By dynamic I mean that the field name is a variable in the trigger context. I've been told it's easy to do with pl/perl but I'd like to delive a pl/pgsql solution to have less dependencies. It isn't possible yet Any workaround you may suggest ? I don't know it - use C language maybe. Pavel --strk; () Free GIS Flash consultant/developer /\ http://strk.keybit.net/services.html -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] patch (for 9.1) string functions
On Tue, Mar 9, 2010 at 1:45 PM, Pavel Stehule pavel.steh...@gmail.com wrote: updated version, concat function doesn't use separator btw...very cool stuff. I took a brief look at the sprintf implementation. The main switch: switch (pdesc.field_type) It looks like format codes we choose not to support (like %p) are silently ignored. Is this the correct behavior? merlin -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Core dump running PL/Perl installcheck with bleadperl [PATCH]
Tim Bunce tim.bu...@pobox.com writes: The attached patch fixes the problem by changing the SvTYPE check to use SvROK instead. Although I only tripped over one case, the patch changes all four uses of SvTYPE(sv) == SVt_RV. The remaining uses of SvTYPE are ok. Applied back to 8.0. 7.4 seems not to contain any tests of this form. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] Access violation from palloc, Visual Studio 2005, C-language function
Environment: Windows Vista, PostgreSQL 8.4 (1-click installer), Visual Studio 2005 sp1. I have a bare-bones DLL built as per the above, compiling the 'add_one' and 'copytext' samples found at http://www.postgresql.org/docs/8.4/interactive/xfunc-c.html (version 1 calling convention), compiled as 'C'. I can use 'add_one' just fine from within SQL, but if I use 'copytext', an access violation occurs as soon as palloc() is called. Could anyone suggest what the problem might be? Failing that, are there any other (creative?) ways to return strings from a C-language function without using palloc? Thanks in advance for any leads Kevin. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Access violation from palloc, Visual Studio 2005, C-language function
Kevin Flanagan kevi...@linkprior.com writes: Environment: Windows Vista, PostgreSQL 8.4 (1-click installer), Visual Studio 2005 sp1. I have a bare-bones DLL built as per the above, compiling the 'add_one' and 'copytext' samples found at http://www.postgresql.org/docs/8.4/interactive/xfunc-c.html (version 1 calling convention), compiled as 'C'. I can use 'add_one' just fine from within SQL, but if I use 'copytext', an access violation occurs as soon as palloc() is called. Could anyone suggest what the problem might be? Hard to tell without seeing the actual code and a stack trace, but I'd bet that you haven't fully resolved the build process problems you mentioned earlier. I'm thinking this may be a symptom of linkage failure, since palloc is probably the first place in the above-described sequence where your DLL is going to call back into the core backend. Another possibility is that you mistranscribed the example somehow. Maybe you forgot the PG_FUNCTION_INFO_V1(copytext) macro? Failing that, are there any other (creative?) ways to return strings from a C-language function without using palloc? If you can't make those examples work, you have fundamental problems you need to fix, not find a creative workaround. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] lock mode for ControlFileLock which pg_start_backup uses
Fujii Masao masao.fu...@gmail.com wrote: Currently pg_start_backup() accesses the shared ControlFile by using ControlFileLock with LW_EXCLUSIVE lock mode. But since that access is read-only operation, LW_SHARED should be chosen instead of LW_EXCLUSIVE. The attached patch changes the lock mode which pg_start_backup() uses. Is it worth applying this patch? Thanks, applied. Regards, --- Takahiro Itagaki NTT Open Source Software Center -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] Warning about invalid .pgpass passwords
Bruce Momjian wrote: Tom Lane wrote: Alvaro Herrera alvhe...@commandprompt.com writes: It had to do with me having a bogus password in .pgpass (so psql was first trying empty password, then the one in .pgpass, and both failing). Pilot error. However, I'd say that we ought to give a notice if the password in .pgpass fails. Can we do something like ERROR: password authentication failed (using password from .pgpass) ie, just tack on a comment to the error message? I looked into that but found it difficult to implement because only libpq knows about pgpass, while the message is printed by psql. I just got confused for +10 minutes by an incorrect .pgpass password, so I found new interest in improving this reported behavior. ;-) The attached patch reports the fact that .pgpass was used if the libpq connection fails: $ psql -h localhost test psql: FATAL: password authentication failed for user postgres (password retrieved from .pgpass) I am not sure if I like the parentheses or not. Ideally I would report this only for password failures but that information is not passed back from the server except as an error string. I am thinking this could be in 9.0. -- Bruce Momjian br...@momjian.ushttp://momjian.us EnterpriseDB http://enterprisedb.com PG East: http://www.enterprisedb.com/community/nav-pg-east-2010.do Index: src/interfaces/libpq/fe-connect.c === RCS file: /cvsroot/pgsql/src/interfaces/libpq/fe-connect.c,v retrieving revision 1.389 diff -c -c -r1.389 fe-connect.c *** src/interfaces/libpq/fe-connect.c 3 Mar 2010 20:31:09 - 1.389 --- src/interfaces/libpq/fe-connect.c 10 Mar 2010 02:37:20 - *** *** 652,657 --- 652,659 conn-dbName, conn-pguser); if (conn-pgpass == NULL) conn-pgpass = strdup(DefaultPassword); + else + conn-used_dot_pgpass = true; } /* *** *** 1144,1149 --- 1146,1161 default: /* Just in case we failed to set it in PQconnectPoll */ conn-status = CONNECTION_BAD; + + /* + * If the connection failed, we should mention that + * we got the password from .pgpass in case that + * password is wrong. + */ + if (conn-used_dot_pgpass conn-password_needed) + appendPQExpBufferStr(conn-errorMessage, + libpq_gettext((password retrieved from .pgpass)\n)); + return 0; } *** *** 2191,2196 --- 2203,2209 conn-verbosity = PQERRORS_DEFAULT; conn-sock = -1; conn-password_needed = false; + conn-used_dot_pgpass = false; #ifdef USE_SSL conn-allow_ssl_try = true; conn-wait_ssl_try = false; Index: src/interfaces/libpq/libpq-int.h === RCS file: /cvsroot/pgsql/src/interfaces/libpq/libpq-int.h,v retrieving revision 1.149 diff -c -c -r1.149 libpq-int.h *** src/interfaces/libpq/libpq-int.h 26 Feb 2010 02:01:33 - 1.149 --- src/interfaces/libpq/libpq-int.h 10 Mar 2010 02:37:20 - *** *** 343,348 --- 343,349 ProtocolVersion pversion; /* FE/BE protocol version in use */ int sversion; /* server version, e.g. 70401 for 7.4.1 */ bool password_needed; /* true if server demanded a password */ + bool used_dot_pgpass; /* true if used .pgpass */ bool sigpipe_so; /* have we masked SIGPIPE via SO_NOSIGPIPE? */ bool sigpipe_flag; /* can we mask SIGPIPE via MSG_NOSIGNAL? */ -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Warning about invalid .pgpass passwords
On Wed, Mar 10, 2010 at 11:52 AM, Bruce Momjian br...@momjian.us wrote: The attached patch reports the fact that .pgpass was used if the libpq connection fails: + /* +* If the connection failed, we should mention that +* we got the password from .pgpass in case that +* password is wrong. +*/ + if (conn-used_dot_pgpass conn-password_needed) + appendPQExpBufferStr(conn-errorMessage, + libpq_gettext((password retrieved from .pgpass)\n)); I think that this should be in PQconnectPoll() rather than connectDBComplete(). Otherwise, only when we make a connection to the server in a nonblocking manner (i.e., use PQconnectStart() and PQconnectPoll()), that HINT message is not output. This looks odd for me. Thought? Regards, -- Fujii Masao NIPPON TELEGRAPH AND TELEPHONE CORPORATION NTT Open Source Software Center -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Warning about invalid .pgpass passwords
Bruce Momjian br...@momjian.us writes: The attached patch reports the fact that .pgpass was used if the libpq connection fails: The test is in a very inappropriate place --- it will be missed by several fully-supported code paths. I am not sure if I like the parentheses or not. I don't like 'em. If you don't have enough confidence in the message to be replacing the normal error string, you probably shouldn't be doing this at all. We'll look silly if we attach such a comment to a message that indicates a network failure, for example; and cases where the comment is actively misleading would be even worse. I'm inclined to think that maybe we should make the server return a distinct SQLSTATE for bad password, and have libpq check for that rather than just assuming that the failure must be bad password. The main argument against this is probably that it would tell a bad guy that he's got a valid username but not a valid password. Not sure if that's a serious issue or not --- I seem to recall that we are exposing validity of user names already (or was that database names?). It would also mean that the new message only triggers when talking to a 9.0+ server, but since we've gotten along without it till now, that aspect doesn't bother me at all. A compromise would be to check for ERRCODE_INVALID_AUTHORIZATION_SPECIFICATION, which in combination with the knowledge that we got asked for a password would give fairly high confidence though not certainty that the problem is a bad password. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Re: Hot Standby query cancellation and Streaming Replication integration
All, I've been playing with vacuum_defer_cleanup_age in reference to the query cancel problem. It really seems to me that this is the way forward in terms of dealing with query cancel for normal operation rather than wal_standby_delay, or maybe in combination with it. As a first test, I set up a deliberately pathological situation with pgbench and a wal_standby_delay of 1 second. This allowed me to trigger query cancel on a relatively simple reporting query; in fact, to make it impossible to complete. Then I increased vacuum_defer_cleanup_age to 10, which represents about 5 minutes of transactions on the test system. This eliminated all query cancels for the reporting query, which takes an average of 10s. Next is a database bloat test, but I'll need to do that on a system with more free space than my laptop. --Josh Berkus -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] patch (for 9.1) string functions
2010/3/9 Merlin Moncure mmonc...@gmail.com: On Tue, Mar 9, 2010 at 1:45 PM, Pavel Stehule pavel.steh...@gmail.com wrote: updated version, concat function doesn't use separator btw...very cool stuff. I took a brief look at the sprintf implementation. The main switch: switch (pdesc.field_type) It looks like format codes we choose not to support (like %p) are silently ignored. Is this the correct behavior? it could be enhanced. sprintf is little bit baroque function and I am not able to take all details. Please, add comment with proposals for change. Pavel merlin -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
