Re: [HACKERS] Assertion failure twophase.c (2) (testing HS/SR)
On Thu, 2010-03-11 at 11:29 +0200, Heikki Linnakangas wrote: I'm still not any wiser on what's causing that, but I've fixed the bug in KnownAssignedXidsMany() now. Yeh, I've been mulling this over for a few days now and I can't see a way that could have happened either. I agree with your fix and the stronger placement of the Assertion. Thanks. I will be doing some further investigation in that area as well, over next week or so. -- 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] Server crash with older tzload library
Hi Tom, On Thu, Mar 11, 2010 at 8:29 PM, Tom Lane t...@sss.pgh.pa.us wrote: Jeevan Chalke jeevan.cha...@enterprisedb.com writes: While setting timezone using SET command (say GMT+3:30), postgres sometimes crashes randomly. I can't reproduce that: regression=# SET TimeZone = 'GMT+3:30'; SET regression=# SELECT '1969-12-31 20:30:00'::timestamptz; timestamptz --- 1969-12-31 20:30:00-03:30 (1 row) Even we were fail to re-produce it always. It is crashing randomly. After debugging, we found following values in tzstate variable when it crashed. So I manually modified it at the beginning of pg_tzset() function. /* Initialize tzstate with some arbitrary values */ tzstate.goback = 277946440; tzstate.goahead = 0; tzstate.ats[0] = 8892; Also not that, tzstate variable remains uninitialized properly when tzload() call returns -1. To mimic this, I have just renamed posixrules timezone file to something else. So that tzload returns -1. And as tzload can return -1 in any failure case and as we don't have that check at callee side tzstate variable remains uninitialized which leading to a server crash. As above garbage values too leads to a crash. In summary, following are the steps to re-produce: - Add above three lines at the beginning of the pg_tzset() function - make install - mv install/share/postgresql/timezone/posixrules install/share/postgresql/timezoneposixrules_a (or remove it) - start the server - run these two statements on psql prompt + SET TimeZone = 'GMT+3:30'; + SELECT '1969-12-31 20:30:00'::timestamptz; BTW, after your commit, tzload() function now sets goback and goahead variable to FALSE which fixes the server crash. MemSet in 2010c is just doing it explicitly before calling tzload though. Thanks for committing the part of the patch which stopped crashing the server with above mentioned steps. Thanks regards, tom lane -- Jeevan B Chalke Software Engineer, RD EnterpriseDB Corporation The Enterprise Postgres Company Phone: +91 20 30589500 Website: www.enterprisedb.com EnterpriseDB Blog: http://blogs.enterprisedb.com/ Follow us on Twitter: http://www.twitter.com/enterprisedb This e-mail message (and any attachment) is intended for the use of the individual or entity to whom it is addressed. This message contains information from EnterpriseDB Corporation that may be privileged, confidential, or exempt from disclosure under applicable law. If you are not the intended recipient or authorized to receive this for the intended recipient, any use, dissemination, distribution, retention, archiving, or copying of this communication is strictly prohibited. If you have received this e-mail in error, please notify the sender immediately by reply e-mail and delete this message.
Re: [HACKERS] [patch] build issues on Win32
Tom Lane t...@sss.pgh.pa.us writes: Any such platform would already be contending with plpgsql not working, encoding conversion not working, etc etc. It's barely conceivable that a client-only installation would be useful. Uh, I don't understand why it's so hard to conceive that someone might need the client library to access a database running on one machine from an application running on another. AFAICT the only case where anyone tries to do this is they have a personal preference to avoid shared libraries, for generally-pretty- darn-dubious reasons. Well, statically linked binaries are much easier to distribute, for one; and there are platforms where shared libraries simply do not exist, or where the entire system runs in a single namespace. Netware is still alive and kicking. DES -- Dag-Erling Smørgrav - d...@des.no -- 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] build issues on Win32
2010/3/12 Dag-Erling Smørgrav d...@des.no: Tom Lane t...@sss.pgh.pa.us writes: Any such platform would already be contending with plpgsql not working, encoding conversion not working, etc etc. It's barely conceivable that a client-only installation would be useful. Uh, I don't understand why it's so hard to conceive that someone might need the client library to access a database running on one machine from an application running on another. Well, in this specific case, we're talking Windows, right? Why not just distribute a libpq.dll along with the application, and you're done? It's not that people don't realize it may be useful. Just that it's not useful enough to enough people to put lots of workarounds in th ecode to make it work. AFAICT the only case where anyone tries to do this is they have a personal preference to avoid shared libraries, for generally-pretty- darn-dubious reasons. Well, statically linked binaries are much easier to distribute, for one; and there are platforms where shared libraries simply do not exist, or where the entire system runs in a single namespace. Netware is still alive and kicking. Do we even support netware on liboq? :-) -- 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] walreceiver is uninterruptible on win32
On Wed, Mar 10, 2010 at 10:09, Fujii Masao masao.fu...@gmail.com wrote: Hi, http://archives.postgresql.org/pgsql-hackers/2010-01/msg01672.php On win32, the blocking libpq functions like PQconnectdb() and PQexec() are uninterruptible since they use the vanilla select() instead of our signal emulation layer compatible select(). Nevertheless, currently walreceiver uses them to establish a connection, send a handshake message and wait for the reply. So walreceiver also becomes uninterruptible for a while. This is the must-fix problem for 9.0. I replaced the blocking libpq functions currently used with asynchronous ones, and used the emulated version of select() to wait, to make walreceiver interruptible. Here is the patch. These are issues that affect other things running libpq in the backend as well, right? Such as dblink? Perhaps we can factor out most of this into functions in backend/port/win32 so that we can re-use it fro there? -- 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] Dyamic updates of NEW with pl/pgsql
On Thu, Mar 11, 2010 at 11:24 PM, Alvaro Herrera alvhe...@commandprompt.com wrote: Merlin Moncure escribió: (small aside: the other biggie would be able to push a composite type in to an update statement...something like 'update foo set foo = new'). This is really great...some variant of this question is continually asked it seems. Can't you already do that with EXECUTE ... USING NEW? hmm, ah, but you have to specify the columns in NEW, so it doesn't really work for you, does it? right...with inserts you can expand the composite type without listing the columns. updates can't do it because of syntax issues, even if you go dynamic. 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] invalid UTF-8 via pl/perl
On Mon, 2010-03-08 at 21:52 -0500, Andrew Dunstan wrote: Tom Lane wrote: Hannu Krosing ha...@2ndquadrant.com writes: So SPI interface should also be fixed, either from perl side, or maybe from inside SPI ? SPI has every right to assume that data it's given is already in the database encoding. Yeah, looks like we missed a few spots. I have added three more checks that I think plug the remaining holes in plperl. Hannu, please test again against CVS HEAD. Seems to work now Do you plan to back-port this ? -- Hannu Krosing http://www.2ndQuadrant.com PostgreSQL Scalability and Availability Services, Consulting and Training -- 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] buildfarm logging versus embedded nulls
Andrew Dunstan and...@dunslane.net writes: Tom Lane wrote: I was looking at this recent nonrepeatable buildfarm failure: http://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=polecatdt=2010-03-11%2021:45:10 Well, the good news is that we actually have the data on the server, in a temp file that will be cleaned up, but hasn't been yet. I have placed a copy at http://buildfarm.postgresql.org/polecat-check.log.gz. Thanks for that. I found the relevant part of the postmaster log: [4b99671f.ddb4:36] LOG: statement: DELETE FROM vactst WHERE i != 0; [4b99671f.ddb4:37] LOG: statement: VACUUM (FULL) vactst; [4b99671f.ddb4:38] WARNING: pgstat wait timeout [4b99671f.ddb4:39] LOG: statement: DELETE FROM vactst; [4b99671f.ddb4:40] LOG: statement: SELECT * FROM vactst; [4b99671f.ddb4:41] LOG: statement: VACUUM (FULL, FREEZE) vactst; [4b99671f.ddb4:42] WARNING: pgstat wait timeout [4b99671f.ddb4:43] LOG: statement: VACUUM (ANALYZE, FULL) vactst; [4b99671f.ddb4:44] WARNING: pgstat wait timeout [4b99671f.ddb4:45] LOG: statement: CREATE TABLE vaccluster (i INT PRIMARY KEY); [4b99671f.ddb4:46] LOG: statement: ALTER TABLE vaccluster CLUSTER ON vaccluster_pkey; [4b99671f.ddb4:47] LOG: statement: INSERT INTO vaccluster SELECT * FROM vactst; [4b99671f.ddb4:48] LOG: statement: CLUSTER vaccluster; [4b99671f.ddb4:49] LOG: statement: VACUUM FULL pg_am; [4b99671f.ddb4:50] WARNING: pgstat wait timeout [4b99671f.ddb4:51] LOG: statement: VACUUM FULL pg_class; [4b99671f.ddb4:52] WARNING: pgstat wait timeout [4b99671f.ddb4:53] LOG: statement: VACUUM FULL pg_database; [4b99671f.ddb4:54] WARNING: pgstat wait timeout [4b99671f.ddb4:55] LOG: statement: VACUUM FULL vaccluster; [4b996707.dcc0:2] WARNING: pgstat wait timeout [4b99671f.ddb4:56] WARNING: pgstat wait timeout [4b99671f.ddb4:57] LOG: statement: VACUUM FULL vactst; [4b996707.dcc0:3] WARNING: pgstat wait timeout [4b996747.ddcc:1] WARNING: pgstat wait timeout [4b99671f.ddba:4] LOG: statement: INSERT INTO DEFAULT_TBL VALUES (1, 'thomas', 57.0613); Most of the pgstat wait timeout gripes are coming from the backend running the vacuum regression test, but there are two that came from process dcc0, which is shown by other log entries to be the autovacuum launcher. So now I'm wondering if there could be some issue that occurs when the autovac launcher and a backend both want stats concurrently. I have not got further than that in my uncaffeinated state --- anybody have any ideas? Now, the log_text field in our build_status_log table is text, so it's on insertion to the database that it gets truncated. I'm thinking that I should just escape nulls with a regex ( 's/\x00/\\0/g' or similar) before inserting the data. Works for me. 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] invalid UTF-8 via pl/perl
Hannu Krosing wrote: On Mon, 2010-03-08 at 21:52 -0500, Andrew Dunstan wrote: Tom Lane wrote: Hannu Krosing ha...@2ndquadrant.com writes: So SPI interface should also be fixed, either from perl side, or maybe from inside SPI ? SPI has every right to assume that data it's given is already in the database encoding. Yeah, looks like we missed a few spots. I have added three more checks that I think plug the remaining holes in plperl. Hannu, please test again against CVS HEAD. Seems to work now Do you plan to back-port this ? I wasn't going to. The previous fixes weren't backpatched either, and in general when we have plugged encoding holes the changes have not been backpatched, on the grounds that it would be a behaviour change, e.g. when we tightened things a lot for 8.3. I think there an outstanding TODO to plug the other PLs, however. It's a pity it has to be done over and over for each PL. Maybe we need some new versions of some of the SPI calls that would do the checking so it could be centralized. cheers andrew -- 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] buildfarm logging versus embedded nulls
Tom Lane wrote: Most of the pgstat wait timeout gripes are coming from the backend running the vacuum regression test, but there are two that came from process dcc0, which is shown by other log entries to be the autovacuum launcher. So now I'm wondering if there could be some issue that occurs when the autovac launcher and a backend both want stats concurrently. Seems like this issue would exist whenever two backends want stats concurrently, no? Is this well-tested? -- Alvaro Herrerahttp://www.CommandPrompt.com/ PostgreSQL Replication, Consulting, Custom Development, 24x7 support -- 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] buildfarm logging versus embedded nulls
Tom Lane wrote: Now, the log_text field in our build_status_log table is text, so it's on insertion to the database that it gets truncated. I'm thinking that I should just escape nulls with a regex ( 's/\x00/\\0/g' or similar) before inserting the data. Works for me. Done. cheers andrew -- 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] [BUGS] log : bad file dscriptor????
Gurjeet Singh singh.gurj...@gmail.com writes: It seems this commit never made it to the release notes. A customer came asking for the fix to this very problem, and although we know that the issue has been fixed, we could not refer him to the release notes. All we could suggest was to do the minor upgrade. We sometimes deem fixes too small/obscure to be worth documenting in the release notes, but this one should have been documented. I'm not sure if this was my misjudgment or Bruce's, but in any case apologies for the omission. If you need to convince somebody that the patch was in fact applied, you could always point them at the commit log archives: http://archives.postgresql.org/pgsql-committers/2009-03/msg00125.php 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] buildfarm logging versus embedded nulls
Alvaro Herrera alvhe...@commandprompt.com writes: Tom Lane wrote: Most of the pgstat wait timeout gripes are coming from the backend running the vacuum regression test, but there are two that came from process dcc0, which is shown by other log entries to be the autovacuum launcher. So now I'm wondering if there could be some issue that occurs when the autovac launcher and a backend both want stats concurrently. Seems like this issue would exist whenever two backends want stats concurrently, no? Is this well-tested? Well, you tell me how much it's been tested ;-). But the autovac launcher could possibly interact differently than another backend, since it has a different value for maximum stats file age. Anyway it's only a guess. It could well be that that machine was simply so heavily loaded that the stats collector couldn't respond fast enough. I'm just wondering whether there's an unrecognized bug lurking here. 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] buildfarm logging versus embedded nulls
Robert Creager wrote: On Mar 11, 2010, at 6:00 PM, Andrew Dunstan wrote: Tom Lane wrote: I was looking at this recent nonrepeatable buildfarm failure: http://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=polecatdt=2010-03-11%2021:45:10 which has several instances of the known pgstat wait timeout problem during the parallel regression tests. You've got me trained well now. I'm now looking at my build machine failures. Wasn't sure what to do about that one, since no relevant files changed. Is there any value in setting keep_error_builds = 0,? I know Andrew was able to get the complete log file. You normally want this as 0, to avoid eating up disk space. You certainly don't want it non-zero for long unless you have many Gb to spare. I doubt keeping this particular build would have helped much. The build was probably fine, the bug is apparently triggered by some hard to repeat timing condition, from what I gather from Tom's analysis. And from now on we will not have logs truncated by the presence of nul bytes. cheers andrew -- 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] buildfarm logging versus embedded nulls
Robert Creager rob...@logicalchaos.org writes: Is there any value in setting keep_error_builds = 0,? I know Andrew was able to get the complete log file. The data is all uploaded to the buildfarm server, so as long as EDB doesn't holler uncle about the amount of storage that's taking, I don't think you need to keep 'em locally. 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] buildfarm logging versus embedded nulls
Tom Lane wrote: Robert Creager rob...@logicalchaos.org writes: Is there any value in setting keep_error_builds = 0,? I know Andrew was able to get the complete log file. The data is all uploaded to the buildfarm server, so as long as EDB doesn't holler uncle about the amount of storage that's taking, I don't think you need to keep 'em locally. Er, that's CMD who host it. Credit where credit is due ;-) One of these days they will get upset and we'll purge the back logs so we only keep the last 6 months or a year. cheers andrew -- 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 Wed, Mar 10, 2010 at 07:50:16AM -0500, Andrew Dunstan wrote:
hubert depesz lubaczewski wrote:
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
well, it's possible. it's just not nice.
http://www.depesz.com/index.php/2010/03/10/dynamic-updates-of-fields-in-new-in-plpgsql/
Using an hstore in 9.0 it's not too bad, Try something like:
CREATE OR REPLACE FUNCTION dyntrig()
RETURNS trigger
LANGUAGE plpgsql
AS $function$
declare
hst hstore;
begin
hst := hstore(NEW);
hst := hst || ('foo' = 'bar');
NEW := populate_record(NEW,hst);
return NEW;
end;
$function$;
But this question probably belongs on -general rather than -hackers.
This is, by the way, an excellent argument for including hstore in
core in 9.1. :)
Cheers,
David.
--
David Fetter da...@fetter.org http://fetter.org/
Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter
Skype: davidfetter XMPP: david.fet...@gmail.com
iCal: webcal://www.tripit.com/feed/ical/people/david74/tripit.ics
Remember to vote!
Consider donating to Postgres: http://www.postgresql.org/about/donate
--
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
Andrew Dunstan wrote:
Bruce Momjian wrote:
+ /* If it was 'invalid authorization', add .pgpass mention */
+ if (conn-dot_pgpass_used conn-password_needed conn-result
+ /* only works with = 9.0 servers */
+ strcmp(PQresultErrorField(conn-result, PG_DIAG_SQLSTATE),
+ ERRCODE_INVALID_PASSWORD_SPECIFICATION) == 0)
+ appendPQExpBufferStr(conn-errorMessage,
+ libpq_gettext(password retrieved from .pgpass\n));
Surely we should use the name of the actual file from which the password
was retrieved here, which could be quite different from .pgpass (see
PGPASSFILE environment setting) and is different by default on Windows
anyway. Using a hardcoded .pgpass in those situations could be quite
confusing.
Agreed, very good idea. Update patch attached.
--
Bruce Momjian br...@momjian.ushttp://momjian.us
EnterpriseDB http://enterprisedb.com
PG East: http://www.enterprisedb.com/community/nav-pg-east-2010.do
Index: doc/src/sgml/errcodes.sgml
===
RCS file: /cvsroot/pgsql/doc/src/sgml/errcodes.sgml,v
retrieving revision 1.28
diff -c -c -r1.28 errcodes.sgml
*** doc/src/sgml/errcodes.sgml 7 Dec 2009 05:22:21 - 1.28
--- doc/src/sgml/errcodes.sgml 12 Mar 2010 16:53:22 -
***
*** 761,766
--- 761,772
entryinvalid_authorization_specification/entry
/row
+ row
+ entryliteral28P01/literal/entry
+ entryINVALID PASSWORD/entry
+ entryinvalid_password/entry
+ /row
+
row
entry spanname=span13emphasis role=boldClass 2B mdash; Dependent Privilege Descriptors Still Exist//entry
Index: src/backend/libpq/auth.c
===
RCS file: /cvsroot/pgsql/src/backend/libpq/auth.c,v
retrieving revision 1.195
diff -c -c -r1.195 auth.c
*** src/backend/libpq/auth.c 26 Feb 2010 02:00:42 - 1.195
--- src/backend/libpq/auth.c 12 Mar 2010 16:53:24 -
***
*** 232,238
auth_failed(Port *port, int status)
{
const char *errstr;
!
/*
* If we failed due to EOF from client, just quit; there's no point in
* trying to send a message to the client, and not much point in logging
--- 232,239
auth_failed(Port *port, int status)
{
const char *errstr;
! int errcode_return = ERRCODE_INVALID_AUTHORIZATION_SPECIFICATION;
!
/*
* If we failed due to EOF from client, just quit; there's no point in
* trying to send a message to the client, and not much point in logging
***
*** 269,274
--- 270,277
case uaMD5:
case uaPassword:
errstr = gettext_noop(password authentication failed for user \%s\);
+ /* We use it to indicate if a .pgpass password failed. */
+ errcode_return = ERRCODE_INVALID_PASSWORD;
break;
case uaPAM:
errstr = gettext_noop(PAM authentication failed for user \%s\);
***
*** 285,291
}
ereport(FATAL,
! (errcode(ERRCODE_INVALID_AUTHORIZATION_SPECIFICATION),
errmsg(errstr, port-user_name)));
/* doesn't return */
}
--- 288,294
}
ereport(FATAL,
! (errcode(errcode_return),
errmsg(errstr, port-user_name)));
/* doesn't return */
}
Index: src/include/utils/errcodes.h
===
RCS file: /cvsroot/pgsql/src/include/utils/errcodes.h,v
retrieving revision 1.31
diff -c -c -r1.31 errcodes.h
*** src/include/utils/errcodes.h 2 Jan 2010 16:58:10 - 1.31
--- src/include/utils/errcodes.h 12 Mar 2010 16:53:24 -
***
*** 194,199
--- 194,200
/* Class 28 - Invalid Authorization Specification */
#define ERRCODE_INVALID_AUTHORIZATION_SPECIFICATION MAKE_SQLSTATE('2','8', '0','0','0')
+ #define ERRCODE_INVALID_PASSWORD MAKE_SQLSTATE('2','8', 'P','0','1')
/* Class 2B - Dependent Privilege Descriptors Still Exist */
#define ERRCODE_DEPENDENT_PRIVILEGE_DESCRIPTORS_STILL_EXIST MAKE_SQLSTATE('2','B', '0','0','0')
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 12 Mar 2010 16:53:25 -
***
*** 91,96
--- 91,99
*/
#define ERRCODE_APPNAME_UNKNOWN 42704
+ /* This is part of the protocol so just define it */
+ #define ERRCODE_INVALID_PASSWORD 28P01
+
/*
* fall back options if they are not specified by arguments or defined
* by environment variables
***
*** 284,289
--- 287,294
static char *pwdfMatchesString(char *buf, char *token);
static char *PasswordFromFile(char *hostname, char *port, char *dbname,
char *username);
+ static bool getPgPassFilename(char
Re: [HACKERS] buildfarm logging versus embedded nulls
On Mar 11, 2010, at 6:00 PM, Andrew Dunstan wrote: Tom Lane wrote: I was looking at this recent nonrepeatable buildfarm failure: http://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=polecatdt=2010-03-11%2021:45:10 which has several instances of the known pgstat wait timeout problem during the parallel regression tests. You've got me trained well now. I'm now looking at my build machine failures. Wasn't sure what to do about that one, since no relevant files changed. Is there any value in setting keep_error_builds = 0,? I know Andrew was able to get the complete log file. Cheers, Rob -- 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] [GENERAL] trouble with to_char('L')
Takahiro Itagaki wrote:
Bruce Momjian br...@momjian.us wrote:
OK, I have created a new function, win32_wchar_to_db_encoding(), to
share the conversion from wide characters to the database encoding.
New patch attached.
Since 9.0 has GetPlatformEncoding() for the purpose, we could simplify
db_encoding_strdup() with the function. Like this:
static char *
db_encoding_strdup(const char *str)
{
char *pstr;
char *mstr;
/* convert the string to the database encoding */
pstr = (char *) pg_do_encoding_conversion(
(unsigned char *) str,
strlen(str),
GetPlatformEncoding(),
GetDatabaseEncoding());
mstr = strdup(pstr);
if (pstr != str)
pfree(pstr);
return mstr;
}
I beleive the code is harmless on all platforms and we can use it
instead of strdup() without any #ifdef WIN32 quotes.
OK, I don't have any Win32 people testing this patch so if we want this
fixed for 9.0 someone is going to have to test my patch to see that it
works. Can you make the adjustments suggested above to my patch and
test it to see that it works so we can apply it for 9.0?
BTW, I found we'd better to add ANSI_X3.4-1968 as an alias for
PG_SQL_ASCII. My Fedora 12 returns the name when --no-locale is used.
OK.
--
Bruce Momjian br...@momjian.ushttp://momjian.us
EnterpriseDB http://enterprisedb.com
PG East: http://www.enterprisedb.com/community/nav-pg-east-2010.do
--
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] Reposnse from backend when wrong user/database request send
Tatsuo Ishii is...@postgresql.org writes: It seems between 8.4 and CVS HEAD backend responses 'E' packet (error/fatal message) if a startup packet sent with wrong user and/or database. Before backend responses 'R' packet first followd by 'E' packet. Does anybody know why this change made? It's a side effect of the changes made to get rid of the flat authorization files. Bad database is now reported before authentication instead of after. I wouldn't have thought bad user per se would be reported before auth, though --- you sure about that one? 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] Dyamic updates of NEW with pl/pgsql
2010/3/12 David Fetter da...@fetter.org:
On Wed, Mar 10, 2010 at 07:50:16AM -0500, Andrew Dunstan wrote:
hubert depesz lubaczewski wrote:
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
well, it's possible. it's just not nice.
http://www.depesz.com/index.php/2010/03/10/dynamic-updates-of-fields-in-new-in-plpgsql/
Using an hstore in 9.0 it's not too bad, Try something like:
CREATE OR REPLACE FUNCTION dyntrig()
RETURNS trigger
LANGUAGE plpgsql
AS $function$
declare
hst hstore;
begin
hst := hstore(NEW);
hst := hst || ('foo' = 'bar');
NEW := populate_record(NEW,hst);
return NEW;
end;
$function$;
But this question probably belongs on -general rather than -hackers.
This is, by the way, an excellent argument for including hstore in
core in 9.1. :)
I like it - but it looking little bit strange - I thinking we need
only one function (maybe with some special support from pl executor)
begin
update_field(NEW, 'field', value);
Pavel
Cheers,
David.
--
David Fetter da...@fetter.org http://fetter.org/
Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter
Skype: davidfetter XMPP: david.fet...@gmail.com
iCal: webcal://www.tripit.com/feed/ical/people/david74/tripit.ics
Remember to vote!
Consider donating to Postgres: http://www.postgresql.org/about/donate
--
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 Fri, Mar 12, 2010 at 07:35:41PM +0100, Pavel Stehule wrote: 2010/3/12 David Fetter da...@fetter.org: This is, by the way, an excellent argument for including hstore in core in 9.1. :) I like it - but it looking little bit strange - I thinking we need only one function (maybe with some special support from pl executor) begin update_field(NEW, 'field', value); This doesn't seem like a terribly useful addition, it being specific to PL/pgsql. Then there's the quoting issue, which the above doesn't quite address. Putting hstore in would let all the other PLs use it, to the extent that they need such a thing. :) Cheers, David. -- David Fetter da...@fetter.org http://fetter.org/ Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter Skype: davidfetter XMPP: david.fet...@gmail.com iCal: webcal://www.tripit.com/feed/ical/people/david74/tripit.ics Remember to vote! Consider donating to Postgres: http://www.postgresql.org/about/donate -- 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 Fri, Mar 12, 2010 at 10:47:45AM -0800, David Fetter wrote: On Fri, Mar 12, 2010 at 07:35:41PM +0100, Pavel Stehule wrote: 2010/3/12 David Fetter da...@fetter.org: This is, by the way, an excellent argument for including hstore in core in 9.1. :) I like it - but it looking little bit strange - I thinking we need only one function (maybe with some special support from pl executor) begin update_field(NEW, 'field', value); This doesn't seem like a terribly useful addition, it being specific to PL/pgsql. Then there's the quoting issue, which the above doesn't quite address. Putting hstore in would let all the other PLs use it, to the extent that they need such a thing. :) Plus pure SQL use ! I was considering using hstore for a table value too for a form of historic table. Just to say I'd also be happy with it being core in pgsql :) --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] Server crash with older tzload library
Jeevan Chalke jeevan.cha...@enterprisedb.com writes: In summary, following are the steps to re-produce: - Add above three lines at the beginning of the pg_tzset() function - make install - mv install/share/postgresql/timezone/posixrules install/share/postgresql/timezoneposixrules_a (or remove it) - start the server - run these two statements on psql prompt + SET TimeZone = 'GMT+3:30'; + SELECT '1969-12-31 20:30:00'::timestamptz; BTW, after your commit, tzload() function now sets goback and goahead variable to FALSE which fixes the server crash. MemSet in 2010c is just doing it explicitly before calling tzload though. Mph. I still can't reproduce a crash even after doing all that and reverting the goback/goahead change. However, it seems to me that that last indicates that this is the same problem discussed on the upstream tz mailing list in early February, and their fix was to move the goback/goahead initialization, ie they fixed it between 2010a and 2010c. So I think we're good (except that this is another reason why we'd be well advised to back-port tzcode2010c into our older branches). If we were to insert a memset I think that pg_tzset is the wrong place for it anyway. If tzload or tzparse returns 0, then pg_tzset is entitled to assume that those functions have set up valid tzstate structure contents, so it should be on their head to zero the struct if that were needed. This was in fact proposed upstream (cf ado's message of 16 Feb 2010 17:33:28) but they eventually chose to just clear the goback/goahead fields there. I feel no need to diverge from their solution. 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] Dyamic updates of NEW with pl/pgsql
2010/3/12 strk s...@keybit.net: On Fri, Mar 12, 2010 at 10:47:45AM -0800, David Fetter wrote: On Fri, Mar 12, 2010 at 07:35:41PM +0100, Pavel Stehule wrote: 2010/3/12 David Fetter da...@fetter.org: This is, by the way, an excellent argument for including hstore in core in 9.1. :) I like it - but it looking little bit strange - I thinking we need only one function (maybe with some special support from pl executor) begin update_field(NEW, 'field', value); This doesn't seem like a terribly useful addition, it being specific to PL/pgsql. Then there's the quoting issue, which the above doesn't quite address. Putting hstore in would let all the other PLs use it, to the extent that they need such a thing. :) Plus pure SQL use ! I was considering using hstore for a table value too for a form of historic table. Just to say I'd also be happy with it being core in pgsql :) I see some disadvantages a) non intuitive name - hstore is very specific name b) effectivity (mainly inside trigger body) - plpgsql specific construct can be 10x faster. I would to see hash tables in core too, but I don't think so it is good solution for record updating. Regards 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] Server crash with older tzload library
Heikki Linnakangas heikki.linnakan...@enterprisedb.com writes: Tom Lane wrote: It strikes me that maybe we are putting ourselves at risk by blithely pushing tzdata updates into back branches without also pushing tzcode updates. I believe they're designed to be compatible both ways, I remember that the 64-bit changes in particular were done in such a way that new tzdata files work with older tzcode versions. I don't know if anyone else is testing various combinations, though, so it probably would be good to update tzcode anyway. I wouldn't really expect a massive failure, but I am worried about the possibility of misbehavior in corner-case timezones, such as those with a very large number of DST rule changes. Also there is the risk of unfixed bugs in the tzcode functions themselves. It's not clear to me for example whether the crash bug Jeevan's been on about was introduced in the 64bit tzcode changes or is a pre-existing problem. However, doing this would mean updating the back branches for 64bit tzdata, which is not a small change. Heikki, do you remember how much that patch affected stuff outside the tzcode files proper? There was no changes outside tzcode files. OK, I'm going to double-check that and then back-patch the current tzcode files. It's too late for the upcoming releases but probably it's just as well for this to sit awhile in CVS before we ship it. We'll at least get some buildfarm cycles on it... 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] Server crash with older tzload library
I wrote: OK, I'm going to double-check that and then back-patch the current tzcode files. Oh, wait, belay that. If we do that, we will be retroactively breaking the no-working-64-bit-integer-type support in the older branches. Probably not a good thing to do in minor releases. I guess we'll just have to wait and see if any problems get reported. I can't see going to the effort of making the new tzcode stuff behave gracefully without int64. 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] Dyamic updates of NEW with pl/pgsql
strk írta: On Fri, Mar 12, 2010 at 10:47:45AM -0800, David Fetter wrote: On Fri, Mar 12, 2010 at 07:35:41PM +0100, Pavel Stehule wrote: 2010/3/12 David Fetter da...@fetter.org: This is, by the way, an excellent argument for including hstore in core in 9.1. :) I like it - but it looking little bit strange - I thinking we need only one function (maybe with some special support from pl executor) begin update_field(NEW, 'field', value); This doesn't seem like a terribly useful addition, it being specific to PL/pgsql. Then there's the quoting issue, which the above doesn't quite address. Putting hstore in would let all the other PLs use it, to the extent that they need such a thing. :) Plus pure SQL use ! What's wrong with UPDATE foo SET (foo) = (NEW); ? I know it's a little ambiguous, as table foo can have fields named foo and new, but the UPDATE foo SET (field, ...) = (value, ...); works in plain SQL and the (...) usually denotes a list with more than one field/value. pl/pgSQL could treat the list with single name as a special case (maybe checking whether the table has fields foo, new and/or old and issue a warning when relevant) and treat the above as a whole-row update. Best regards, Zoltán Böszörményi -- Bible has answers for everything. Proof: But let your communication be, Yea, yea; Nay, nay: for whatsoever is more than these cometh of evil. (Matthew 5:37) - basics of digital technology. May your kingdom come - superficial description of plate tectonics -- Zoltán Böszörményi Cybertec Schönig Schönig GmbH http://www.postgresql.at/ -- 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 Fri, Mar 12, 2010 at 3:01 PM, Boszormenyi Zoltan z...@cybertec.at wrote: What's wrong with UPDATE foo SET (foo) = (NEW); ? amen brother! :-) I say though, since you can do: SELECT foo FROM foo; why not UPDATE foo SET foo = new;? 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] buildfarm logging versus embedded nulls
I wrote: Anyway it's only a guess. It could well be that that machine was simply so heavily loaded that the stats collector couldn't respond fast enough. I'm just wondering whether there's an unrecognized bug lurking here. Still meditating on this ... and it strikes me that the pgstat.c code is really uncommunicative about problems. In particular, pgstat_read_statsfile_timestamp and pgstat_read_statsfile don't complain at all about being unable to read a stats file. It seems to me that the only expected case is ENOENT (and even that isn't really expected, in normal operation). Surely we should at least elog(LOG) any other failure condition? Another place that could probably do with elog(LOG) is where pgstat_write_statsfile resets last_statrequest in case it's in the future. That shouldn't ever happen. While the reset is probably a good thing for robustness, wouldn't logging it be a good idea? Lastly, backend_read_statsfile is designed to send an inquiry message every time through the loop, ie, every 10 msec. This is said to be in case the stats collector drops one. But is this enough to flood the collector and make things worse? I wonder if there should be some backoff there. 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] Dyamic updates of NEW with pl/pgsql
Merlin Moncure írta: On Fri, Mar 12, 2010 at 3:01 PM, Boszormenyi Zoltan z...@cybertec.at wrote: What's wrong with UPDATE foo SET (foo) = (NEW); ? amen brother! :-) I say though, since you can do: SELECT foo FROM foo; why not UPDATE foo SET foo = new;? I just tried this: zozo=# create table foo (foo integer, bar integer); CREATE TABLE zozo=# insert into foo values (1, 2), (2, 4); INSERT 0 2 zozo=# select foo from foo; foo - 1 2 (2 rows) zozo=# create table foo1 (foo integer, bar integer); CREATE TABLE zozo=# insert into foo1 values (1, 2), (2, 4); INSERT 0 2 zozo=# select foo1 from foo1; foo1 --- (1,2) (2,4) (2 rows) So, if the table has field that's name is the same as the table name then SELECT foo FROM foo; returns the field, not the whole row, it's some kind of a precedence handling. What we could do is the reverse precedence with UPDATE foo SET foo = 3 WHERE foo = 1; vs UPDATE foo SET (foo) = (1,3) WHERE (foo) = (1,2); Note the WHERE condition, I would expect it to work there, too. If it works in plain SQL then no special casing would be needed in PLs. Best regards, Zoltán Böszörményi -- Bible has answers for everything. Proof: But let your communication be, Yea, yea; Nay, nay: for whatsoever is more than these cometh of evil. (Matthew 5:37) - basics of digital technology. May your kingdom come - superficial description of plate tectonics -- Zoltán Böszörményi Cybertec Schönig Schönig GmbH http://www.postgresql.at/ -- 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] buildfarm logging versus embedded nulls
Tom Lane wrote: I wrote: Anyway it's only a guess. It could well be that that machine was simply so heavily loaded that the stats collector couldn't respond fast enough. I'm just wondering whether there's an unrecognized bug lurking here. Still meditating on this ... and it strikes me that the pgstat.c code is really uncommunicative about problems. In particular, pgstat_read_statsfile_timestamp and pgstat_read_statsfile don't complain at all about being unable to read a stats file. Yeah, I had the same thought. Lastly, backend_read_statsfile is designed to send an inquiry message every time through the loop, ie, every 10 msec. This is said to be in case the stats collector drops one. But is this enough to flood the collector and make things worse? I wonder if there should be some backoff there. I also think the autovacuum worker minimum timestamp may be playing games with the retry logic too. Maybe a worker is requesting a new file continuously because pgstat is not able to provide one before the deadline is past, and thus overloading it. I still think that 500ms is too much for a worker, but backing off all the way to 10ms seems too much. Maybe it should just be, say, 100ms. -- Alvaro Herrerahttp://www.CommandPrompt.com/ PostgreSQL Replication, Consulting, Custom Development, 24x7 support -- 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] Reposnse from backend when wrong user/database request send
Tatsuo Ishii is...@postgresql.org writes: It seems between 8.4 and CVS HEAD backend responses 'E' packet (error/fatal message) if a startup packet sent with wrong user and/or database. Before backend responses 'R' packet first followd by 'E' packet. Does anybody know why this change made? It's a side effect of the changes made to get rid of the flat authorization files. Bad database is now reported before authentication instead of after. I wouldn't have thought bad user per se would be reported before auth, though --- you sure about that one? No. Just a logical conjecture. So the change was made not to fix the bug(IMO). I now understand that those behavior could be changed randomly release to relase in unpredictable way. -- Tatsuo Ishii SRA OSS, Inc. Japan English: http://www.sraoss.co.jp/index_en.php Japanese: http://www.sraoss.co.jp -- 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] buildfarm logging versus embedded nulls
Alvaro Herrera alvhe...@commandprompt.com writes: Tom Lane wrote: Still meditating on this ... and it strikes me that the pgstat.c code is really uncommunicative about problems. In particular, pgstat_read_statsfile_timestamp and pgstat_read_statsfile don't complain at all about being unable to read a stats file. Yeah, I had the same thought. OK, I'll add some logging. Lastly, backend_read_statsfile is designed to send an inquiry message every time through the loop, ie, every 10 msec. This is said to be in case the stats collector drops one. But is this enough to flood the collector and make things worse? I wonder if there should be some backoff there. I also think the autovacuum worker minimum timestamp may be playing games with the retry logic too. Maybe a worker is requesting a new file continuously because pgstat is not able to provide one before the deadline is past, and thus overloading it. I still think that 500ms is too much for a worker, but backing off all the way to 10ms seems too much. Maybe it should just be, say, 100ms. But we don't advance the deadline within the wait loop, so (in theory) a single requestor shouldn't be able to trigger more than one stats file update. I wonder though if an autovac worker could make many such requests over its lifespan ... 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] Reposnse from backend when wrong user/database request send
Tatsuo Ishii is...@postgresql.org writes: Tatsuo Ishii is...@postgresql.org writes: It seems between 8.4 and CVS HEAD backend responses 'E' packet (error/fatal message) if a startup packet sent with wrong user and/or database. Before backend responses 'R' packet first followd by 'E' packet. I now understand that those behavior could be changed randomly release to relase in unpredictable way. I think the protocol specification is pretty explicit that you shouldn't be relying on specific sequences of events where it's not logically necessary that things happen in a particular order. It's always been possible for a connection to be rejected before any 'R' is sent; we've only made a minor change in the set of error cases for which that's true. 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] Dyamic updates of NEW with pl/pgsql
On Fri, Mar 12, 2010 at 4:24 PM, Boszormenyi Zoltan z...@cybertec.at wrote: Merlin Moncure írta: On Fri, Mar 12, 2010 at 3:01 PM, Boszormenyi Zoltan z...@cybertec.at wrote: What's wrong with UPDATE foo SET (foo) = (NEW); ? amen brother! :-) I say though, since you can do: SELECT foo FROM foo; why not UPDATE foo SET foo = new;? I just tried this: zozo=# create table foo (foo integer, bar integer); CREATE TABLE zozo=# insert into foo values (1, 2), (2, 4); INSERT 0 2 zozo=# select foo from foo; foo - 1 2 (2 rows) But you can always get around this with, e.g. SELECT v FROM foo v; ...Robert -- 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] buildfarm logging versus embedded nulls
Tom Lane wrote: Alvaro Herrera alvhe...@commandprompt.com writes: I also think the autovacuum worker minimum timestamp may be playing games with the retry logic too. Maybe a worker is requesting a new file continuously because pgstat is not able to provide one before the deadline is past, and thus overloading it. I still think that 500ms is too much for a worker, but backing off all the way to 10ms seems too much. Maybe it should just be, say, 100ms. But we don't advance the deadline within the wait loop, so (in theory) a single requestor shouldn't be able to trigger more than one stats file update. Hmm, yeah. I wonder though if an autovac worker could make many such requests over its lifespan ... Well, yes, but it will request fresh stats only for the recheck logic before each table, so there will be one intervening vacuum (or none, actually, if the table was vacuumed by some other autovac worker. Though given the default naptime of 1 min I find it unlikely that the regression database will ever see more than one worker). Since the warning comes from the launcher and not the worker, I wonder if this is a red herring. -- Alvaro Herrerahttp://www.CommandPrompt.com/ PostgreSQL Replication, Consulting, Custom Development, 24x7 support -- 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] buildfarm logging versus embedded nulls
Alvaro Herrera alvhe...@commandprompt.com writes: Since the warning comes from the launcher and not the worker, I wonder if this is a red herring. It's all speculation at the moment. So far there's not really enough evidence to refute the idea that the system was just under heavy load at that point --- except that even under heavy load it shouldn't take the stats collector 5 seconds to write the stats file for the regression database, ISTM. I wonder if there is any practical way for the buildfarm client script to report about the system's load average, or some other gauge of how much is going on in the buildfarm machine besides the regression tests. One thought is just to log how long it takes to run the regression tests. A longer-than-usual run for a particular animal would be evidence of a load spike; if we could correlate that with failures of this sort it would be easier to write them off as heavy load. 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] Reposnse from backend when wrong user/database request send
Tatsuo Ishii is...@postgresql.org writes:
Tatsuo Ishii is...@postgresql.org writes:
It seems between 8.4 and CVS HEAD backend responses 'E' packet
(error/fatal message) if a startup packet sent with wrong user and/or
database. Before backend responses 'R' packet first followd by 'E'
packet.
I now understand that those behavior could be changed randomly release
to relase in unpredictable way.
I think the protocol specification is pretty explicit that you shouldn't
be relying on specific sequences of events where it's not logically
necessary that things happen in a particular order. It's always been
possible for a connection to be rejected before any 'R' is sent; we've
only made a minor change in the set of error cases for which that's
true.
No. I would say CVS HEAD's behavior that it returns 'E' first is ok if
it is given wrong database.
Problem is in 8.4 or before and HEAD returns Authentication ok
('R'+0x8+0x0) then 'E' if wrong user is given. How come backend says
Great! authentication ok then Sorry your database is wrong so
authentican failed. FYI 8.4 or before always returns Authentication
ok then 'E' if user and/or database is wrong.
Maybe we should change AuthenticationOK to AuthenticationMaybeOK?:-)
--
Tatsuo Ishii
SRA OSS, Inc. Japan
English: http://www.sraoss.co.jp/index_en.php
Japanese: http://www.sraoss.co.jp
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] Re: [BUGS] BUG #5021: ts_parse doesn't recognize email addresses with underscores
Teodor Sigaev wrote:
Oleg, Teodor, can you look at this? I tried to fix it in wparser_def.c,
but couldn't figure out how. Thanks.
select distinct token as email
from ts_parse('default', ' first_l...@yahoo.com ' )
where tokid = 4
Patch in attachment, it allows underscore in the middle of local part of
email
in in host name (similarly to '-' character).
Thanks, patch applied.
I'm not sure about backpatching, because it could break existing search
configuration.
Agreed. I don't think this warrants backpatching.
Here is the before behavior:
test= select ts_parse('default', ' first_l...@yahoo.com ' );
ts_parse
(12, )
(1,first)
(12,_)
-- (4,l...@yahoo.com)
(12, )
(5 rows)
and the after-patch, fixed behavior:
test= select ts_parse('default', ' first_l...@yahoo.com ' );
ts_parse
--
(12, )
-- (4,first_l...@yahoo.com)
(12, )
(3 rows)
I assume because this only expands the pattern space for email addresses
that there is no affect on binary upgrades with this patch. Is that
correct? Would an email address check on a binary-upgraded tsvector
index not match an email address with underscores? Do we need a warning
in the release notes about this?
--
Bruce Momjian br...@momjian.ushttp://momjian.us
EnterpriseDB http://enterprisedb.com
PG East: http://www.enterprisedb.com/community/nav-pg-east-2010.do
--
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: [BUGS] BUG #5021: ts_parse doesn't recognize email addresses with underscores
Upon seeing this patch I considered that I use addresses such as alvherre+st...@something.org and wondered how could this thing support that. I don't think we want extra parser stuff just to add whatever random junk we want to support in email addresses ... -- Alvaro Herrerahttp://www.CommandPrompt.com/ The PostgreSQL Company - Command Prompt, Inc. -- 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] renameatt() can rename attribute of index, sequence, ...
2010/3/11 KaiGai Kohei kai...@ak.jp.nec.com: (2010/03/11 23:55), Robert Haas wrote: 2010/3/10 KaiGai Koheikai...@ak.jp.nec.com: Indeed, it is useful to allow renaming attribute of composite types. However, it is also useless to allow to rename attribute of sequences, but harmless, like renames on indexes. It seems to me it is fair enough to allow renaming attributes of tables, views and composite types... I don't agree. I think users should be allowed to rename things they had a hand in naming in the first place (and index columns fall into that category, since the names are derived from table column names). But changing system-assigned column names for sequences or toast tables is just weird. OK, the attached patch forbid to rename an attribute of relations except for tables, views, composite types and indexes. I would like to apply this for 9.0, with some adjustments to the comments. Objections? ...Robert -- 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: [BUGS] BUG #5021: ts_parse doesn't recognize email addresses with underscores
Alvaro Herrera wrote:
Upon seeing this patch I considered that I use addresses such as
alvherre+st...@something.org and wondered how could this thing support
that. I don't think we want extra parser stuff just to add whatever
random junk we want to support in email addresses ...
Well, I think the big question is whether we need to honor RFC 5322
(http://www.rfc-editor.org/rfc/rfc5322.txt). Wikipedia says these are
all valid characters:
http://en.wikipedia.org/wiki/E-mail_address
* Uppercase and lowercase English letters (a-z, A-Z)
* Digits 0 to 9
* Characters ! # $ % ' * + - / = ? ^ _ ` { | } ~
* Character . (dot, period, full stop) provided that it is not the
first or last character, and provided also that it does not appear two
or more times consecutively.
And we don't currently honor most of the special characters, including
plus:
test= select ts_parse('default', ' first+l...@yahoo.com ' );
ts_parse
(12, )
(1,first)
(12,+)
(4,l...@yahoo.com)
(12, )
(5 rows)
Where does this leave us? Do we add the other characters? Do we
document that we only allow a limited number of characters for email
addresses? What is the logic in that? Do any of these characters
conflict with our tsquery operators?
--
Bruce Momjian br...@momjian.ushttp://momjian.us
EnterpriseDB http://enterprisedb.com
PG East: http://www.enterprisedb.com/community/nav-pg-east-2010.do
--
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: [BUGS] BUG #5021: ts_parse doesn't recognize email addresses with underscores
Bruce Momjian br...@momjian.us writes:
Well, I think the big question is whether we need to honor RFC 5322
(http://www.rfc-editor.org/rfc/rfc5322.txt). Wikipedia says these are
all valid characters:
http://en.wikipedia.org/wiki/E-mail_address
* Uppercase and lowercase English letters (a-z, A-Z)
* Digits 0 to 9
* Characters ! # $ % ' * + - / = ? ^ _ ` { | } ~
* Character . (dot, period, full stop) provided that it is not the
first or last character, and provided also that it does not appear two
or more times consecutively.
That's an awful lot of special characters. For the RFC's purposes,
it's not hard to be flexible because in an email message there is
external context telling where to expect an address. I think if we
tried to allow all of those in email addresses in tsearch, we'd have
email addresses gobbling up a whole lot of adjacent text, to nobody's
benefit.
I can see the case for adding + because that's fairly common as Alvaro
notes, but I think we should be very circumspect about going farther.
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: [BUGS] BUG #5021: ts_parse doesn't recognize email addresses with underscores
Tom Lane wrote:
Bruce Momjian br...@momjian.us writes:
Well, I think the big question is whether we need to honor RFC 5322
(http://www.rfc-editor.org/rfc/rfc5322.txt). Wikipedia says these are
all valid characters:
http://en.wikipedia.org/wiki/E-mail_address
* Uppercase and lowercase English letters (a-z, A-Z)
* Digits 0 to 9
* Characters ! # $ % ' * + - / = ? ^ _ ` { | } ~
* Character . (dot, period, full stop) provided that it is not the
first or last character, and provided also that it does not appear two
or more times consecutively.
That's an awful lot of special characters. For the RFC's purposes,
it's not hard to be flexible because in an email message there is
external context telling where to expect an address. I think if we
tried to allow all of those in email addresses in tsearch, we'd have
email addresses gobbling up a whole lot of adjacent text, to nobody's
benefit.
I can see the case for adding + because that's fairly common as Alvaro
notes, but I think we should be very circumspect about going farther.
OK, I can add '+' using Teodor's patch as a guide, and document which
characters we support, and that we don't support all of them. What
about the binary upgrade issue? I am now worried that maybe we should
back out the patch and just document our restrictions.
--
Bruce Momjian br...@momjian.ushttp://momjian.us
EnterpriseDB http://enterprisedb.com
PG East: http://www.enterprisedb.com/community/nav-pg-east-2010.do
--
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: [BUGS] BUG #5021: ts_parse doesn't recognize email addresses with underscores
On Mar 12, 2010, at 5:18 PM, Tom Lane wrote:
Bruce Momjian br...@momjian.us writes:
Well, I think the big question is whether we need to honor RFC 5322
(http://www.rfc-editor.org/rfc/rfc5322.txt). Wikipedia says these are
all valid characters:
http://en.wikipedia.org/wiki/E-mail_address
* Uppercase and lowercase English letters (a-z, A-Z)
* Digits 0 to 9
* Characters ! # $ % ' * + - / = ? ^ _ ` { | } ~
* Character . (dot, period, full stop) provided that it is not the
first or last character, and provided also that it does not appear two
or more times consecutively.
That's an awful lot of special characters. For the RFC's purposes,
it's not hard to be flexible because in an email message there is
external context telling where to expect an address. I think if we
tried to allow all of those in email addresses in tsearch, we'd have
email addresses gobbling up a whole lot of adjacent text, to nobody's
benefit.
I can see the case for adding + because that's fairly common as Alvaro
notes, but I think we should be very circumspect about going farther.
I've been working with recognizing email addresses in text for
years, with many millions of documents processed. Recognizing
them in text is a very different problem to validating them or sanitizing
them. Using the RFC spec to match things that might be an email
address isn't a great idea in the wild, so +1 on the circumspect.
I've found that /[a-z0-9_][^\@\\s]{0,80})@/ is good at finding local parts
of real email addresses in free text in the wild, without getting being
too prone to grab things that just look vaguely like email addresses. Obviously
there are some things it'll match that aren't email addresses, and some
email addresses it won't match, but for indexing it's been really pretty
good when combined with a good regex for domain parts[1].
Cheers,
Steve
[1]
([a-z0-9_][^\@\\s]{0,80})@([a-z0-9._-]{0,252}\\.(?:[a-z]{2}|edu|com|net|org|gov|mil|info|biz|coop|museum|aero|name|pro|travel|jobs|mobi|tel|cat)
(Before you point out all the ways that differs from the RFC specs for
an email address, yes, I know, but that's the point. Real world usage
is not the same as RFC spec.) [2]
[2] This is the simplified version - the full version is marginally more
selective, at the expense of being much more complex.
--
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: [BUGS] BUG #5021: ts_parse doesn't recognize email addresses with underscores
Bruce Momjian br...@momjian.us writes: OK, I can add '+' using Teodor's patch as a guide, and document which characters we support, and that we don't support all of them. What about the binary upgrade issue? I am now worried that maybe we should back out the patch and just document our restrictions. The tsearch stuff is supposedly designed to be flexible about that. It's not really any different from changing your tsearch configuration midstream. You might not get matches that you would have liked to get, but there's not any internal inconsistency. 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: [BUGS] BUG #5021: ts_parse doesn't recognize email addresses with underscores
Tom Lane wrote: Bruce Momjian br...@momjian.us writes: OK, I can add '+' using Teodor's patch as a guide, and document which characters we support, and that we don't support all of them. What about the binary upgrade issue? I am now worried that maybe we should back out the patch and just document our restrictions. The tsearch stuff is supposedly designed to be flexible about that. It's not really any different from changing your tsearch configuration midstream. You might not get matches that you would have liked to get, but there's not any internal inconsistency. Glad you are not worried. ;-) What concerns me is if someone created a tsvector index or stored tsvector output in a table using the old rules, a new query might not match the binary-upgraded tsvector stored values. You are right that internally it is fine. -- Bruce Momjian br...@momjian.ushttp://momjian.us EnterpriseDB http://enterprisedb.com PG East: http://www.enterprisedb.com/community/nav-pg-east-2010.do -- 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: [BUGS] BUG #5021: ts_parse doesn't recognize email addresses with underscores
Steve Atkins wrote:
On Mar 12, 2010, at 5:18 PM, Tom Lane wrote:
Bruce Momjian br...@momjian.us writes:
Well, I think the big question is whether we need to honor RFC 5322
(http://www.rfc-editor.org/rfc/rfc5322.txt). Wikipedia says these are
all valid characters:
http://en.wikipedia.org/wiki/E-mail_address
* Uppercase and lowercase English letters (a-z, A-Z)
* Digits 0 to 9
* Characters ! # $ % ' * + - / = ? ^ _ ` { | } ~
* Character . (dot, period, full stop) provided that it is not the
first or last character, and provided also that it does not appear two
or more times consecutively.
That's an awful lot of special characters. For the RFC's purposes,
it's not hard to be flexible because in an email message there is
external context telling where to expect an address. I think if we
tried to allow all of those in email addresses in tsearch, we'd have
email addresses gobbling up a whole lot of adjacent text, to nobody's
benefit.
I can see the case for adding + because that's fairly common as Alvaro
notes, but I think we should be very circumspect about going farther.
I've been working with recognizing email addresses in text for
years, with many millions of documents processed. Recognizing
them in text is a very different problem to validating them or sanitizing
them. Using the RFC spec to match things that might be an email
address isn't a great idea in the wild, so +1 on the circumspect.
I've found that /[a-z0-9_][^\@\\s]{0,80})@/ is good at finding local parts
of real email addresses in free text in the wild, without getting being
too prone to grab things that just look vaguely like email addresses.
Obviously
there are some things it'll match that aren't email addresses, and some
email addresses it won't match, but for indexing it's been really pretty
good when combined with a good regex for domain parts[1].
OK, based on your experience, I think we have gone far enough by
allowing underscores. I have applied the attached patch to document
what symbols we do allow.
Just for thrills, I want to point out that even the description is not
accurate. Look what happens when a dash follows an underscore:
test= select ts_parse('default', ' a-...@yahoo.com ' );
ts_parse
-
(12, )
(4,a-...@yahoo.com)
(12, )
(3 rows)
test= select ts_parse('default', ' a-b...@yahoo.com ' );
ts_parse
-
(12, )
(16,a-b)
(11,a)
(12,-)
(11,b)
(12,-_)
(4,c...@yahoo.com)
(12, )
(8 rows)
--
Bruce Momjian br...@momjian.ushttp://momjian.us
EnterpriseDB http://enterprisedb.com
PG East: http://www.enterprisedb.com/community/nav-pg-east-2010.do
Index: doc/src/sgml/textsearch.sgml
===
RCS file: /cvsroot/pgsql/doc/src/sgml/textsearch.sgml,v
retrieving revision 1.53
diff -c -c -r1.53 textsearch.sgml
*** doc/src/sgml/textsearch.sgml 14 Aug 2009 14:53:20 - 1.53
--- doc/src/sgml/textsearch.sgml 13 Mar 2010 03:03:24 -
***
*** 1943,1948
--- 1943,1955
languages, token types literalword/ and literalasciiword/
should be treated alike.
/para
+
+para
+ literalemail/ does not support all valid email characters as
+ defined by RFC 5322. Specifically, the only non-alphanumeric
+ characters supported for email user names are period, dash, and
+ underscore.
+/para
/note
para
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] Getting to beta1
Where are we in getting to beta1? I know people are looking to me for 9.0 release notes and I will have them done in about a week, but what about open issues? I don't see many on the main 9.0 open items page: http://wiki.postgresql.org/wiki/PostgreSQL_9.0_Open_Items#Bugs The list has been reduced greatly in the past week. What about HS/SR open items? -- Bruce Momjian br...@momjian.ushttp://momjian.us EnterpriseDB http://enterprisedb.com PG East: http://www.enterprisedb.com/community/nav-pg-east-2010.do -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] pq_setkeepalives* functions
Hi,
In 2 of 3 pq_setkeepalives* functions we have the #DEFINE involving
even this conditional:
if (port == NULL || IS_AF_UNIX(port-laddr.addr.ss_family))
return STATUS_OK;
but in pq_setkeepalivesinterval() the #DEFINE is after the
conditional, doesn't seems to affect anything but for consistency with
the other two :)
--
Atentamente,
Jaime Casanova
Soporte y capacitación de PostgreSQL
Asesoría y desarrollo de sistemas
Guayaquil - Ecuador
Cel. +59387171157
Index: src/backend/libpq/pqcomm.c
===
RCS file: /home/postgres/pgrepo/pgsql/src/backend/libpq/pqcomm.c,v
retrieving revision 1.205
diff -c -r1.205 pqcomm.c
*** src/backend/libpq/pqcomm.c 26 Feb 2010 02:00:43 - 1.205
--- src/backend/libpq/pqcomm.c 13 Mar 2010 04:39:19 -
***
*** 1418,1427
int
pq_setkeepalivesinterval(int interval, Port *port)
{
if (port == NULL || IS_AF_UNIX(port-laddr.addr.ss_family))
return STATUS_OK;
- #ifdef TCP_KEEPINTVL
if (interval == port-keepalives_interval)
return STATUS_OK;
--- 1418,1427
int
pq_setkeepalivesinterval(int interval, Port *port)
{
+ #ifdef TCP_KEEPINTVL
if (port == NULL || IS_AF_UNIX(port-laddr.addr.ss_family))
return STATUS_OK;
if (interval == port-keepalives_interval)
return STATUS_OK;
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
