Re: [HACKERS] Should pg_dump dump larger tables first?
On 1/31/2013 2:06 AM, Dimitri Fontaine wrote: Loading several big'o'tables in parallel tend not to give benefits in the tests I've done so far, but that might be an artefact of python multi threading, I will do some testing with proper tooling later. or insufficient IO parallelism in your disk hardware, file system, etc. -- john r pierce 37N 122W somewhere on the middle of the left coast -- 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] [sepgsql 1/3] add name qualified creation label
On 1/23/2013 8:32 PM, Tom Lane wrote: FWIW, in Fedora-land I see: F16: 2.1.6 (F16 will go out of support next month) F17: 2.1.10 (F17 has been stable for 6+ months) F18: 2.1.12 (F18 just went stable) While requiring 2.1.10 today might be thought a tad leading-edge, will that still be true by the time we ship 9.3? I'd be far more interested in what is in RHEL and CentOS.Fedora, with its 6 month obsolescence cycle, is of zero interest to me for deploying database servers. EL6 has libselinux 2.0.94 EL5 has libselinux 1.33.4 -- 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] Error Building rpm
On 1/20/2013 9:23 PM, Vivek Singh Raghuwanshi wrote: 3.RedHat_RHEL-6 uuid-devel (Now RedHat is not providing this rpm) you sure about that? now, I'm running CentOS 6 not RHEL6, but the packages are 1:1 and built from the same SRPMs. uuid-devel.i686 1.6.1-10.el6 base uuid-devel.x86_64 1.6.1-10.el6 base -- 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] AIX buildfarm member
On 1/11/2013 6:56 AM, Steve Singer wrote: If someone else in the community is running PostgreSQL on AIX then it would be good if they setup a buildfarm member, perhaps with a more recent version of AIX. I am and I'd love to, however, sigh, its deep behind corporate firewalls and any attempt at doing something like that would land me in all kinda hurt. I run AIX 6.1 and 7 LPAR's (IBM's equivalent of a VM) on our AIX dev box, which is a 2 core Power 6. Another complexity is that the licensing for XL C is per 'seat' (named user). I'm really surprised IBM doesn't have some program to support a worthy project like this. -- 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] Improve compression speeds in pg_lzcompress.c
On 1/7/2013 1:10 AM, Simon Riggs wrote: On 7 January 2013 07:29, Takeshi Yamamuro yamamuro.take...@lab.ntt.co.jp wrote: Anyway, the compression speed in lz4 is very fast, so in my opinion, there is a room to improve the current implementation in pg_lzcompress. So why don't we use LZ4? what will changing compression formats do for compatability? this is for the compressed data in pg_toast storage or something? will this break pg_upgrade style operations? -- 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] Improve compression speeds in pg_lzcompress.c
On 1/7/2013 2:05 AM, Andres Freund wrote: I think there should be enough bits available in the toast pointer to indicate the type of compression. I seem to remember somebody even posting a patch to that effect? I agree that it's probably too late in the 9.3 cycle to start with this. so an upgraded database would have old toasted values in the old compression format, and new toasted values in the new format in an existing table? that's kind of ugly. -- 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] discarding duplicate indexes
On 12/20/2012 12:26 AM, Gavin Flower wrote: CREATE TABLE test (id int, int sub, text payload); CREATE INDEX test_idx1 ON test (id, sub); CREATE INDEX test_idx2 ON test (id); Nowtest_idx2 is logically included intest_idx1, but if the majority of transactions only query onid, thentest_idx2 would be more better as it ties up less RAM if sub is an integer, that index isn't that much larger. both indexes need to index all the rows, and with the header and block overhead, the extra word isn't that big of a deal. as long as there are some transactions using the other index, most of both of them will likely want to be in memory, so you'll end up using MORE memory.
Re: [HACKERS] pg_top
On 12/20/2012 4:17 AM, Brett Maton wrote: It appears that procpid has been renamed to pid at some point, also the column current_query appears to have been shortened to query. My patch updates a couple of queries to use the new shorter column names. IMHO, any such fix should check the version, and use the old name for 9.2, and new for = 9.2 /me tossed another mumbled curse at whomever changed that field name.
Re: [HACKERS] ALTER TABLE ... NOREWRITE option
On 12/5/2012 1:42 AM, Simon Riggs wrote: I think we need a parameter called schema_change_reporting = off (default) | on [USERSET] which displays relevant statistics/reports about the actions taken by DDL statements. That will also highlight locks and the need to reduce their lock levels. where does this get displayed? is it just tossed into the postgres log files? -- 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] MySQL search query is not executing in Postgres DB
On 11/27/12 2:41 PM, Tom Lane wrote: Tweaking the casting rules could have a lot of unforeseen consequences. understatement of the year. IMHO. $0.02 worth etc. -- john r pierceN 37, W 122 santa cruz ca mid-left coast -- 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] [PERFORM] out of memory
On 11/05/12 9:27 AM, Robert Haas wrote: That is, if we have a large datum that we're trying to send back to the client, could we perhaps chop off the first 50MB or so, do the encoding on that amount of data, send the data to the client, lather, rinse, repeat? I'd suggest work_mem sized chunks for this? -- john r pierceN 37, W 122 santa cruz ca mid-left coast -- 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] Arguments to foreign tables?
On 11/04/12 11:59 AM, Jeff Davis wrote: Is there any fundamental or philosophical reason why a foreign table can't accept arguments? Should that be a TODO? what does that even mean?how would 'data' accept 'arguments' ??! -- john r pierceN 37, W 122 santa cruz ca mid-left coast -- 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] Deprecating RULES
On 10/17/12 2:31 AM, Dimitri Fontaine wrote: Then if you insist on comparing to a macro facility, as we're talking about dynamic code rewriting, maybe we need to compare RULEs to the lisp style macro facility, which is nothing like a pre-processor facility (in lisp, that's the reader, I think). Except the vast majority of the audience likely have no idea what the 'lisp macro system' is like or what this comparison implies.. Even though I dabbled in a little LISP almost 40 years ago, I don't remember anything about LISP macros, just Assembler and C macros :) Any such comparison should be with something that is common knowledge, not something even more obscure than the primary subject matter. -- john r pierceN 37, W 122 santa cruz ca mid-left coast -- 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] Deprecating RULES
On 10/17/12 10:46 AM, Greg Stark wrote: Warning: RULES are tricky to use correctly. They rewrite the original query into a new query before it is run and it is very hard to correctly anticipate and rewrite every possible input query into the desired result. There are also unexpected interactions with other components when RULES do something unexpected such as rewrite a single query to return two result sets. For most applications it's much simpler and more predictable to use TRIGGERs. ROW level triggers are evaluated for each row the original query is about to process (or has just finished processing) and this makes them much easier to follow. Statement level TRIGGERs can be used for audit logs and similar operations which need to run once per statement. as a relative novice, I concur, this is clear, concise, and to the point. -- john r pierceN 37, W 122 santa cruz ca mid-left coast -- 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] Successor of MD5 authentication, let's use SCRAM
On 10/12/12 4:25 PM, Stephen Frost wrote: * Josh Berkus (j...@agliodbs.com) wrote: Unless we can give people a run these three commands on each server and you're now SSL authenticating script, we can continue to expect the majority of users not to use SSL. And I don't think that level of simplicity is even theoretically possible. The Debian-based packages do quite a bit to ease this pain. Do the other distributions do anything to set up SSL certificates, etc on install? Perhaps they could be convinced to? don't forget, there's OS's other than Linux to consider too... the various BSD's, Solaris, AIX, OSX, and MS Windows are all platforms PostgreSQL runs on. -- john r pierceN 37, W 122 santa cruz ca mid-left coast -- 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] Successor of MD5 authentication, let's use SCRAM
On 10/12/12 9:00 PM, Darren Duncan wrote: And now we're migrating to Red Hat for the production launch, using the http://www.postgresql.org/download/linux/redhat/ packages for Postgres 9.1, and these do *not* include the SSL. hmm? I'm using the 9.1 for CentOS 6(RHEL 6) and libpq.so certainly has libssl3.so, etc as references. ditto the postmaster/postgres main program has libssl3.so too. maybe your certificate chains don't come pre-built, I dunno, I haven't dealt with that end of things. -- john r pierceN 37, W 122 santa cruz ca mid-left coast -- 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] Bad Data back Door
On 10/06/12 3:45 AM, Heikki Linnakangas wrote: At the SQL level, there's the convert(bytea, name, name) function. ahhh, right. (forehead slap) a 2nd function would do the same, but replace errors with the substitution character in the target charset and not error. Hmm, I don't think we have that. me thinks this would be extremely useful for importing 'dirty' data. that or a per-connection flag (or option on the COPY command?) that said substitute-on-error for the likes of UTF-8 imports from CSV. -- john r pierceN 37, W 122 santa cruz ca mid-left coast -- 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] Bad Data back Door
On 10/05/12 6:12 PM, Tom Lane wrote: Now, having said that, I think it has to be the reponsibility of the FDW to apply any required check ... which makes this a bug report against oracle_fdw, not the core system. (FWIW, contrib/file_fdw depends on the COPY code, which will check encoding.) I'm not sure of that. what if the FDW is used to connect to (say) a postgres database that is in POSIX/C ? is that checked for? I'd like to see some encoding validation and substitution functions in postgres. for instance, one that can take any supported encoding and convert it to the database encoding and generate an error on any invalid character. this translation could be identity (eg, UTF8-UTF8) whereupon it would just validate.a 2nd function would do the same, but replace errors with the substitution character in the target charset and not error. -- john r pierceN 37, W 122 santa cruz ca mid-left coast -- 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] psql, remove include of psqlscan.c
On 09/27/12 8:41 AM, Alvaro Herrera wrote: But I think I see what Tom objection to it is: if we export this capability to libpq applications, then we set it in stone to a certain extent: exactly how things are split would become part of the API, so to speak. Upgrading to a newer libpq could break application code that worked with the previous release's by splitting things differently. I don't currently have an opinion on whether this is a bad thing or not. Who wants to argue for/against? I wonder if it shouldn't be in a separate 'helper' library, as it has no direct ties to any libpq internals. -- john r pierceN 37, W 122 santa cruz ca mid-left coast -- 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] Switching timeline over streaming replication
On 09/25/12 11:01 AM, m...@rpzdesign.com wrote: At some point, every master - slave replicator gets to the point where they need to start thinking about master-master replication. master-master and transactional integrity are mutually exclusive, except perhaps in special cases like Oracle RAC, where the masters share a coherent cache and implement global locks. -- john r pierceN 37, W 122 santa cruz ca mid-left coast -- 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] libpq connectoin redirect
feng tian wrote: Hi, I want to load balance a postgres server on 4 physical machines, say 127.0.0.11-14. I can set up a pgbouncer on 127.0.0.10 and connection pooling to my four boxes. However, the traffic from/to clients will go through an extra hop. Another way to do this, is to send the client an redirect message. When client connect to 127.0.0.10, instead of accepting the connection, it can reply to client telling it to reconnect to one of the server on 127.0.0.11-14. I am planning to write/submit a patch to do that. I wonder if there is similar effort in extending libpq protocol, or, if you have better ideas on how to achieve this. how do you plan on maintaining consistency, transactional integrity and atomicity of updates across these 4 machines? -- 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] solaris sparc 64bit binary release
Bjorn Munch wrote: I will have a look into it. as of right now, I suspect what I need are the following files from a recent Solaris 64bit build... include/server/pg_config.h lib/64/pgxs/src/Makefile.global there are a few more files that could be involved, but AFAIK, they are invariant or don't matter to my plugin builds -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] solaris sparc 64bit binary release
the 8.4.3 binary tarball for solaris sparc 64bit on postgresql.com was shipped with the 32bit includes and the Makefile fragments from 8.4-community/lib/64/pgxs/src/ I'm specifically hitting this contradition: $ grep FLOAT8 include/server/pg_config.h #define FLOAT8PASSBYVAL false and $ pg_controldata /var/postgres/8.4-community/data_64 | grep Float8 Float8 argument passing: by value For mostly corporate reasons, I need to get some C modules, specifically pl/java, working with the binary release: postgresql-8.4.3-S10.sparc-64.tar.bz2 rather than have to build my own postgres and freak out the data center operations guys. Is there any chance I can get the correct include/server/pg_config.h and lib/64/pgxs/src/Makefile.global from the packager, whom I gather is Bjorn Much and has been seen on this list?
Re: [HACKERS] [BUGS] BUG #2052: Federal Agency Tech Hub Refuses to
Bruce Momjian wrote: If someone wants to create a separate web page to track fixes related to CVE number, that is fine. My guess is that most people reading the release notes don't care about the CVE numbers themselves (just that each release has all known security bugs fixed), and most bugs that are fixed don't have CVE numbers at commit time. I think its quite reasonable for the one line description of a postgres bug to reference CVE-2005-0247 multiple buffer overflows... or whatever, I guess it kind of depends on which came first... if the CVE security item came first, and was entered into the PGSQL bug tracker, then this makes a LOT of sense. if the CVE folks create their entry AFTER the bug has been entered into PGSQL, it makes less sense. ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] [BUGS] We are not following the spec for HAVING without GROUP
select 1 from tab having 1=1;
returns 2 rows
I'm curious whats in those two rows... {{1} {1}} ?
---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster
