Re: [HACKERS] pltcl broken on tcl8.5 ?
Devrim GÜNDÜZ wrote: Hi, On Sun, 2008-06-15 at 20:54 -0400, Andrew Dunstan wrote: Has anyone been able to get the tests to pass using Tcl 8.5.1? All regression tests passed on Fedora-9 while building new RPM sets. Do you specifically run the PL regression tests? 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] TODO Item: Allow pg_hba.conf to specify host names along with IP addresses
On Sun, Jun 15, 2008 at 11:53:57PM +0200, Peter Eisentraut wrote: Isn't that what a local DNS caching-only server would accomplish? Only if you looked up the DNS name at auth time :) A -- Andrew Sullivan [EMAIL PROTECTED] +1 503 667 4564 x104 http://www.commandprompt.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] TODO Item: Allow pg_hba.conf to specify host names along with IP addresses
On Sun, Jun 15, 2008 at 11:56:35PM +0200, Peter Eisentraut wrote: It would probably be a good idea to check how other programs deal with hostname lookups during authentication. Programs like SSH, Apache, and Squid come to mind. There is actually a great deal of controversy about most of this hostname-based authentication, particularly in the absence of DNSSEC. If anyone implementing this is interested in the controversy, I have a huge mail archive of it (because I'm the current editor of the IETF working group document on this, and therefore have received much hate mail on the topic). I think it's all summarised in the draft[1] I mentioned upthread. Since that's possibly about to go to IETF last call, it'd be a good time for someone planning to implement something to look at that document, and report on whether it provides any useful guidance at all. I'd be keenly interested in hearing the verdict. A [1] http://tools.ietf.org/wg/dnsop/draft-ietf-dnsop-reverse-mapping-considerations/ -- Andrew Sullivan [EMAIL PROTECTED] +1 503 667 4564 x104 http://www.commandprompt.com/ -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] Permission of prepared statements (was: pg_stat_statements)
Tom Lane [EMAIL PROTECTED] wrote: We don't have any system-wide names for statements, so this seems pretty ill-defined and of questionable value. Showing the text of statements in a view also has security problems. I found we can execute prepared statements and view the sql source through pg_prepared_statements even after we execute SET SESSION AUTHORIZATION. Is this an expected behavior? It is not a problem in normal use because the *real* user is same before and after changing ROLEs, but we should be careful about sharing connections between different users in connection pooling. Almost connection poolings don't do that, though. 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
Re: [HACKERS] TODO Item: Allow pg_hba.conf to specify host names along with IP addresses
Am Montag, 16. Juni 2008 schrieb Andrew Sullivan: Since that's possibly about to go to IETF last call, it'd be a good time for someone planning to implement something to look at that document, and report on whether it provides any useful guidance at all. I'd be keenly interested in hearing the verdict. Well, this mainly says that a system that relies on DNS and reverse DNS should not be the default and only security mechanism. I think we can work with that. I'm not sure this actually tells us anything new, but at least it's written down in one place now. -- 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] TODO Item: Allow pg_hba.conf to specify host names along with IP addresses
Am Donnerstag, 12. Juni 2008 schrieb Dickson S. Guedes: There is a TODO Item to allow pg_hba.conf to specify host names along with IP addresses. I'm a bit curious how useful in practice this would actually be. Obviously, you want to use host names to simplify the management of hosts, currently being done with IP addresses. But how widely useful is it really to authenticate a bunch of hosts in different ways? I'd say the standard case is localhost vs everything else. Or perhaps localhost vs LAN vs rest of the Internet. In neither of these cases , using host names helps much. We have people here concerned about security of DNS, rightly so. But what about relying on IP addresses or, by extension, MAC addresses for security; is that safe? So what are the use cases for having more than about 4 or 5 lines in pg_hba.conf, and how would the ability to use host names help there? -- 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] Question about Encoding a Custom Type
On Sun, Jun 15, 2008 at 10:07:43PM -0700, David E. Wheeler wrote: Howdy, Possibly showing my ignorance here, but as I'm working on updating citext to be locale-aware and to work on 8.3, I've run into this peculiarity: The only odd thing I see is the use of PG_ARGS to pass the arguments to citextcmp. But I can't see why it would break either. Can you attach a debugger and see where it goes wrong? As to the comment about freeing stuff, it's usually nice if btree comparison functions free memory because that way index rebuilds on large tables don't run you out of memory. 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
[HACKERS] Crash in pgCrypto?
Could someone using the pgcrypto extension please verify this? SELECT encode(digest(null, 'md5'::text), 'hex'); or SELECT digest(null, 'md5'); Takes a few seconds, and then crashes the server with a Signal 11. My system is PostgreSQL 8.2.7. Seems to be an unchecked access to memory location 0. Best regards, Mario Weilguni -- 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] Crash in pgCrypto?
On 6/16/08, Mario Weilguni [EMAIL PROTECTED] wrote: Could someone using the pgcrypto extension please verify this? SELECT encode(digest(null, 'md5'::text), 'hex'); or SELECT digest(null, 'md5'); Takes a few seconds, and then crashes the server with a Signal 11. My system is PostgreSQL 8.2.7. Seems to be an unchecked access to memory location 0. Seems you loaded pgcrypto function signatures from dump (from 8.0). http://marc.info/?l=postgresql-generalm=118794006505296w=2 Recreate the functions with pgcrypto.sql. -- marko -- 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] Crash in pgCrypto?
Marko Kreen schrieb: On 6/16/08, Mario Weilguni [EMAIL PROTECTED] wrote: Could someone using the pgcrypto extension please verify this? SELECT encode(digest(null, 'md5'::text), 'hex'); or SELECT digest(null, 'md5'); Takes a few seconds, and then crashes the server with a Signal 11. My system is PostgreSQL 8.2.7. Seems to be an unchecked access to memory location 0. Seems you loaded pgcrypto function signatures from dump (from 8.0). http://marc.info/?l=postgresql-generalm=118794006505296w=2 Recreate the functions with pgcrypto.sql. Yes, this is what I did, and it happened during update from 8.0 -- 8.2. But that brings me to another problem, what is the best way to create backups with pgdump so that stuff from contrib is not dumped, but recreated from the newer version? Thanks! -- 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] Crash in pgCrypto?
On 6/16/08, Mario Weilguni [EMAIL PROTECTED] wrote: Marko Kreen schrieb: On 6/16/08, Mario Weilguni [EMAIL PROTECTED] wrote: Could someone using the pgcrypto extension please verify this? SELECT encode(digest(null, 'md5'::text), 'hex'); or SELECT digest(null, 'md5'); Takes a few seconds, and then crashes the server with a Signal 11. My system is PostgreSQL 8.2.7. Seems to be an unchecked access to memory location 0. Seems you loaded pgcrypto function signatures from dump (from 8.0). http://marc.info/?l=postgresql-generalm=118794006505296w=2 Recreate the functions with pgcrypto.sql. Yes, this is what I did, and it happened during update from 8.0 -- 8.2. But that brings me to another problem, what is the best way to create backups with pgdump so that stuff from contrib is not dumped, but recreated from the newer version? Good question... Seems the proper support for modules will not leave todo-list any time soon. Only way that works now is to add any module .sql to template0, so they would not be dumped out. So you are forced to recreate them properly on newer version. (By adding them to template0 again.) -- marko -- 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] Crash in pgCrypto?
Marko Kreen schrieb: On 6/16/08, Mario Weilguni [EMAIL PROTECTED] wrote: Marko Kreen schrieb: On 6/16/08, Mario Weilguni [EMAIL PROTECTED] wrote: Could someone using the pgcrypto extension please verify this? SELECT encode(digest(null, 'md5'::text), 'hex'); or SELECT digest(null, 'md5'); Takes a few seconds, and then crashes the server with a Signal 11. My system is PostgreSQL 8.2.7. Seems to be an unchecked access to memory location 0. Seems you loaded pgcrypto function signatures from dump (from 8.0). http://marc.info/?l=postgresql-generalm=118794006505296w=2 Recreate the functions with pgcrypto.sql. Yes, this is what I did, and it happened during update from 8.0 -- 8.2. But that brings me to another problem, what is the best way to create backups with pgdump so that stuff from contrib is not dumped, but recreated from the newer version? Good question... Seems the proper support for modules will not leave todo-list any time soon. Only way that works now is to add any module .sql to template0, so they would not be dumped out. So you are forced to recreate them properly on newer version. (By adding them to template0 again.) Is this todo-list something I can find online? Best regards Mario Weilguni -- 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] Crash in pgCrypto?
Marko Kreen wrote: Good question... Seems the proper support for modules will not leave todo-list any time soon. Only way that works now is to add any module .sql to template0, so they would not be dumped out. So you are forced to recreate them properly on newer version. (By adding them to template0 again.) Module install/uninstall is being worked on. In fact this case shows that it's something we really need, rather than just something that would be nice to have, IMNSHO. 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] Crash in pgCrypto?
Am Montag, 16. Juni 2008 schrieb Mario Weilguni: Is this todo-list something I can find online? Yes, google for postgresql+todo+list. -- 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] Crash in pgCrypto?
On 6/16/08, Mario Weilguni [EMAIL PROTECTED] wrote: Is this todo-list something I can find online? postgresql.org - Developers - TODO list: http://www.postgresql.org/docs/faqs.TODO.html -- marko -- 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] Crash in pgCrypto?
Andrew Dunstan schrieb: Marko Kreen wrote: Good question... Seems the proper support for modules will not leave todo-list any time soon. Only way that works now is to add any module .sql to template0, so they would not be dumped out. So you are forced to recreate them properly on newer version. (By adding them to template0 again.) Module install/uninstall is being worked on. In fact this case shows that it's something we really need, rather than just something that would be nice to have, IMNSHO. cheers andrew Yes, this is really a pitfall when doing security related updates. Best regards, Mario Weilguni -- 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] Crash in pgCrypto?
Mario Weilguni wrote: Could someone using the pgcrypto extension please verify this? SELECT encode(digest(null, 'md5'::text), 'hex'); or SELECT digest(null, 'md5'); Takes a few seconds, and then crashes the server with a Signal 11. My system is PostgreSQL 8.2.7. Seems to be an unchecked access to memory location 0. I think the functions were made STRICT recently, and the NULL checks were removed, but people with the old definitions of the functions could see the crashes. Try removing pgcrypto and recompiling it from a fresh release. -- 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] Question about Encoding a Custom Type
On Jun 16, 2008, at 02:52, Martijn van Oosterhout wrote: The only odd thing I see is the use of PG_ARGS to pass the arguments to citextcmp. But I can't see why it would break either. Can you attach a debugger and see where it goes wrong? Yes, I can do that, although I'm pretty new to C (let alone gdb), so I'm not sure exactly how to go about it. I'll try to get on IRC later today to see if anyone can help me along. As to the comment about freeing stuff, it's usually nice if btree comparison functions free memory because that way index rebuilds on large tables don't run you out of memory. Thanks. I'll add that to my list. Best, David -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] pg_stat_statements
On Sunday 15 June 2008 22:31:59 ITAGAKI Takahiro wrote:
Robert Treat [EMAIL PROTECTED] wrote:
On Friday 13 June 2008 12:58:22 Josh Berkus wrote:
I can see how this would be useful, but I can also see that it could be
a huge performance burden when activated. So it couldn't be part of
the standard statistics collection.
A lower overhead way to get at this type of information is to quantize
dtrace results over a specific period of time. Much nicer than doing the
whole logging/analyze piece.
DTrace is disabled in most installation as default, and cannot be used in
some platforms (especially I want to use the feature in Linux). I think
DTrace is known as a tool for developers, but not for DBAs. However,
statement logging is required by DBAs who used to use STATSPACK in Oracle.
For some reason it has gotten that reputation in this community, but that
really is not the case. As Sun describes it, dtrace provides a powerful
infrastructure to permit administrators, developers, and service personnel to
concisely answer arbitrary questions about the behavior of the operating
system and user programs. Given that PostgreSQL relies on the operating
system for a majority of it's instermentation (ie. we have nothing like v$
tables in oracle), we should really be thinking of dtrace as the ultimate
tool for DBA's to figure out what is going on in thier systems.
--
Robert Treat
Build A Brighter LAMP :: Linux Apache {middleware} 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] pg_stat_statements
On Mon, Jun 16, 2008 at 10:34 AM, Robert Treat [EMAIL PROTECTED] wrote: Given that PostgreSQL relies on the operating system for a majority of it's instermentation (ie. we have nothing like v$ tables in oracle), we should really be thinking of dtrace as the ultimate tool for DBA's to figure out what is going on in thier systems. Over a year ago, we added an Oracle wait-event-like interface (counters and timers) to the core of Advanced Server which not only provides everything DTrace currently does, but is also cross-platform and is 300 lines of code in the core. While DTrace has a little less overhead due to its use of a user-mode high-resolution timer, neither benchmarks or customers have found our implementation to cause any performance degradation when timing is enabled. It wouldn't be too hard to write the probes in such a way as they could be used by DTrace or by a loadable timing/counter implementation for platforms which don't support DTrace. -- Jonah H. Harris, Sr. Software Architect | phone: 732.331.1324 EnterpriseDB Corporation | fax: 732.331.1301 499 Thornall Street, 2nd Floor | [EMAIL PROTECTED] Edison, NJ 08837 | http://www.enterprisedb.com/ -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] TODO Item: Allow pg_hba.conf to specify host names along with IP addresses
On Mon, Jun 16, 2008 at 11:47:21AM +0200, Peter Eisentraut wrote: I'm a bit curious how useful in practice this would actually be. Obviously, you want to use host names to simplify the management of hosts, currently being done with IP addresses. But how widely useful is it really to authenticate a bunch of hosts in different ways? I'd say the standard case is localhost vs everything else. Or perhaps localhost vs LAN vs rest of the Internet. In neither of these cases , using host names helps much. The obvious case for it (which is why I'm not arguing against using it as such) is network renumbering. If you renumber a network, right now you have to update these files. Today this isn't a big deal, but as IPv4 addresses get scarcer and IPv6 addresses come online, this is going to become a problem people have more often. In large deployments with a lot of postmasters and many people's hands involved, one fewer change to manage would be a boon. Moreover, in managed networks, you don't always control when your IPs will change or how. Doing this by hostname could have advantages for reliability, at the possible cost of startup performance. One reason to use DNS names rather than static /etc/host entries or IP addresses is this resilience in the face of a changing network infrastructure. We have people here concerned about security of DNS, rightly so. But what about relying on IP addresses or, by extension, MAC addresses for security; is that safe? Well, there's one fewer thing that can be subverted. But authenticating from a host address is pretty weak authentication. I'd think the Morris worm teaches us that. Without DNSSEC, subverting the DNS is very close to trivial. But, in the presence of competent DNSSEC deployment, subverting the DNS becomes just shy of impossible, so this might become a strategy approximately as strong as authentication by host address. You're still trusting a connection on the basis of who it claims to be and where it's coming from; that's hardly strong authentication. I agree with Andrew Dunstan that for any real world wide-scale uses, you want to use some sort of strong authentication. A -- Andrew Sullivan [EMAIL PROTECTED] +1 503 667 4564 x104 http://www.commandprompt.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] Core team statement on replication in PostgreSQL
On Mon, Jun 9, 2008 at 9:48 PM, in message [EMAIL PROTECTED], Greg Smith [EMAIL PROTECTED] wrote: On Mon, 9 Jun 2008, Tom Lane wrote: It should also be pointed out that the whole thing becomes uninteresting if we get real-time log shipping implemented. So I see absolutely no point in spending time integrating pg_clearxlogtail now. There are remote replication scenarios over a WAN (mainly aimed at disaster recovery) that want to keep a fairly updated database without putting too much traffic over the link. People in that category really want zeroed tail+compressed archives, but probably not the extra overhead that comes with shipping smaller packets in a real-time implementation. We ship the WAL files over a (relatively) slow WAN for disaster recovery purposes, and we would be fine with replacing our current techniques with real-time log shipping as long as: (1) We can do it asynchronously. (i.e., we don't have to wait for WAN latency to commit transactions.) (2) It can ship to multiple targets. (Management dictates that we have backups at the site of origin as well as our central site. A failure to replicate to one must not delay the other.) (3) It doesn't consume substantially more WAN bandwidth overall. A solution which fails to cover any of these leaves pg_clearxlogtail interesting to us. -Kevin -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Question about Encoding a Custom Type
On Jun 16, 2008, at 09:24, David E. Wheeler wrote: On Jun 16, 2008, at 02:52, Martijn van Oosterhout wrote: The only odd thing I see is the use of PG_ARGS to pass the arguments to citextcmp. But I can't see why it would break either. Can you attach a debugger and see where it goes wrong? Yes, I can do that, although I'm pretty new to C (let alone gdb), so I'm not sure exactly how to go about it. I'll try to get on IRC later today to see if anyone can help me along. What's even weirder is that it can not work and then suddenly work: try=# select citext_smaller( 'aardvark'::citext, 'AARDVARK'::citext ); ERROR: invalid byte sequence for encoding UTF8: 0xe02483 HINT: This error can also happen if the byte sequence does not match the encoding expected by the server, which is controlled by client_encoding. try=# select citext_smaller( 'aardvark'::citext, 'AARDVARK'::citext ); citext_smaller AARDVARK (1 row) WTF? Logging onto IRC now… https://svn.kineticode.com/citext/trunk/ Best, David -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Question about Encoding a Custom Type
David E. Wheeler [EMAIL PROTECTED] writes: What's even weirder is that it can not work and then suddenly work: Smells like uninitialized-memory problems to me. Perhaps you are miscalculating the length of the input data? Are you testing in an --enable-cassert build? The memory clobber stuff can help to make it more obvious where such problems lurk. 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] Question about Encoding a Custom Type
On Jun 16, 2008, at 13:06, Tom Lane wrote:
David E. Wheeler [EMAIL PROTECTED] writes:
What's even weirder is that it can not work and then suddenly work:
Smells like uninitialized-memory problems to me. Perhaps you are
miscalculating the length of the input data?
Entirely possible. Here are the two functions in which I calculate size:
char * cilower(text * arg) {
// Do I need to free anything here?
char * str = VARDATA_ANY( arg );
#ifdef USE_WIDE_UPPER_LOWER
// Have wstring_lower() do the work.
return wstring_lower( str );
# else
// Copy the string and process it.
intinex, len;
char * result;
index = 0;
len= VARSIZE(arg) - VARHDRSZ;
result = (char *) palloc( strlen( str ) + 1 );
for (index = 0; index = len; index++) {
result[index] = tolower((unsigned char) str[index] );
}
return result;
#endif /* USE_WIDE_UPPER_LOWER */
}
int citextcmp (PG_FUNCTION_ARGS) {
// Could we do away with the varlena struct here?
text * left = PG_GETARG_TEXT_P(0);
text * right = PG_GETARG_TEXT_P(1);
char * lstr = cilower( left );
char * rstr = cilower( right );
intllen = VARSIZE_ANY_EXHDR(left);
intrlen = VARSIZE_ANY_EXHDR(right);
return varstr_cmp(lstr, llen, rstr, rlen);
}
Are you testing in an --enable-cassert build? The memory clobber
stuff can help to make it more obvious where such problems lurk.
I've just recompiled with --enable-cassert and --enable-debug, but got
no more information when I triggered the error, neither in psql nor in
the log. :-(
Thanks,
David
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] How to Sponsor a Feature
On Sunday 15 June 2008 23:01:16 Joshua D. Drake wrote:
Andrew Dunstan wrote:
Plus an ability to filter the list on those criteria. I'd also like to
see a space for companies to state which PostgreSQL major contributors
are working for them. That should be of some assistance to sponsors in
picking a development company to deal with.
+1
Under CMD's listing I see the following:
They are one of the most prolific of community supporters with over 50% of
their staff recognized PostgreSQL community members.
ISTM somewhere between the description and the experience pieces, you have
plenty of ways to list your contributors. Also, don't forget we allow
contributors to list companies next to thier names if they so desire.
--
Robert Treat
Build A Brighter LAMP :: Linux Apache {middleware} 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] Question about Encoding a Custom Type
On Mon, Jun 16, 2008 at 01:29:33PM -0500, David E. Wheeler wrote:
Smells like uninitialized-memory problems to me. Perhaps you are
miscalculating the length of the input data?
Entirely possible. Here are the two functions in which I calculate size:
Actually, real dumb question but: arn't you assume that text* values
are NULL terminated, because they're not...
char * cilower(text * arg) {
// Do I need to free anything here?
char * str = VARDATA_ANY( arg );
str here is not null terminated. You need text_to_cstring or something
similar.
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] Crash in pgCrypto?
On Monday 16 June 2008 09:54:16 Alvaro Herrera wrote:
Mario Weilguni wrote:
Could someone using the pgcrypto extension please verify this?
SELECT encode(digest(null, 'md5'::text), 'hex');
or
SELECT digest(null, 'md5');
Takes a few seconds, and then crashes the server with a Signal 11. My
system is PostgreSQL 8.2.7. Seems to be an unchecked access to memory
location 0.
I think the functions were made STRICT recently, and the NULL checks
were removed, but people with the old definitions of the functions could
see the crashes. Try removing pgcrypto and recompiling it from a fresh
release.
broken record
I still advocate to folks to try to put contrib modules into thier own schemas
whenever possible, so that you have the option of doing pg_dump -N
contribmodule, makes things like this much easier to work around. (And yes,
I've volunteered to patch the contribs with this if we ever decide to make it
the default setup)
/broken record
--
Robert Treat
Build A Brighter LAMP :: Linux Apache {middleware} 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] pg_stat_statements
Jonah, It wouldn't be too hard to write the probes in such a way as they could be used by DTrace or by a loadable timing/counter implementation for platforms which don't support DTrace. I was under the impression that's the way our feature, the Generic Monitoring Interface was written. It's a macro. If someone can deliver another trace framework, you can plug it right in. -- --Josh Josh Berkus PostgreSQL @ Sun San Francisco -- 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] Question about Encoding a Custom Type
On Jun 16, 2008, at 13:41, Martijn van Oosterhout wrote:
Actually, real dumb question but: arn't you assume that text* values
are NULL terminated, because they're not...
char * cilower(text * arg) {
// Do I need to free anything here?
char * str = VARDATA_ANY( arg );
str here is not null terminated. You need text_to_cstring or something
similar.
Ah! That makes sense. I changed it to this:
#define GET_TEXT_STR(textp) DatumGetCString( \
DirectFunctionCall1( textout, PointerGetDatum( textp ) ) \
)
char * cilower(text * arg) {
// Do I need to free anything here?
char * str = GET_TEXT_STR( arg );
...
And now I don't get that error anymore. W00t! Many thanks.
Now I have just one more bizarre error: PostgreSQL thinks that a
citext column is not in an aggregate even when it is:
try=# CREATE AGGREGATE array_accum (anyelement) (
try(# sfunc = array_append,
try(# stype = anyarray,
try(# initcond = '{}'
try(# );
try=# CREATE TEMP TABLE srt ( name CITEXT );
try=#
try=# INSERT INTO srt (name)
try-# VALUES ('aardvark'),
try-#('AAA'),
try-#('â');
try=# select array_accum(name) from srt order by name;
ERROR: column srt.name must appear in the GROUP BY clause or be
used in an aggregate function
Um, what? Again, I'm sure I'm just missing something really stupid.
What might cause this?
Many thanks all,
David
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] Reducing overhead for repeat de-TOASTing
Recent discussions with the PostGIS hackers led me to think about ways to reduce overhead when the same TOAST value is repeatedly detoasted. In the example shown here http://archives.postgresql.org/pgsql-hackers/2008-06/msg00384.php 90% of the runtime is being consumed by repeated detoastings of a single datum. That is certainly an outlier case, but we've heard complaints of TOAST being slow before. The solution I'm about to propose should fix this, and as a bonus it will reduce the problem of memory leakage when a detoasted value doesn't get pfreed. What I am imagining is that the tuple toaster will maintain a cache of recently-detoasted values, and that pg_detoast_datum() returns a pointer to a cache entry rather than a freshly palloc'd value. The cache lookup key is the toast table OID plus value OID. Now pg_detoast_datum() has no idea where the pointer it returns will go, so the big problem with this scheme is that it's hard to tell how long a cache entry needs to live. But we can resolve that by ruling that the required lifetime is the same as the value would have had if it'd really been palloc'd --- IOW, until the memory context that was current at the time gets deleted or reset. This can be implemented by allowing the toaster cache to hook into the memory context delete/reset calls. (We have no such capability now, but there have been some previous cases where it would've come in handy, so I think this would be a useful extension anyhow. It should be an actual hook that can be used by anyone, not something where mcxt.c is specifically passing control to tuptoaster.) Once a cache entry is no longer required anywhere, it can be removed, and will be if needed to shrink the cache to some target size (work_mem perhaps, or is it worth inventing a separate GUC for this?). But we can hang onto the value longer if it's not taking up needed space. This is important since the use pattern exhibited in the PostGIS problem involves repeat detoastings that are separated by MemoryContextResets --- if we free the cache entry as soon as possible, we'll not gain anything. The other cache management problem that would have to be solved is to invalidate entries when the underlying TOAST table or individual TOAST value is deleted. This is exactly like the problem for tuples in the syscaches, and can be solved via sinval messaging. (The reason we need to worry about this is to guard against the possibility that the same identifier is re-used for a new TOAST value; otherwise we could just let dead values age out of the cache.) A change of this sort has the potential to break a lot of code, but I think the only thing we'd really have to do is turn PG_FREE_IF_COPY() into a no-op. In general, functions are not supposed to scribble on pass-by-reference input datums, and since most functions don't actually distinguish whether their inputs got detoasted (except perhaps by using PG_FREE_IF_COPY()), that means that they won't be scribbling on the toast cache entry either. It would be possible to extend this concept to caching toast slice fetches (pg_detoast_datum_slice() calls) if we add the offset/length arguments to the cache lookup key. I'm not certain if that's worth the trouble though --- any feelings about that? Also, that case is much more likely to have callers that think they can scribble on the result, since they know it must be a palloc'd value. One unsolved problem is that this scheme doesn't provide any way to cache the result of decompressing an inline-compressed datum, because those have no unique ID that could be used for a lookup key. This puts a bit of a damper on the idea of making PG_FREE_IF_COPY() a no-op --- if it is, then detoasting a datum of that type would indeed cause a memory leak. The best idea I have at the moment is to continue to have inline decompression produce a palloc'd value, leave PG_FREE_IF_COPY() as-is, and arrange for pfree() on toast cache entries to be a no-op. (Which we can do by setting up a special memory context methods pointer for them.) It'd be cool if there were a way to cache decompression though. Ideas? Comments, better ideas? Anyone think this is too much trouble to take for the problem? 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] Question about Encoding a Custom Type
David E. Wheeler [EMAIL PROTECTED] writes: Now I have just one more bizarre error: PostgreSQL thinks that a citext column is not in an aggregate even when it is: try=# select array_accum(name) from srt order by name; ERROR: column srt.name must appear in the GROUP BY clause or be used in an aggregate function Um, what? It's complaining about the use in ORDER BY. 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] pltcl broken on tcl8.5 ?
Andrew Dunstan wrote: Devrim GÜNDÜZ wrote: Hi, On Sun, 2008-06-15 at 20:54 -0400, Andrew Dunstan wrote: Has anyone been able to get the tests to pass using Tcl 8.5.1? All regression tests passed on Fedora-9 while building new RPM sets. Do you specifically run the PL regression tests? As confirmed by discussion on IRC, the RPM build process only runs make check which doesn't run the PL regression tests. 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] Question about Encoding a Custom Type
On Jun 16, 2008, at 14:38, Tom Lane wrote: It's complaining about the use in ORDER BY. Okay, so stupid question: How can I get an array of the values in a given order? I guess this works: select array_accum(b) from ( select name from srt order by name ) AS A(b); Thanks, David -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] pltcl broken on tcl8.5 ?
Andrew Dunstan [EMAIL PROTECTED] writes: Buildfarm bobcat is broken running the pltcl regression tests - see http://www.pgbuildfarm.org/cgi-bin/show_log.pl?nm=bobcatdt=2008-06-15%2022:43:01 and I have reproduced this on Fedora 9 myself. This distro has Tcl 8.5.1. Hoo, nasty. Tcl_GetVar() is resetting interp-result. Not sure why we didn't see this before ... maybe it didn't use to? Anyway, the order of execution in ereport(ERROR, (errmsg(%s, interp-result), errcontext(%s\nin PL/Tcl function \%s\, UTF_U2E(Tcl_GetVar(interp, errorInfo, TCL_GLOBAL_ONLY)), prodesc-user_proname))); is machine-dependent, which explains why I didn't see it on HPPA. 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] pltcl broken on tcl8.5 ?
Tom Lane wrote: Andrew Dunstan [EMAIL PROTECTED] writes: Buildfarm bobcat is broken running the pltcl regression tests - see http://www.pgbuildfarm.org/cgi-bin/show_log.pl?nm=bobcatdt=2008-06-15%2022:43:01 and I have reproduced this on Fedora 9 myself. This distro has Tcl 8.5.1. Hoo, nasty. Tcl_GetVar() is resetting interp-result. Not sure why we didn't see this before ... maybe it didn't use to? Anyway, the order of execution in ereport(ERROR, (errmsg(%s, interp-result), errcontext(%s\nin PL/Tcl function \%s\, UTF_U2E(Tcl_GetVar(interp, errorInfo, TCL_GLOBAL_ONLY)), prodesc-user_proname))); is machine-dependent, which explains why I didn't see it on HPPA. According to the manual page that's only supposed to happen if the TCL_LEAVE_ERR_MSG flag is used: TCL_LEAVE_ERR_MSG If an error is returned and this bit is set in flags, then an error message will be left in the interpreter’s result, where it can be retrieved with Tcl_GetObjResult or Tcl_GetStringResult. If this flag bit isn’t set then no error message is left and the interpreter’s result will not be modified. So this looks like a bug. I guess we could work around it by saving out interp-result first. As you say, nasty. 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] Crash in pgCrypto?
On Mon, Jun 16, 2008 at 02:48:42PM -0400, Robert Treat wrote: On Monday 16 June 2008 09:54:16 Alvaro Herrera wrote: Mario Weilguni wrote: Could someone using the pgcrypto extension please verify this? SELECT encode(digest(null, 'md5'::text), 'hex'); or SELECT digest(null, 'md5'); Takes a few seconds, and then crashes the server with a Signal 11. My system is PostgreSQL 8.2.7. Seems to be an unchecked access to memory location 0. I think the functions were made STRICT recently, and the NULL checks were removed, but people with the old definitions of the functions could see the crashes. Try removing pgcrypto and recompiling it from a fresh release. broken record I still advocate to folks to try to put contrib modules into thier own schemas whenever possible, so that you have the option of doing pg_dump -N contribmodule, makes things like this much easier to work around. (And yes, I've volunteered to patch the contribs with this if we ever decide to make it the default setup) /broken record I, too, would be happy to do the legwork on this one. I believe we'd want to have both per-db and per-role settings for search_path. What's involved with creating that latter? Cheers, David. -- David Fetter [EMAIL PROTECTED] http://fetter.org/ Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter Skype: davidfetter XMPP: [EMAIL PROTECTED] 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] Question about Encoding a Custom Type
On Mon, Jun 16, 2008 at 02:45:57PM -0500, David Wheeler wrote: On Jun 16, 2008, at 14:38, Tom Lane wrote: It's complaining about the use in ORDER BY. Okay, so stupid question: How can I get an array of the values in a given order? I guess this works: select array_accum(b) from ( select name from srt order by name ) AS A(b); SELECT ARRAY(SELECT name FROM srt ORDER BY name); -- also works. Cheers, David. -- David Fetter [EMAIL PROTECTED] http://fetter.org/ Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter Skype: davidfetter XMPP: [EMAIL PROTECTED] 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] Crash in pgCrypto?
David Fetter wrote: I, too, would be happy to do the legwork on this one. I believe we'd want to have both per-db and per-role settings for search_path. What's involved with creating that latter? I'm not sure what's your point here, but you can already use ALTER ROLE foo SET search_path=... -- 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] Crash in pgCrypto?
David Fetter wrote: On Mon, Jun 16, 2008 at 02:48:42PM -0400, Robert Treat wrote: On Monday 16 June 2008 09:54:16 Alvaro Herrera wrote: Mario Weilguni wrote: Could someone using the pgcrypto extension please verify this? SELECT encode(digest(null, 'md5'::text), 'hex'); or SELECT digest(null, 'md5'); Takes a few seconds, and then crashes the server with a Signal 11. My system is PostgreSQL 8.2.7. Seems to be an unchecked access to memory location 0. I think the functions were made STRICT recently, and the NULL checks were removed, but people with the old definitions of the functions could see the crashes. Try removing pgcrypto and recompiling it from a fresh release. broken record I still advocate to folks to try to put contrib modules into thier own schemas whenever possible, so that you have the option of doing pg_dump -N contribmodule, makes things like this much easier to work around. (And yes, I've volunteered to patch the contribs with this if we ever decide to make it the default setup) /broken record I, too, would be happy to do the legwork on this one. I believe we'd want to have both per-db and per-role settings for search_path. What's involved with creating that latter? Proper support for module install / uninstall will be a far better solution. Why would you wast your time on something that will be at best half-baked? 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] pltcl broken on tcl8.5 ?
Andrew Dunstan [EMAIL PROTECTED] writes: Tom Lane wrote: Hoo, nasty. Tcl_GetVar() is resetting interp-result. According to the manual page that's only supposed to happen if the TCL_LEAVE_ERR_MSG flag is used: TCL_LEAVE_ERR_MSG If an error is returned and this bit is set in flags, then an error message will be left in the interpreters result, where it can be retrieved with Tcl_GetObjResult or Tcl_GetStringResult. If this flag bit isnt set then no error message is left and the interpreters result will not be modified. But notice that they specify using Tcl_GetObjResult or Tcl_GetStringResult, rather than touching the field directly. I suspect they'd regard this as not-a-bug. In any case I found the responsible code: Tcl_SaveInterpState/Tcl_RestoreInterpState restore the result as an object not a string. I see no such routines in 8.4. As I look at this, I think it's got even more problems: it's assuming that interp-result is in the database encoding, which seems a pretty faulty assumption considering it came from Tcl. pltcl_elog converts to the database encoding before calling Tcl_SetResult, which makes that path all right as long as Tcl doesn't do anything with the string before exiting, but I don't particularly trust that assumption either. All in all this is really quite broken. 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] TODO Item: Allow pg_hba.conf to specify host names along with IP addresses
* Andrew Sullivan ([EMAIL PROTECTED]) wrote: On Mon, Jun 16, 2008 at 11:47:21AM +0200, Peter Eisentraut wrote: I'm a bit curious how useful in practice this would actually be. Obviously, you want to use host names to simplify the management of hosts, currently being done with IP addresses. But how widely useful is it really to authenticate a bunch of hosts in different ways? I'd say the standard case is localhost vs everything else. Or perhaps localhost vs LAN vs rest of the Internet. In neither of these cases , using host names helps much. There's an important use case that you've not listed- differentiating authentication types by hosts. For example, I have some systems which are inside of my Kerberos realm and you should be using kerberos/gssapi to auth to the databases from there, but I don't control everything and so have to make exceptions for systems which need to connect but can't use Kerberos for one reason or another. The same also ends up being true of applications (most notably Java-based ones, though that should get better with GSSAPI support getting into JDBC and my moving to 8.3) where users can't auth with kerberos/gssapi. That tends to be most easily managed on a per-host basis as well. Additionally, we have systems with sensetive data on them where we like to layer the security, and one of those is to say users with admin rights can connect from these hosts, while other users can only connect from their systems. All of these systems are behind NAT'ing devices or are using RFC 1918 addressing as an isolated network so it's not clear to me that using host names will help me in the IPv4 world. We're working with IPv6 though and are bringing up services on it and I expect we will have to go through a renumbering before we run anything production on IPv6, so being able to use host names at that point would be nice. Not as the only authentication mechanism, but as an additional layer that an intruder would have to deal with. We have DNSSEC running also, and IPSEC, which lends security to the DNS service such that forging DNS would be at least non-trivial. All that said, we could drive it off some config option, I suppose. I'm not sure if that will satisfy those concerned about depending on anything DNS, but it would limit the performance conerns, I'd think. Thanks, Stephen signature.asc Description: Digital signature
Re: [HACKERS] Crash in pgCrypto?
On Mon, Jun 16, 2008 at 06:00:33PM -0400, Andrew Dunstan wrote: I, too, would be happy to do the legwork on this one. I believe we'd want to have both per-db and per-role settings for search_path. What's involved with creating that latter? Proper support for module install / uninstall will be a far better solution. Why would you wast your time on something that will be at best half-baked? Maybe I'm missing something big, but I don't quite see what constitutes proper that doesn't involve the module's having at least one schema to itself. Does this mean we'd be freezing modules in their first-deployed form? It seems to me that DROP SCHEMA ... CASCADE is just the right level of modularity combined with flexibility post-installation. The way I've structured DBI-Link, for example, involves one schema for DBI-Link itself, modifiable by the DB superuser, and ancillary schemas for each link. Come to think of it, it would be nice if it were possible to tell pg_depend about such relationships between schemas, so that when somebody drops a schema with CASCADE, all schemas marked as depending on it also disappear... As to why you'd want per-role, per-DB search_paths, right now, you can set them only per-role, which results in an annoying number of path not found warnings should a user switch to a DB in the cluster which doesn't contain all the schemas in its default search_path. Another way would be for people to be able to set flame-proof_suitsome kind(s) of configurable action(s) on CONNECT/. Cheers, David. -- David Fetter [EMAIL PROTECTED] http://fetter.org/ Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter Skype: davidfetter XMPP: [EMAIL PROTECTED] 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] Reducing overhead for repeat de-TOASTing
* Tom Lane ([EMAIL PROTECTED]) wrote: One unsolved problem is that this scheme doesn't provide any way to cache the result of decompressing an inline-compressed datum, because those have no unique ID that could be used for a lookup key. That's pretty unfortunate. Ideas? Not at the moment, but given the situation it really does strike me as something we want to solve. Inventing an ID would likely be overkill or wouldn't solve the problem anyway, I'm guessing... Comments, better ideas? Anyone think this is too much trouble to take for the problem? I definitely think it's worth it, even if it doesn't handle an inline-compressed datum. PostGIS is certainly a good use case for why, but I doubt it's the only one. Thanks! Stephen signature.asc Description: Digital signature
Re: [HACKERS] Crash in pgCrypto?
David Fetter wrote: On Mon, Jun 16, 2008 at 06:00:33PM -0400, Andrew Dunstan wrote: I, too, would be happy to do the legwork on this one. I believe we'd want to have both per-db and per-role settings for search_path. What's involved with creating that latter? Proper support for module install / uninstall will be a far better solution. Why would you wast your time on something that will be at best half-baked? Maybe I'm missing something big, but I don't quite see what constitutes proper that doesn't involve the module's having at least one schema to itself. Does this mean we'd be freezing modules in their first-deployed form? It seems to me that DROP SCHEMA ... CASCADE is just the right level of modularity combined with flexibility post-installation. ISTM that uninstall foomodule will be a whole lot nicer. If we record all the objects that the module contains, then we would just drop them. The module could involve one schema, or several schemas, or none. Maybe that's the something big. 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] Crash in pgCrypto?
Andrew Dunstan [EMAIL PROTECTED] writes: David Fetter wrote: Maybe I'm missing something big, but I don't quite see what constitutes proper that doesn't involve the module's having at least one schema to itself. ISTM that uninstall foomodule will be a whole lot nicer. Right. We have all the mechanism we need in the form of the dependency stuff: you just make everything in the module auto-depend on the module object. People who want to put their modules into private schemas can do it, but they won't be forced to. In any case, trying to define a module as a schema doesn't help at all to solve the hard problem, which is how to get this stuff to play nice with pg_dump. I think that the agreed-on solution was that pg_dump should emit some kind of LOAD MODULE foo command, and *not* dump any of the individual objects in the module. We can't have that if we try to equate modules with schemas instead of making them a new kind of object. 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] Reducing overhead for repeat de-TOASTing
Stephen Frost [EMAIL PROTECTED] writes: * Tom Lane ([EMAIL PROTECTED]) wrote: Comments, better ideas? Anyone think this is too much trouble to take for the problem? I definitely think it's worth it, even if it doesn't handle an inline-compressed datum. Yeah. I'm not certain how much benefit we could get there anyway. If the datum isn't out-of-line then there's a small upper limit on how big it can be and hence a small upper limit on how long it takes to decompress. It's not clear that a complicated caching scheme would pay for itself. The profile shown here: http://postgis.refractions.net/pipermail/postgis-devel/2008-June/003081.html shows that the problem the PostGIS guys are looking at is definitely an out-of-line case (in fact, it looks like the datum wasn't even compressed). 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] Question about Encoding a Custom Type
On Jun 16, 2008, at 16:48, David Fetter wrote: select array_accum(b) from ( select name from srt order by name ) AS A(b); SELECT ARRAY(SELECT name FROM srt ORDER BY name); -- also works. Wow, somehow I'd missed that syntax over the years. Thanks David! Best, David -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
