Re: [HACKERS] Re: [Pljava-dev] Should creating a new base type require superuser status?
Tom Lane wrote: Thomas Hallgren <[EMAIL PROTECTED]> writes: Tom, could you please elaborate where you see a security hole? The problem that we've seen in the past shows up when the user lies in the CREATE TYPE command, specifying type representation properties that are different from what the underlying functions expect. In particular, if it's possible to pass a pass-by-value integer to a function that's expecting a pass-by-reference datum, you can misuse the function to access backend memory. This is a non-issue in PL/Java. An integer parameter is never passed by reference and there's no way the PL/Java user can get direct access to backend memory. I gather from looking at the example that Kris referenced that there's some interface code in between the SQL function call and the user's Java code, and that that interface code is itself looking at the declared properties of the SQL type to decide what to do. So to the extent that that code is (a) bulletproof against inconsistencies and (b) not subvertible by the PL/Java user, it might be that there's no hole in practice. But assumption (b) seems pretty fragile to me. I think that assumption is without ground. Java doesn't permit you to access memory unless you use Java classes (java.nio stuff) that is explicitly designed to do that and you need native code to set such things up. A PL/Java user can not do that unless he is able to link in other shared objects or dll's to the backend process. Based on that, I claim that your statement about a "security hole a mile wide" is incorrect. PL/Java is not subject to issues relating to misuse of backend memory. Regards, Thomas Hallgren -- 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] WITH RECUSIVE patches 0723
Andrew Gierth <[EMAIL PROTECTED]> writes: > One more oversight: the patch isn't updating the ECPG preproc.y other > than trivially, so WITH queries aren't working in ecpg: > test.pgc:111: ERROR: syntax error at or near "recursive" By and large we don't expect core patches to worry about fixing the ecpg grammar. Right now the situation is that Michael Meskes makes a manual cleanup pass every so often :-(. I would like to see that get automated sooner rather than later, but in the near term it is not the responsibility of core-patch authors to update ecpg. 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] Re: [Pljava-dev] Should creating a new base type require superuser status?
> "Tom" == Tom Lane <[EMAIL PROTECTED]> writes: >> Tom, could you please elaborate where you see a security hole? Tom> The problem that we've seen in the past shows up when the user Tom> lies in the CREATE TYPE command, specifying type representation Tom> properties that are different from what the underlying functions Tom> expect. In particular, if it's possible to pass a pass-by-value Tom> integer to a function that's expecting a pass-by-reference Tom> datum, you can misuse the function to access backend memory. It strikes me that type output functions are routinely invoked by superusers (e.g. during pg_dump), and therefore if a non-superuser can create a type, that seems to imply that there's no way for a superuser to safely examine or dump the content of the database without risking the execution of untrusted code, correct? -- Andrew (irc:RhodiumToad) -- 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] WITH RECUSIVE patches 0723
> "Tatsuo" == Tatsuo Ishii <[EMAIL PROTECTED]> writes: >> At David's request I've been looking through this patch. >> >> Regarding documentation: if it would help, I can write some; I >> have already made a start on writing down what is going on >> internally in order to understand it myself. Tatsuo> Thanks. There was some docs written in Japanese by Tatsuo> Yoshiyuki. Recently he updagted it. I will translate into Tatsuo> English and post here. (Still waiting on this) One more oversight: the patch isn't updating the ECPG preproc.y other than trivially, so WITH queries aren't working in ecpg: test.pgc:111: ERROR: syntax error at or near "recursive" -- Andrew (irc:RhodiumToad) -- 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: [Pljava-dev] Should creating a new base type require superuser status?
Thomas Hallgren <[EMAIL PROTECTED]> writes: > Tom, could you please elaborate where you see a security hole? The problem that we've seen in the past shows up when the user lies in the CREATE TYPE command, specifying type representation properties that are different from what the underlying functions expect. In particular, if it's possible to pass a pass-by-value integer to a function that's expecting a pass-by-reference datum, you can misuse the function to access backend memory. I gather from looking at the example that Kris referenced that there's some interface code in between the SQL function call and the user's Java code, and that that interface code is itself looking at the declared properties of the SQL type to decide what to do. So to the extent that that code is (a) bulletproof against inconsistencies and (b) not subvertible by the PL/Java user, it might be that there's no hole in practice. But assumption (b) seems pretty fragile to 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
[HACKERS] Re: [Pljava-dev] Should creating a new base type require superuser status?
It seems perfectly safe to me too for the reason that Kris mentions. Tom, could you please elaborate where you see a security hole? Regards, Thomas Hallgren Tom Lane wrote: Kris Jurka <[EMAIL PROTECTED]> writes: On Wed, 30 Jul 2008, Alvaro Herrera wrote: I do agree that creating base types should require a superuser though. It too seems dangerous just on principle, even if today there's no actual hole (that we already know of). pl/java already allows non-superusers to create functions returning cstring and base types built off of these functions. So in other words, if pl/java is installed we have a security hole a mile wide. regards, tom lane ___ Pljava-dev mailing list [EMAIL PROTECTED] http://pgfoundry.org/mailman/listinfo/pljava-dev -- 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] Review: DTrace probes (merged version) ver_03
Alvaro Herrera wrote:
Greg Smith wrote:
One tiny change I'd suggest here: if you look at the code for checkpoint
buffer writing there are traces for two points in the process:
CheckPointBuffers(int flags)
{
+ TRACE_POSTGRESQL_BUFFER_CHECKPOINT_START(flags);
CheckpointStats.ckpt_write_t = GetCurrentTimestamp();
BufferSync(flags);
CheckpointStats.ckpt_sync_t = GetCurrentTimestamp();
smgrsync();
CheckpointStats.ckpt_sync_end_t = GetCurrentTimestamp();
+ TRACE_POSTGRESQL_BUFFER_CHECKPOINT_DONE();
}
Note how the existing code also tracks how long the sync phase took
compared to the write one, and reports both numbers in the checkpoint
logs. It would be nice to add another probe at that same point (just
after ckpt_sync_t is set) so that dtrace users could instrument all these
possibilities as well: just buffer write time/resources, just sync ones,
or both.
Sounds like the thing to do would be to pass CheckpointStats into the
DONE probe.
I like this approach as it avoids the need to have too many probes. I
will make this change and get it in with the remaining probes for the
next commit fest.
--
Robert Lor Sun Microsystems
Austin, USA http://sun.com/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] SSL configure patch: review
Tom Lane wrote:
> BTW, doesn't this patch leak memory at freePGconn() time?
Doh -- right, fixed.
> I also think that more of it should be inside #ifdef USE_SSL --- ie,
> the options should be treated like requiressl not sslmode, and not
> exist in a non-SSL build.
I wondered about that too, and couldn't make up my mind about it.
This patch does things that way.
Something that's bothering me is that PGSSLKEY is inconsistent with the
sslkey conninfo parameter. PGSSLKEY specifies an engine (basically a
driver for specialized hardware AFAICT) from which the key is to be
loaded, but sslkey is a simple filename. This means that there's no way
to load a key from hardware if you want to specify it per connection.
Not that I have any such hardware, but it looks bogus.
Obviously one still wants to be able to specify a different file name
from the default; I tried to see if there's any way to load an engine
that would load the key from a file, but could not extract any sense
from the man page:
http://www.openssl.org/docs/crypto/engine.html
Maybe this means that we should provide separate parameters, say
"sslkey" and "sslkeyfile", and a new env var PGSSLKEYFILE.
Thoughts? Am I overengineering this stuff?
--
Alvaro Herrerahttp://www.CommandPrompt.com/
PostgreSQL Replication, Consulting, Custom Development, 24x7 support
Index: doc/src/sgml/libpq.sgml
===
RCS file: /home/alvherre/Code/cvs/pgsql/doc/src/sgml/libpq.sgml,v
retrieving revision 1.260
diff -c -p -r1.260 libpq.sgml
*** doc/src/sgml/libpq.sgml 27 Jun 2008 02:44:31 - 1.260
--- doc/src/sgml/libpq.sgml 1 Aug 2008 20:29:04 -
***
*** 281,286
--- 281,330
+ sslcert
+
+
+This parameter specifies the file name of the client SSL
+certificate. This option is only available if
+PostgreSQL is compiled with SSL support.
+
+
+
+
+
+ sslkey
+
+
+This parameter specifies the file name of the client SSL key.
+This option is only available if PostgreSQL is
+compiled with SSL support.
+
+
+
+
+
+ sslrootcert
+
+
+This parameter specifies the file name of the root SSL certificate.
+This option is only available if PostgreSQL is
+compiled with SSL support.
+
+
+
+
+
+ sslcrl
+
+
+This parameter specifies the file name of the SSL certificate
+revocation list (CRL). This option is only available if
+PostgreSQL is compiled with SSL support.
+
+
+
+
+
krbsrvname
*** defaultNoticeProcessor(void *arg, const
*** 4911,4916
--- 4955,4982
+PGROOTCERT
+
+ PGROOTCERT specifies the file name where the SSL
+ root certificate is stored. This can be overridden by the
+ sslrootcert connection parameter.
+
+
+
+
+
+
+PGSSLCRL
+
+ PGSSLCRL specifies the file name where the SSL certificate
+ revocation list is stored. This can be overridden by the
+ sslcrl connection parameter.
+
+
+
+
+
+
PGKRBSRVNAME
PGKRBSRVNAME sets the Kerberos service name to use
Index: src/interfaces/libpq/fe-connect.c
===
RCS file: /home/alvherre/Code/cvs/pgsql/src/interfaces/libpq/fe-connect.c,v
retrieving revision 1.359
diff -c -p -r1.359 fe-connect.c
*** src/interfaces/libpq/fe-connect.c 29 May 2008 22:02:44 - 1.359
--- src/interfaces/libpq/fe-connect.c 1 Aug 2008 20:13:49 -
*** static const PQconninfoOption PQconninfo
*** 181,186
--- 181,201
{"sslmode", "PGSSLMODE", DefaultSSLMode, NULL,
"SSL-Mode", "", 8}, /* sizeof("disable") == 8 */
+ /* These parameters are only present in an SSL-enabled build. */
+ #ifdef USE_SSL
+ {"sslcert", "PGSSLCERT", NULL, NULL,
+ "SSL-Client-Cert", "", 64},
+
+ {"sslkey", "PGSSLKEY", NULL, NULL,
+ "SSL-Client-Key", "", 64},
+
+ {"sslrootcert", "PGROOTCERT", NULL, NULL,
+ "SSL-Root-Certificate", "", 64},
+
+ {"sslcrl", "PGSSLCRL", NULL, NULL,
+ "SSL-Revocation-List", "", 64},
+ #endif
+
#if defined(KRB5) || defined(ENABLE_GSS) || defined(ENABLE_SSPI)
/* Kerberos and GSSAPI authentication support specifying the service name */
{"krbsrvname", "PGKRBSRVNAME", PG_KRB_SRVNAM, NULL,
*** connectOptions1(PGconn *conn, const char
*** 414,419
--- 429,442
tmp = conninfo_getval(connOptions, "sslmode");
conn->sslmode = tmp ? strdup(tmp) : NULL;
Re: [HACKERS] Review: DTrace probes (merged version) ver_03
Greg Smith wrote:
> One tiny change I'd suggest here: if you look at the code for checkpoint
> buffer writing there are traces for two points in the process:
>
> CheckPointBuffers(int flags)
> {
> + TRACE_POSTGRESQL_BUFFER_CHECKPOINT_START(flags);
> CheckpointStats.ckpt_write_t = GetCurrentTimestamp();
> BufferSync(flags);
> CheckpointStats.ckpt_sync_t = GetCurrentTimestamp();
> smgrsync();
> CheckpointStats.ckpt_sync_end_t = GetCurrentTimestamp();
> + TRACE_POSTGRESQL_BUFFER_CHECKPOINT_DONE();
> }
>
> Note how the existing code also tracks how long the sync phase took
> compared to the write one, and reports both numbers in the checkpoint
> logs. It would be nice to add another probe at that same point (just
> after ckpt_sync_t is set) so that dtrace users could instrument all these
> possibilities as well: just buffer write time/resources, just sync ones,
> or both.
Sounds like the thing to do would be to pass CheckpointStats into the
DONE probe.
--
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] SSL configure patch: review
Tom Lane wrote: > Alvaro Herrera <[EMAIL PROTECTED]> writes: > > I've hacked up a couple of SGML paragraphs to serve as documentation. > > The patch is attached. I'll revise it (and make sure it compiles > > properly) and see about committing it later today. > > Weren't there a couple of other points in ams' review that we were > waiting to hear from Mark about? Yes; I based mine on ams', which already had them corrected AFAICT. I, too, am unhappy about Mark's unresponsiveness anyway. -- 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] SSL configure patch: review
BTW, doesn't this patch leak memory at freePGconn() time? I also think that more of it should be inside #ifdef USE_SSL --- ie, the options should be treated like requiressl not sslmode, and not exist in a non-SSL build. 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] SSL configure patch: review
Alvaro Herrera <[EMAIL PROTECTED]> writes: > I've hacked up a couple of SGML paragraphs to serve as documentation. > The patch is attached. I'll revise it (and make sure it compiles > properly) and see about committing it later today. Weren't there a couple of other points in ams' review that we were waiting to hear from Mark about? 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] Review: DTrace probes (merged version) ver_03
One tiny change I'd suggest here: if you look at the code for checkpoint
buffer writing there are traces for two points in the process:
CheckPointBuffers(int flags)
{
+ TRACE_POSTGRESQL_BUFFER_CHECKPOINT_START(flags);
CheckpointStats.ckpt_write_t = GetCurrentTimestamp();
BufferSync(flags);
CheckpointStats.ckpt_sync_t = GetCurrentTimestamp();
smgrsync();
CheckpointStats.ckpt_sync_end_t = GetCurrentTimestamp();
+ TRACE_POSTGRESQL_BUFFER_CHECKPOINT_DONE();
}
Note how the existing code also tracks how long the sync phase took
compared to the write one, and reports both numbers in the checkpoint
logs. It would be nice to add another probe at that same point (just
after ckpt_sync_t is set) so that dtrace users could instrument all these
possibilities as well: just buffer write time/resources, just sync ones,
or both.
--
* Greg Smith [EMAIL PROTECTED] http://www.gregsmith.com Baltimore, MD
--
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] SSL configure patch: review
Abhijit Menon-Sen wrote:
> At 2008-07-08 08:27:29 +0530, [EMAIL PROTECTED] wrote:
> >
> > (The patch is whitespace-damaged and the one fe-secure.c hunk doesn't
> > apply cleanly to the latest source, but I'm ignoring both problems for
> > the moment.)
>
> It wasn't hard to fix those, so I've attached an updated patch here.
>
> > Finally, I don't know enough (i.e. anything) about Windows to evaluate
> > the changes to libpq.rc, but the file that should be patched is really
> > libpq.rc.in.
>
> (But I didn't touch libpq.rc.in. I'm not sure if it even needs to be
> changed any more.)
It doesn't look like it needs changing.
I've hacked up a couple of SGML paragraphs to serve as documentation.
The patch is attached. I'll revise it (and make sure it compiles
properly) and see about committing it later today.
--
Alvaro Herrerahttp://www.CommandPrompt.com/
The PostgreSQL Company - Command Prompt, Inc.
Index: doc/src/sgml/libpq.sgml
===
RCS file: /home/alvherre/Code/cvs/pgsql/doc/src/sgml/libpq.sgml,v
retrieving revision 1.260
diff -c -p -r1.260 libpq.sgml
*** doc/src/sgml/libpq.sgml 27 Jun 2008 02:44:31 - 1.260
--- doc/src/sgml/libpq.sgml 1 Aug 2008 18:52:07 -
***
*** 281,286
--- 281,324
+ sslcert
+
+
+This parameter specifies the file name of the client SSL
+certificate.
+
+
+
+
+
+ sslkey
+
+
+This parameter specifies the file name of the client SSL key.
+
+
+
+
+
+ sslrootcert
+
+
+This parameter specifies the file name of the root SSL certificate.
+
+
+
+
+
+ sslcrl
+
+
+This parameter specifies the file name of the SSL certificate
+revocation list (CRL)
+
+
+
+
+
krbsrvname
*** defaultNoticeProcessor(void *arg, const
*** 4911,4916
--- 4949,4976
+PGROOTCERT
+
+ PGROOTCERT specifies the file name where the SSL
+ root certificate is stored. This can be overridden by the
+ sslrootcert connection parameter.
+
+
+
+
+
+
+PGSSLCRL
+
+ PGSSLCRL specifies the file name where the SSL certificate
+ revocation list is stored. This can be overridden by the
+ sslcrl connection parameter.
+
+
+
+
+
+
PGKRBSRVNAME
PGKRBSRVNAME sets the Kerberos service name to use
Index: src/interfaces/libpq/fe-connect.c
===
RCS file: /home/alvherre/Code/cvs/pgsql/src/interfaces/libpq/fe-connect.c,v
retrieving revision 1.359
diff -c -p -r1.359 fe-connect.c
*** src/interfaces/libpq/fe-connect.c 29 May 2008 22:02:44 - 1.359
--- src/interfaces/libpq/fe-connect.c 1 Aug 2008 14:44:50 -
*** static const PQconninfoOption PQconninfo
*** 181,186
--- 181,198
{"sslmode", "PGSSLMODE", DefaultSSLMode, NULL,
"SSL-Mode", "", 8}, /* sizeof("disable") == 8 */
+ {"sslcert", "PGSSLCERT", NULL, NULL,
+ "SSL-Client-Cert", "", 64},
+
+ {"sslkey", "PGSSLKEY", NULL, NULL,
+ "SSL-Client-Key", "", 64},
+
+ {"sslrootcert", "PGROOTCERT", NULL, NULL,
+ "SSL-Root-Certificate", "", 64},
+
+ {"sslcrl", "PGSSLCRL", NULL, NULL,
+ "SSL-Revocation-List", "", 64},
+
#if defined(KRB5) || defined(ENABLE_GSS) || defined(ENABLE_SSPI)
/* Kerberos and GSSAPI authentication support specifying the service name */
{"krbsrvname", "PGKRBSRVNAME", PG_KRB_SRVNAM, NULL,
*** connectOptions1(PGconn *conn, const char
*** 413,418
--- 425,438
conn->connect_timeout = tmp ? strdup(tmp) : NULL;
tmp = conninfo_getval(connOptions, "sslmode");
conn->sslmode = tmp ? strdup(tmp) : NULL;
+ tmp = conninfo_getval(connOptions, "sslkey");
+ conn->sslkey = tmp ? strdup(tmp) : NULL;
+ tmp = conninfo_getval(connOptions, "sslcert");
+ conn->sslcert = tmp ? strdup(tmp) : NULL;
+ tmp = conninfo_getval(connOptions, "sslrootcert");
+ conn->sslrootcert = tmp ? strdup(tmp) : NULL;
+ tmp = conninfo_getval(connOptions, "sslcrl");
+ conn->sslcrl = tmp ? strdup(tmp) : NULL;
#ifdef USE_SSL
tmp = conninfo_getval(connOptions, "requiressl");
if (tmp && tmp[0] == '1')
Index: src/interfaces/libpq/fe-secure.c
===
RCS file: /home/alvherre/Code/cvs/pgsql/src/interfaces/libpq/fe-secure.c,v
retrieving revision 1.105
diff -c -p -r1.105 fe-secure.c
*** src/interfaces/libpq/fe-secure.c 16 May 2008 18:30:53 - 1.105
--- src/interfaces/libpq/fe-secure.c 1 Aug 2008 14:44:
Re: [HACKERS] Fixing the representation of ORDER BY/GROUP BY/DISTINCT
Martijn van Oosterhout <[EMAIL PROTECTED]> writes: > On Thu, Jul 31, 2008 at 08:54:49PM -0400, Tom Lane wrote: >> So while I was fooling with Steve Midgley's problem I got a bit of a bee >> in my bonnet about the way that the parser emits ORDER BY, GROUP BY, >> and DISTINCT lists. > There's an open TODO item in this area: namely that a GROUP BY referring > to a primary key is equivalent to a GROUP BY involving all the rest of > the fields. Now, I don't think anyone has proposed a way to support > that, but I wanted to check we arn't making it harder to do with these > changes... No, these changes shouldn't make any difference for that. (Offhand it seems like that might just be a simple modification in the code that checks for improper use of ungrouped fields. Not sure though.) 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] Fixing the representation of ORDER BY/GROUP BY/DISTINCT
On Thu, Jul 31, 2008 at 08:54:49PM -0400, Tom Lane wrote: > So while I was fooling with Steve Midgley's problem I got a bit of a bee > in my bonnet about the way that the parser emits ORDER BY, GROUP BY, > and DISTINCT lists. There's an open TODO item in this area: namely that a GROUP BY referring to a primary key is equivalent to a GROUP BY involving all the rest of the fields. Now, I don't think anyone has proposed a way to support that, but I wanted to check we arn't making it harder to do with these changes... Have a nice day, -- Martijn van Oosterhout <[EMAIL PROTECTED]> http://svana.org/kleptog/ > Please line up in a tree and maintain the heap invariant while > boarding. Thank you for flying nlogn airlines. signature.asc Description: Digital signature
Re: [HACKERS] Fixing the representation of ORDER BY/GROUP BY/DISTINCT
Gregory Stark <[EMAIL PROTECTED]> writes: > So ASC/DESC is represented by using > for sortop? Yes --- that's always been 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] Review: DTrace probes (merged version) ver_03
Alvaro Herrera wrote: Alvaro Herrera wrote: Applied. I forgot to mention that I renamed the sort_end probe to sort_done, to keep the naming convention. It is a backwards-incompatible change, but there were plenty other probes renamed so my guess is that one more does not matter all that much. It was overlooked :-( . Good catch! Also, it seems I cannot sort pg_trace and pgstat consistently :-( Not sure what you're trying to say here! -- Robert Lor Sun Microsystems Austin, USA http://sun.com/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] Messed up CVS status of two ECPG files
"Tom Lane" <[EMAIL PROTECTED]> writes: > Gregory Stark <[EMAIL PROTECTED]> writes: >> These two files seem to be getting updated every time I do a CVS update. > > Doesn't happen here --- maybe something odd in your local CVS state? Huh, indeed. I needed rsync --delete. I'm surprised it hasn't caused any problems before now. Sorry for the noise -- Gregory Stark EnterpriseDB http://www.enterprisedb.com Ask me about EnterpriseDB's 24x7 Postgres 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] Instructions for adding new catalog
"Gustavo Tonini" <[EMAIL PROTECTED]> writes: > I read the archives, but I can't find the instructions for adding new > catalogs to the system. That's probably because there aren't any. Look at recent patches that added a new catalog to get an idea of what you need to do. The enum patch might be a good choice. 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] Review: DTrace probes (merged version) ver_03
Alvaro Herrera wrote: Applied. Thanks! How come "Oid" works for FLUSH_START but not READ_START and READ_DONE? I'll get the answer for this. Also, I wonder if there's any proof that this works at all on Mac OS X, given that the rule to create probes.o from probes.d is conditionally pulled in only for Solaris? It does work on OS X. I dare everyone to try it :-) The implementation of DTrace on OS X is a bit different than on Solaris, so the rule your referring to is only needed for Solaris. -- Robert Lor Sun Microsystems Austin, USA http://sun.com/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] Messed up CVS status of two ECPG files
Gregory Stark <[EMAIL PROTECTED]> writes: > These two files seem to be getting updated every time I do a CVS update. Doesn't happen here --- maybe something odd in your local CVS state? > If that's true then we should just cvs delete them. We already did, according to the cvsweb view. 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] Messed up CVS status of two ECPG files
These two files seem to be getting updated every time I do a CVS update. I think what's happened is that they've become generated files and are being deleted by "make clean" but CVS thinks they're still under revision control and puts back some old version. If that's true then we should just cvs delete them. U src/interfaces/ecpg/preproc/keywords.c U src/interfaces/ecpg/test/expected/connect-test1.c -- Gregory Stark EnterpriseDB http://www.enterprisedb.com Ask me about EnterpriseDB's On-Demand Production Tuning -- 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] Search for version-numbered tclsh?
Tom Lane wrote: > Perhaps have PGAC_PATH_TCLSH do > > AC_PATH_PROGS(TCLSH, [tclsh tcl tclsh8.5 tclsh8.4 tclsh8.3]) > > or some such. Applied. -- 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
[HACKERS] Instructions for adding new catalog
Hello, I read the archives, but I can't find the instructions for adding new catalogs to the system. Where can I find those instructions? Is there a document about this? Thanks, Gustavo. P.S: Please CC to me on reply -- 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] Review: DTrace probes (merged version) ver_03
Alvaro Herrera wrote: > Applied. I forgot to mention that I renamed the sort_end probe to sort_done, to keep the naming convention. It is a backwards-incompatible change, but there were plenty other probes renamed so my guess is that one more does not matter all that much. Also, it seems I cannot sort pg_trace and pgstat consistently :-( -- 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] Review: DTrace probes (merged version) ver_03
Robert Lor wrote: > I made some changes to the sed script so it works with the sed on > Solaris & OS X. I tested this patch on both Solaris and OS X with DTrace > enabled and disabled and also verified that the sed script works with > GNU sed. I hope this is the final change for this patch. Thanks for > catching all the issues, and my bad for not testing with DTrace disabled. Applied. Something seems wrong with this argument: > + /* The following probe declarations cause compilation errors > + * on Mac OS X but not on Solaris. Need further investigation. > + * probe buffer__read__start(BlockNumber, Oid, Oid, Oid, bool); > + * probe buffer__read__done(BlockNumber, Oid, Oid, Oid, bool, bool); > + */ > + probe buffer__read__start(unsigned int, unsigned int, unsigned int, > unsigned int, bool); > + probe buffer__read__done(unsigned int, unsigned int, unsigned int, > unsigned int, bool, bool); > + > + probe buffer__flush__start(Oid, Oid, Oid); > + probe buffer__flush__done(Oid, Oid, Oid); How come "Oid" works for FLUSH_START but not READ_START and READ_DONE? Also, I wonder if there's any proof that this works at all on Mac OS X, given that the rule to create probes.o from probes.d is conditionally pulled in only for Solaris? -- 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] Fixing the representation of ORDER BY/GROUP BY/DISTINCT
"Tom Lane" <[EMAIL PROTECTED]> writes:
> typedef struct SortGroupClause
> {
> NodeTag type;
> Index tleSortGroupRef;/* reference into targetlist */
> Oid eqop; /* the equality operator ('=' op) */
> Oid sortop; /* the ordering operator ('<' op), or 0 */
> boolnulls_first;/* do NULLs come before normal values? */
> } SortGroupClause;
So ASC/DESC is represented by using > for sortop?
--
Gregory Stark
EnterpriseDB http://www.enterprisedb.com
Ask me about EnterpriseDB's On-Demand Production Tuning
--
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] Fixing the representation of ORDER BY/GROUP BY/DISTINCT
"Tom Lane" <[EMAIL PROTECTED]> writes: > This is important for making the world safe for hashed DISTINCT, since > AFAICS we probably can't ever use hashing for DISTINCT ON --- its definition > is too dependent on the assumption of sorting. I don't think that's true. We could store the sort key in the hash along with the resulting tuple and replace the resulting tuple iff the new sort key is less than the old sort key. -- Gregory Stark EnterpriseDB http://www.enterprisedb.com Ask me about EnterpriseDB's Slony Replication 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] So, what's the "base dn" in an LDAP URL again?
Tom Lane wrote: > The fine manual claims that the "base dn" part of an LDAP URL > is meaningful: > > The server will bind to the distinguished name specified as base > dn using the user name supplied by the client. If prefix and > suffix is specified, it will be prepended and appended to the > user name before the bind. > > But looking at CheckLDAPAuth() just now, it doesn't do anything at all > with the basedn part of the string. Seems to me this is either a code > bug or a docs bug. I think it's a docs bug. You don't "bind to the dn...". You bind *with* a DN, and that one is made of out of . IIRC, my original intent was for it to bind using that and then attempt to access the location specified by basedn, so one could set permissions on that object. But I never did implement that - and even if I did, the docs would still be wrong. So, the docs should be fixed - I'll take a look at that. It does mean that basedn isn't used, and could be removed. But we're obviously not going to do that in a backbranch, since it'd change the syntax. As for HEAD, I'd leave it in as well, since the changes I'm working on for pg_hba parameters will likely make the syntax change anyway - and there's no point in doing it twice. Seems fair? //Magnus -- 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] Plans for 8.4
Henry B. Hotz wrote: > > On Jul 31, 2008, at 7:58 AM, Magnus Hagander wrote: > >> Stephen Frost wrote: >>> * Henry B. Hotz ([EMAIL PROTECTED]) wrote: I'm making no promises, but what would people think of a hostgss hba option? >>> >>> As described, sounds like a win to me. It'd be very nice to be able to >>> just use GSSAPI encryption on the link. That, combined w/ Magnus' work >>> on username/princ mappings, would really bring PostgreSQL up to date wrt >>> GSSAPI support. >> >> Yeah, +1 on this feature, it would be quite useful. >> >> >>> It'd really be great to have this support in the ODBC and JDBC drivers >>> too.. I think in JDBC it might 'just work', I'm less sure about ODBC. >> >> ODBC will need hackery I think. They use libpq for authentication only, >> but have their own SSL code and such. I do think ODBC would be a fairly >> major point to it being a success, though, so it'd be good if a plan >> could be secured for it. But it's not a showstopper, of course. > > I don't know enough about ODBC. If ODBC does SSL independently of PG > then it requires thought by someone who understands ODBC. I just meant please consider coordinating with the ODBC folks to make sure it gets in there as well - and in time for the same release. >>> As a practical question- would you really need a seperate explicit >>> pg_hba option for it? It'd be nice to be able to require it, if >>> desired, but that strikes me as more sensible as an option to the 'gss' >>> auth mechanism? >> >> Yeah, if we can get rid of that, that'd be good. The stuff I'm working >> on will allow us to have multiple parameters for each row in name/value >> pairs, so if we could use that, it'd be better. (I've been considering >> changing how host/hostssl work that way as well - by having a parameter >> similar to what we have on the client side with sslmode=...) >> >> A thought that I came across - is it even possible to use GSSAPI >> encryption *without* using GSSAPI authentication? If not, it really >> seems like it should belong more in the parameter part of the field. >> Since in that case it is also not possible to enable encryption *before* >> authentication, or is it? > > You're on the right track. My problem isn't the hba file parsing at all. > > My problem is the interaction between the buffering logic and the > encrypted I/O routines. The technical issue is that to make a GSSAPI > security layer independent of SSL you need to invent a whole new > buffering layer. That's a lot of work, and it only buys you the ability > to do both SSL and GSSAPI at the same time. That doesn't seem worth it. Yeah, there seems to be no general point in that. However, implementing a layer there might have other benefits. Such as being able to use other SSL implementations (right now we only do OpenSSL. There has been talk about GnuTLS, and it would be good to be able to do schannel) > The code being affected is what's currently configured in column 1 of > hba. The ability to use the new capability requires that SSL *NOT* be > configured in column 1 for the relevant client addresses. In short, no, > it doesn't make sense to make it an option to the gss authentication > method, even though it requires it. If we make it an option to the gss > authentication method it would still need to act like it was specified > in column 1, which would be confusing. Does this hold even if we move the "hostssl" stuff into a parameter "at the end"? I was thinking maybe something like: host all all 0.0.0.0/0 md5 ssl=require host all all 0.0.0.0/0 gss ssl=forbid gssencrypt=require (you get the idea) > GSSAPI security layers are negotiated after the authentication (or at > least after the start of authentication). There are GSSAPI status flags > that indicate if the security layer is available yet. The GSSAPI > security layer code would check those flags and gss_wrap() or not > accordingly. (-: There's a flush() or two from my original patch that > will need to be added back in, otherwise we'll encrypt a message that > tells the other end how to decrypt messages. Not a big deal. ;-) Ok, makes sense. //Magnus -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] NDirectFileRead and Write
Hello, I'd like to use NDirectFileRead and NDirectFileWrite statistics counters for counting reads and writes in BufFile. They are defined, but not used now. BufFile is used for tuple sorting or materializing, so we could use NDirectFileRead/Write to retrieve how many I/Os are done in temp tablespace. We can get the values of NDirectFileRead/Write when we enable log_statement_stats, log_parser_stats, log_planner_stats or log_executor_stats. (They show always 0 for NDirectFile R/W now.) I have a plan to store the values shown by log_xxx_stats into pg_stat_statements, that is per-query statistics information collector I'm developing. The combination of NDirectFile R/W and pg_stat_statements have an advantage to detect which sql uses large tuple sorting. And after we find such queries, we can turn trace_sort on and examine how amount of work_mem is needed by such queries. We could save time for tuning queries and reading server logs. -- The patch would be very trivial ;-) Index: src/backend/storage/file/buffile.c === --- src/backend/storage/file/buffile.c (HEAD) +++ src/backend/storage/file/buffile.c (working copy) @@ -238,6 +238,7 @@ file->nbytes = 0; file->offsets[file->curFile] += file->nbytes; /* we choose not to advance curOffset here */ + NDirectFileRead++; } /* @@ -300,6 +301,7 @@ file->offsets[file->curFile] += bytestowrite; file->curOffset += bytestowrite; wpos += bytestowrite; + NDirectFileWrite++; } file->dirty = false; Regards, --- ITAGAKI Takahiro 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
