Re: [PATCHES] [HACKERS] Krb5 multiple DB connections
Greetings,
The attached patch fixes a bug which was originally brought up in May
of 2002 in this thread:
http://archives.postgresql.org/pgsql-interfaces/2002-05/msg00083.php
The original bug reporter also supplied a patch to fix the problem:
http://archives.postgresql.org/pgsql-interfaces/2002-05/msg00090.php
I ran into exactly the same issue using 8.1.2. I've updated the
original patch to work for HEAD and 8.1.2. I've tested the patch on
both HEAD and 8.1.2, both at home and at work, and it works quite
nicely. In fact, I hope to have a patch to phppgadmin which will make
it properly handle Kerberized logins.
Thanks,
Stephen
Index: src/interfaces/libpq/fe-auth.c
===
RCS file: /projects/cvsroot/pgsql/src/interfaces/libpq/fe-auth.c,v
retrieving revision 1.110
diff -c -r1.110 fe-auth.c
*** src/interfaces/libpq/fe-auth.c 26 Dec 2005 14:58:05 - 1.110
--- src/interfaces/libpq/fe-auth.c 5 Feb 2006 20:03:21 -
***
*** 101,122
* Various krb5 state which is not connection specific, and a flag to
* indicate whether we have initialised it yet.
*/
static intpg_krb5_initialised;
static krb5_context pg_krb5_context;
static krb5_ccache pg_krb5_ccache;
static krb5_principal pg_krb5_client;
static char *pg_krb5_name;
static int
! pg_krb5_init(char *PQerrormsg)
{
krb5_error_code retval;
! if (pg_krb5_initialised)
return STATUS_OK;
! retval = krb5_init_context(pg_krb5_context);
if (retval)
{
snprintf(PQerrormsg, PQERRORMSG_LENGTH,
--- 101,133
* Various krb5 state which is not connection specific, and a flag to
* indicate whether we have initialised it yet.
*/
+ /*
static intpg_krb5_initialised;
static krb5_context pg_krb5_context;
static krb5_ccache pg_krb5_ccache;
static krb5_principal pg_krb5_client;
static char *pg_krb5_name;
+ */
+
+ struct krb5_info
+ {
+ int pg_krb5_initialised;
+ krb5_contextpg_krb5_context;
+ krb5_ccache pg_krb5_ccache;
+ krb5_principal pg_krb5_client;
+ char*pg_krb5_name;
+ };
static int
! pg_krb5_init(char *PQerrormsg, struct krb5_info *info)
{
krb5_error_code retval;
! if (info-pg_krb5_initialised)
return STATUS_OK;
! retval = krb5_init_context((info-pg_krb5_context));
if (retval)
{
snprintf(PQerrormsg, PQERRORMSG_LENGTH,
***
*** 125,170
return STATUS_ERROR;
}
! retval = krb5_cc_default(pg_krb5_context, pg_krb5_ccache);
if (retval)
{
snprintf(PQerrormsg, PQERRORMSG_LENGTH,
pg_krb5_init: krb5_cc_default: %s\n,
error_message(retval));
! krb5_free_context(pg_krb5_context);
return STATUS_ERROR;
}
! retval = krb5_cc_get_principal(pg_krb5_context, pg_krb5_ccache,
!
pg_krb5_client);
if (retval)
{
snprintf(PQerrormsg, PQERRORMSG_LENGTH,
pg_krb5_init: krb5_cc_get_principal: %s\n,
error_message(retval));
! krb5_cc_close(pg_krb5_context, pg_krb5_ccache);
! krb5_free_context(pg_krb5_context);
return STATUS_ERROR;
}
! retval = krb5_unparse_name(pg_krb5_context, pg_krb5_client,
pg_krb5_name);
if (retval)
{
snprintf(PQerrormsg, PQERRORMSG_LENGTH,
pg_krb5_init: krb5_unparse_name: %s\n,
error_message(retval));
! krb5_free_principal(pg_krb5_context, pg_krb5_client);
! krb5_cc_close(pg_krb5_context, pg_krb5_ccache);
! krb5_free_context(pg_krb5_context);
return STATUS_ERROR;
}
! pg_krb5_name = pg_an_to_ln(pg_krb5_name);
! pg_krb5_initialised = 1;
return STATUS_OK;
}
/*
* pg_krb5_authname -- returns a pointer to static space containing whatever
--- 136,191
return STATUS_ERROR;
}
! retval = krb5_cc_default(info-pg_krb5_context,
(info-pg_krb5_ccache));
if (retval)
{
snprintf(PQerrormsg, PQERRORMSG_LENGTH,
pg_krb5_init: krb5_cc_default: %s\n,
error_message(retval));
! krb5_free_context(info-pg_krb5_context);
return STATUS_ERROR;
}
! retval = krb5_cc_get_principal(info-pg_krb5_context,
info-pg_krb5_ccache,
!
(info-pg_krb5_client));
Re: [PATCHES] [INTERFACES] [BUGS] BUG #2171: Differences compiling plpgsql in ecpg and psql
On Wed, Feb 01, 2006 at 11:48:45PM -0500, Bruce Momjian wrote: I have researched your report, and you are right, there are two ecpg bugs here. First, dollar quoting uses single-quotes internally to do the quoting, but it does not double any single-quotes in the dollar-quoted string. Actually ecpg should not translate dollar quoting at all. I'm going to fix this. Dollar quotes will then be send to the backend with translation and the backend takes care of the rest. Second, when a dollar quoted string or single-quoted string spans multiple lines, ecpg does not escape the newline that is part of the string. Some compilers will accept an unescaped newline in a string, while others will not: Not sure, but there appears to be a bug in the routine that outputs a statement. I will change that one as well and would ask you to just check again. It seems to me that this also fixes your problem. I tried with the one test case in this email and it seems to work. But then I'm currently travelling and do not have that much spare time to test. Michael -- Michael Meskes Email: Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org) ICQ: 179140304, AIM/Yahoo: michaelmeskes, Jabber: [EMAIL PROTECTED] Go SF 49ers! Go Rhein Fire! Use Debian GNU/Linux! Use PostgreSQL! ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
[PATCHES] plpython tracebacks
I have been working with plpython for several months and have
been hampered by the lack of a traceback being logged when a
plpython function raises an error. I have written a patch causes
the PLy_traceback function to fully log the traceback. The
output looks just like the traceback output provided by the
python interpreter.
Feedback appreciated.
Scott
--- plpython-1.70.c.orig2006-02-06 14:24:42.0 -0600
+++ plpython-1.70.c.patched 2006-02-06 15:34:05.0 -0600
@@ -2499,7 +2499,8 @@
*vob = NULL;
char *vstr,
*estr,
- *xstr = NULL;
+ *xstr = NULL,
+ *tbstr;
/*
* get the current exception
@@ -2523,6 +2524,82 @@
else
vstr = Unknown;
+ /* If there is a traceback object, we build a string containing
+ the traceback information. */
+ if (tb != NULL)
+ {
+ PyObject
+ *cur_tb, /* traceback (tb) item being handled */
+ *old_tb, /* holds tb so we can decrement reference to
it */
+ *hdr, /* First line of logged output */
+ *tmpl,/* PyString template for the logged tb item */
+ *ftr, /* Last line of logged output */
+ *tb_list, /* Each tb item create a PyString in this
list */
+ *ln, /* The line number of the item in the
traceback */
+ *frame, /* the tb_frame */
+ *code,/* the f_code this guy has filename and
method name*/
+ *fn, /* the filename of the item in the tb */
+ *nm, /* the function/method name of the item in
the tb */
+ *args,/* A tuple of the form (fn, ln, nm) */
+ *logline, /* The assembled string with the logged
message */
+ *os, /* points to the os module */
+ *sep, /* line separator */
+ *tb_log; /* PyString with the assembled log msg */
+
+ hdr = PyString_FromString(Traceback (most recent call last):);
+ tmpl = PyString_FromString( File \%s\, line %s, in %s);
+ ftr = PyString_FromString();
+
+ tb_list = PyList_New(0); /* create the list of strings */
+ PyList_Append(tb_list, hdr); /* Append the header to the list */
+
+ /* 1st tb is useless; throw it away */
+ cur_tb = PyObject_GetAttrString(tb, tb_next);
+ while (cur_tb != Py_None)
+ {
+
+ ln = PyObject_GetAttrString(cur_tb, tb_lineno);
+ frame = PyObject_GetAttrString(cur_tb, tb_frame);
+ code = PyObject_GetAttrString(frame, f_code);
+ fn = PyObject_GetAttrString(code, co_filename);
+ nm = PyObject_GetAttrString(code, co_name);
+
+ args = Py_BuildValue((OOO), fn, ln, nm); /* args
tuple */
+ logline = PyString_Format(tmpl, args); /* build logged
string */
+ PyList_Append(tb_list, logline); /* append string
to list */
+
+ /* decrement references on all our objects */
+ Py_DECREF(logline);
+ Py_DECREF(args);
+ Py_XDECREF(nm);
+ Py_XDECREF(fn);
+ Py_XDECREF(code);
+ Py_XDECREF(frame);
+ Py_XDECREF(ln);
+
+ old_tb = cur_tb;
+ /* get the next traceback item */
+ cur_tb = PyObject_GetAttrString(cur_tb, tb_next);
+ Py_DECREF(old_tb);/* we're done with old_tb so
decref it */
+ }
+ PyList_Append(tb_list, ftr); /* append the log msg footer */
+
+ os = PyImport_ImportModule(os);
+ sep = PyObject_GetAttrString(os, linesep); /* get os EOL char
*/
+ tb_log = _PyString_Join(sep, tb_list); /* create tb log
msgs */
+ tbstr = PyString_AsString(tb_log);
+
+ Py_DECREF(tb_log);
+ Py_DECREF(sep);
+ Py_DECREF(os);
+ Py_DECREF(tb_list);
+ Py_DECREF(ftr);
+ Py_DECREF(tmpl);
+ Py_DECREF(hdr);
+ }
+ else
+ tbstr = No Traceback;
+
/*
* I'm not sure what to do if eob is NULL here -- we can't call PLy_elog
* because that function calls us, so we could end up with infinite
@@ -2530,7 +2607,7 @@
* Assert() be more appropriate?
*/
estr = eob ? PyString_AsString(eob) :
Re: [PATCHES] pgbench: Support Multiple Simultaneous Runs (with Mean and Std. Dev.)
Tom, I noticed in this thread: http://archives.postgresql.org/pgsql-performance/2005-12/msg00206.php you state: Try something like -s 10 -c 10 -t 3000 to get numbers reflecting test conditions more like what the TPC council had in mind when they designed this benchmark. I tend to repeat such a test 3 times to see if the numbers are repeatable, and quote the middle TPS number as long as they're not too far apart. The -x I added is to make your 3 times easier. Sure, it's just sugar, but if this is part of the recommended use of the tool, or even a personal case study from the core team, I figured it might be of use to others. Anyway, just a followup since I was going through the archives and found a mild argument in favor it from you. :) -- Thomas F. O'Connell Database Architecture and Programming Co-Founder Sitening, LLC http://www.sitening.com/ 3004 B Poston Avenue Nashville, TN 37203-1314 615-260-0005 (cell) 615-469-5150 (office) 615-469-5151 (fax) ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [PATCHES] [INTERFACES] [BUGS] BUG #2171: Differences compiling plpgsql in
Michael Meskes wrote: On Wed, Feb 01, 2006 at 11:48:45PM -0500, Bruce Momjian wrote: I have researched your report, and you are right, there are two ecpg bugs here. First, dollar quoting uses single-quotes internally to do the quoting, but it does not double any single-quotes in the dollar-quoted string. Actually ecpg should not translate dollar quoting at all. I'm going to fix this. Dollar quotes will then be send to the backend with translation and the backend takes care of the rest. Well, CVS version before I modified it had dolq stuff in the lexer to handle dollar quotes and pass it as SCONST to the parser. Second, when a dollar quoted string or single-quoted string spans multiple lines, ecpg does not escape the newline that is part of the string. Some compilers will accept an unescaped newline in a string, while others will not: Not sure, but there appears to be a bug in the routine that outputs a statement. I will change that one as well and would ask you to just check again. It seems to me that this also fixes your problem. I tried with the one test case in this email and it seems to work. But then I'm currently travelling and do not have that much spare time to test. The problem is that output.c does: printf(abc def); While some compilers are OK with that, others are not. I changed it to output: printf(abc\n\ def); -- Bruce Momjian| http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [PATCHES] drop if exists remainder
Here's a first draft patch for DROP ... IF EXISTS for the remaining cases, namely: LANGUAGE, TABLESPACE, TRIGGER OPERATOR CLASS, FUNCTION, AGGREGATE, OPERATOR, CAST and RULE. At what point does this stop being useful and become mere bloat? The only case I can ever recall being actually asked for was the TABLE case ... Chris KL said it should be done for all on the grounds of consistency. But I will happily stop right now if that's not the general view - I'm only doing this to complete something I started. Well, my use-case was to be able to wrap pg_dump -c output in begin/commit tags and being able to run and re-run such dumps without errors. Basically I don't like 'acceptable errors' when restoring dumps :) They just confuse newer users especially. I also just like consistency :) Chris ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [PATCHES] drop if exists remainder
Christopher Kings-Lynne wrote: Here's a first draft patch for DROP ... IF EXISTS for the remaining cases, namely: LANGUAGE, TABLESPACE, TRIGGER OPERATOR CLASS, FUNCTION, AGGREGATE, OPERATOR, CAST and RULE. At what point does this stop being useful and become mere bloat? The only case I can ever recall being actually asked for was the TABLE case ... Chris KL said it should be done for all on the grounds of consistency. But I will happily stop right now if that's not the general view - I'm only doing this to complete something I started. Well, my use-case was to be able to wrap pg_dump -c output in begin/commit tags and being able to run and re-run such dumps without errors. Basically I don't like 'acceptable errors' when restoring dumps :) They just confuse newer users especially. I also just like consistency :) Makes sense. -- Bruce Momjian| http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
[PATCHES] Patch to readme
Attached is a patch to the README file to bring it a little more up to date with current PostgreSQL. 12,14c12,23 The JDBC, ODBC, C++, Python, and Tcl interfaces have been moved to the PostgreSQL Projects Web Site at http://gborg.postgresql.org for separate maintenance. A Perl DBI/DBD driver is available from CPAN. --- PostgreSQL has many language interfaces including some of the more common listed below: JDBC - http://jdbc.postgresql.org ODBC - http://odbc.postgresql.org C++ - http://thaiopensource.org/development/libpqxx/ Perl - http://www.cpan.org Python - http://www.initd.org/ Ruby - http://ruby.scripting.ca/postgres/ Other language binding are available from a variety of contributing parties. 27c36 ftp://ftp.postgresql.org/pub/. For more information look at our web --- http://www.postgresql.org/download/. For more information look at our web ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [PATCHES] Patch to readme
Is there a reason you didn't list the pl/PHP one? Seems appropriate for that list no? On Mon, 6 Feb 2006, Joshua D. Drake wrote: Attached is a patch to the README file to bring it a little more up to date with current PostgreSQL. Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email: [EMAIL PROTECTED] Yahoo!: yscrappy ICQ: 7615664 ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [PATCHES] Patch to readme
Marc G. Fournier wrote: Is there a reason you didn't list the pl/PHP one? Seems appropriate for that list no? I was only listing client side interfaces... I could adapt to include the PL interfaces. Joshua D. Drake On Mon, 6 Feb 2006, Joshua D. Drake wrote: Attached is a patch to the README file to bring it a little more up to date with current PostgreSQL. Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email: [EMAIL PROTECTED] Yahoo!: yscrappy ICQ: 7615664 ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [PATCHES] Patch to readme
Marc G. Fournier wrote: Is there a reason you didn't list the pl/PHP one? Seems appropriate for that list no? On Mon, 6 Feb 2006, Joshua D. Drake wrote: adapted. Attached is a patch to the README file to bring it a little more up to date with current PostgreSQL. Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email: [EMAIL PROTECTED] Yahoo!: yscrappy ICQ: 7615664 ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match 12,14c12,35 The JDBC, ODBC, C++, Python, and Tcl interfaces have been moved to the PostgreSQL Projects Web Site at http://gborg.postgresql.org for separate maintenance. A Perl DBI/DBD driver is available from CPAN. --- PostgreSQL has many language interfaces including some of the more common listed below: C++ - http://thaiopensource.org/development/libpqxx/ JDBC - http://jdbc.postgresql.org ODBC - http://odbc.postgresql.org Perl - http://www.cpan.org PHP - http://www.php.net Python - http://www.initd.org/ Ruby - http://ruby.scripting.ca/postgres/ Other language binding are available from a variety of contributing parties. PostgreSQL also has a great number of procedural languages available, a short but not complete list is below: pl/c - Included in PostgreSQL core plPgsql - Included in PostgreSQL core - Similar to Oracle PL/sql plPerl - Included in PostgreSQL core plPHP - http://projects.commandprompt.com/projects/public/plphp plPython - Included in PostgreSQL core plJava - http://gborg.postgresql.org/project/pljava/projdisplay.php plTcl - Included in PostgreSQL core 27c48 ftp://ftp.postgresql.org/pub/. For more information look at our web --- http://www.postgresql.org/download/. For more information look at our web ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
