Re: [HACKERS] pg_controldata/pg_resetxlog "Latest checkpoint's NextXID" format

On 12/29/2015 07:15 AM, Tom Lane wrote: > Yeah. Use of the same x/y notation with two different bases seems like > a recipe for confusion. It's probably too late to do anything about > this for 9.5, but I'd be +1 for adopting Jose's suggestion or some > other formatting tweak in HEAD. I made the

[HACKERS] custom parameters cannot be removed once set

Today I was reminded of an issue I have run across before, namely that in a given postgres session, once a custom parameter has been set, there is no way to remove it entirely. For example: 8<--- # psql regression psql (9.5rc1) Type "help" for help. regression=# SELECT current_set

Re: [HACKERS] custom parameters cannot be removed once set

On 12/30/2015 10:36 AM, Joe Conway wrote: > A side issue is that it would be nice if there were a way to check for a > custom parameter value without getting an error if it does not exist. > There is a missing_ok option to GetConfigOptionByName(), but we > currently don't expose

Re: [HACKERS] custom parameters cannot be removed once set

On 12/30/2015 10:44 AM, Tom Lane wrote: > Meh. The real problem here is that people are abusing the custom-GUC > mechanism to implement session-lifespan variables. I do not think we > should encourage that; GUC offers neither adequate features for that > (eg, no way to declare a variable's type)

Re: [HACKERS] Proposal: SET ROLE hook

On 01/06/2016 02:39 AM, Pavel Stehule wrote: > I did a review of this patch. > > 1. the proposal is clean and there are not any objection against it. I > checked a implementation, and it does exactly same what was proposed. > > 2. This hook has impact only on SET role to XXX statement, what isn't

Re: [HACKERS] Multi-tenancy with RLS

On 01/06/2016 12:15 PM, Robert Haas wrote: > On Tue, Jan 5, 2016 at 11:07 PM, Haribabu Kommi > wrote: >> May be you missed to apply the 3_shared_catalog_tenancy_v4 path, >> because 4_database_catalog_tenancy_v5 patch depends on it. >> >> Here I attached all the patches for your convenience, I am a

Re: [HACKERS] Writing Trigger Functions in C

rtitioning in C ? >> >> If you have some code to paste so I can start from I will really appreciate. > > Honestly I'd leave the trigger alone and modify the client code in > performance sensitive places to insert directly to the correct > partition table. I second

[HACKERS] pg_dump selectively ignores extension configuration tables

al_ref_sys test|grep spatial_ref_sys pg_dump -n public test|grep spatial_ref_sys 8<-- Is this intentional, or oversight, or missing feature? Thanks, Joe -- Joe Conway credativ LLC: http://www.credativ.us Linux, PostgreSQL, and general Open Source Training,

Re: [HACKERS] pg_dump selectively ignores extension configuration tables

re which - probably the latter? +1 I think it should dump the user data portion, especially since that matches what pg_dump would do if you did not specify the table or schema. Joe -- Joe Conway credativ LLC: http://www.credativ.us Linux, PostgreSQL, and general Open Source Training, Service, Con

Re: [HACKERS] pg_dump selectively ignores extension configuration tables

On 03/13/2013 04:16 PM, Dimitri Fontaine wrote: > Joe Conway writes: >> I think it should dump the user data portion, especially since that >> matches what pg_dump would do if you did not specify the table or schema. > > +1 > > If you don't have time slots to

Re: [HACKERS] pg_dump selectively ignores extension configuration tables

On 03/14/2013 05:23 PM, Joe Conway wrote: > On 03/13/2013 04:16 PM, Dimitri Fontaine wrote: >> Joe Conway writes: >>> I think it should dump the user data portion, especially since that >>> matches what pg_dump would do if you did not specify the table or schema. >&

Re: [HACKERS] pg_dump selectively ignores extension configuration tables

On 03/25/2013 08:12 AM, Vibhor Kumar wrote: > Since, nobody has picked this one. > > If there is no objection,then I can test this patch against 9.1 & 9.2. Here are diffs for 9.1 and 9.2. The previous email was against 9.3 dev. Joe -- Joe Conway credativ LLC: http://www.cred

[HACKERS] pg_dump with postgis extension dumps rules separately

LE be implicitly part of the CREATE EXTENSION? If so, is this a pg_dump bug, PostGIS bug, or pilot error? FWIW I see CREATE OR REPLACE RULE statements in the PostGIS extension SQL script. Thanks, Joe -- Joe Conway credativ LLC: http://www.credativ.us Linux, PostgreSQL, and general Open Source Tra

Re: [HACKERS] pg_dump selectively ignores extension configuration tables

; on this thread. > Is it possible, if we can have two switches for extension in pg_dump: > 1. extension dump with user data in extension tables. > 2. User data-only dump from extensions. This might be worth considering for 9.4 Thanks, Joe -- Joe Conway credativ LLC: http://www.cre

Re: [HACKERS] pg_dump with postgis extension dumps rules separately

On 04/08/2013 07:42 AM, Dimitri Fontaine wrote: > Joe Conway writes: >> Shouldn't that CREATE RULE be implicitly part of the CREATE EXTENSION? > > Yes. It's a bug, been reported before, it's on my todo list. I have > arranged some time to care about it while in b

Re: [HACKERS] a patch for row-at-a-time execution for table functions

we would wait a while to see how that went before worrying again about value-per-call mode. At this point you're looking at 9.4 for this, but I'll try to help see it through since it has long been on my TODO list. Joe - -- Joe Conway credativ LLC: http://www.credativ.us Linux, PostgreSQ

Re: [HACKERS] pg_dump with postgis extension dumps rules separately

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 04/08/2013 08:34 AM, Dimitri Fontaine wrote: > Joe Conway writes: >> OK, maybe I'll try to take a look in the meantime. > > That would be awesome :) > >> Did you have any comment on the other pg_dump patch (revi

Re: [HACKERS] pg_dump --snapshot

ries > which are running on the replica? This sounds a lot like having an "idle in transaction" session hanging around. Could we use something akin to a prepared transaction to preserve the ability to use the snapshot? Maybe with an (optional) expiration timestamp? Joe - -- Joe Co

Re: [HACKERS] sha1, sha2 functions into core?

ndomness > of the salt string than replacing the md5 hash per se. Or change to an md5 HMAC rather than straight md5 with salt. Last I checked (which admittedly was a while ago) there were still no known cryptographic weaknesses associated with an HMAC based on md5. Joe -- Joe Conway creda

Re: [HACKERS] sha1, sha2 functions into core?

nst a stolen set of tokens and HMACs. Didn't we add a hook some time ago for user provided password checker? Joe -- Joe Conway credativ LLC: http://www.credativ.us Linux, PostgreSQL, and general Open Source Training, Service, Consulting, & 24x7 Support -- Sent via pgsql-hackers ma

Re: [HACKERS] has_language_privilege returns incorrect answer for non-superuser

On 08/30/2012 07:23 PM, Bruce Momjian wrote: > On Thu, Jul 12, 2012 at 06:01:00PM -0700, Joe Conway wrote: >> I'll take a look at the latter option sometime in the next few weeks and >> submit for the next commitfest. > > Any news on this? Not yet -- OBE. I'll tr

Re: [HACKERS] use of dblink_build_sql_insert() induces a server crash

On 02/03/2010 04:49 AM, Rushabh Lathia wrote: > Testcase: > > create table foo (a int ); > postgres=# SELECT dblink_build_sql_insert('foo','1 2',2,'{\"0\", > \"a\"}','{\"99\", \"xyz\"}'); > HINT: Use the escape string syntax for escapes, e.g., E'\r\n'. > server closed the connection unexpectedly

Re: [HACKERS] use of dblink_build_sql_insert() induces a server crash

On 02/03/2010 04:49 AM, Rushabh Lathia wrote: > > create table foo (a int ); > postgres=# SELECT dblink_build_sql_insert('foo','1 2',2,'{\"0\", > \"a\"}','{\"99\", \"xyz\"}'); > HINT: Use the escape string syntax for escapes, e.g., E'\r\n'. > server closed the connection unexpectedly The proble

Re: [HACKERS] use of dblink_build_sql_insert() induces a server crash

On 02/03/2010 10:18 AM, Tom Lane wrote: > Joe Conway writes: >> The problem exists with all three dblink_build_sql_* functions. Here is >> a more complete patch. If there are no objections I'll apply this to >> HEAD and look at back-patching -- these functions have ha

[HACKERS] proposed PQconnectdbParams macros (was Re: [BUGS] BUG #5304: psql using conninfo fails in connecting to the server)

[moving to hackers] On 02/02/2010 10:23 PM, Tom Lane wrote: > Joe Conway writes: >> Should I also be looking to replace all (or most) other instances of >> PQsetdbLogin()? > > I think we at least wanted to fix pg_dump(all)/pg_restore. Not sure if > the others are wo

Re: [HACKERS] machine-readable pg_controldata?

On 03/04/2010 02:09 PM, Joshua Tolley wrote: > On Thu, Mar 04, 2010 at 10:54:15PM +0100, Magnus Hagander wrote: >> 2010/3/4 Josh Berkus : >>> pg_controldata --catalog_version >>> >>> Even better would be the ability to get everything which is in >>> pg_controldata currently as part of a system view

Re: [HACKERS] machine-readable pg_controldata?

On 03/05/2010 10:28 AM, Greg Smith wrote: > Heikki Linnakangas wrote: >> Then again, if you don't use the copy in shared memory but just open the >> pg_control file and read it in the UDF, you could implement this as a >> pgfoundry module that works with older versions too. > > This is the directi

Re: [HACKERS] walreceiver is uninterruptible on win32

On 03/15/2010 02:42 AM, Magnus Hagander wrote: > > I think we need to look at this as a single problem needing to be > solved, and then have the same solution applied to dblink and > walreceiver. > +1 Joe signature.asc Description: OpenPGP digital signature

Re: [HACKERS] extended operator classes vs. type interfaces

On 04/09/2010 07:33 AM, Robert Haas wrote: > On Fri, Apr 9, 2010 at 7:55 AM, Yeb Havinga wrote: >> 'tagging' a datatype as a lineair order, it could automatically have a range >> type defined on it, like done for the array types currently. > > The way we've handled array types is, quite frankly,

Re: [HACKERS] possible memory leak with SRFs

On 05/07/2010 09:06 PM, Nikhil Sontakke wrote: >>> Yeah this is my basic confusion. But wouldn't the arguments be >>> evaluated afresh on the subsequent call for this SRF? >> >> No, see ExecMakeFunctionResult(). If we did that we'd have serious >> problems with volatile functions, ie srf(random())

Re: [HACKERS] possible memory leak with SRFs

On 05/08/2010 09:12 AM, Tom Lane wrote: > Joe Conway writes: >> I think this is an example of why we still need to implement a real >> SFRM_ValuePerCall mode that allows results to be pipelined. Yes, >> ValuePerCall sort of works from the targetlist, but it is pretty much &

[HACKERS] memory leak regression 9.1 versus 8.1

emory leak. The real function is actually selecting over many inherited tables (i.e. a partitioned table). Thoughts? Thanks, Joe -- Joe Conway credativ LLC: http://www.credativ.us Linux, PostgreSQL, and general Open Source Training, Service, Consulting, & 24x7 Support CREATE OR REPLACE FUNC

Re: [HACKERS] memory leak regression 9.1 versus 8.1

efore it starts to swap too badly. The memory map it > will then print on stderr should point to where the memory is going. Thanks -- will try that. Joe -- Joe Conway credativ LLC: http://www.credativ.us Linux, PostgreSQL, and general Open Source Training, Service, Consulting, & 24x7 Sup

Re: [HACKERS] memory leak regression 9.1 versus 8.1

On 05/09/2012 03:36 PM, Joe Conway wrote: > Good call -- of course that just means my contrived example fails to > duplicate the real issue :-( > In the real example, even with work_mem = 1 MB I see the same behavior > on 9.1. OK, new script. This more faithfully represents the real l

Re: [HACKERS] memory leak regression 9.1 versus 8.1

On 05/09/2012 05:06 PM, Joe Conway wrote: > OK, new script. This more faithfully represents the real life scenario, > and reproduces the issue on HEAD with out-of-the-box config settings, > versus 8.1 which completes the query having never exceeded a very modest >

Re: [HACKERS] memory leak regression 9.1 versus 8.1

On 05/09/2012 10:01 PM, Tom Lane wrote: > Joe Conway writes: >> The attached one-liner seems to plug up the majority (although not quite >> all) of the leakage. > > Looks sane to me. Are you planning to look for the remaining leakage? Actually, now I'm not so sure

[HACKERS] has_language_privilege returns incorrect answer for non-superuser

--- I verified this behavior on head as well as 9.1 (didn't bother looking any further back). Looks like the reason is that CreateFunction() correctly checks lanpltrusted, whereas pg_language_aclmask() does not. Seems like a bug to me -- opinions? Joe -- Joe

Re: [HACKERS] has_language_privilege returns incorrect answer for non-superuser

On 07/10/2012 12:50 AM, Magnus Hagander wrote: > On Tue, Jul 10, 2012 at 3:23 AM, Joe Conway wrote: >> I verified this behavior on head as well as 9.1 (didn't bother looking >> any further back). Looks like the reason is that CreateFunction() >> correctly ch

Re: [HACKERS] has_language_privilege returns incorrect answer for non-superuser

tter option sometime in the next few weeks and submit for the next commitfest. Is it still worth backpatching a change to has_language_privilege as a bug fix? Joe -- Joe Conway credativ LLC: http://www.credativ.us Linux, PostgreSQL, and general Open Source Training, Service, Consulting, &

Re: [HACKERS] "serializable" in comments and names

d to the alternative > IsolationUsesStmtSnapshot. The attached patch is updated for the various comments, as well as some wording tweaks by me. If there are no objections I'd like to commit this in a day or two. Joe -- Joe Conway credativ LLC: http://www.credativ.us Linux, PostgreSQL, and gen

Re: [HACKERS] "serializable" in comments and names

On 09/09/2010 09:11 AM, Joe Conway wrote: > The attached patch is updated for the various comments, as well as some > wording tweaks by me. If there are no objections I'd like to commit this > in a day or two. Committed. Joe -- Joe Conway credativ LLC: http://www.credativ.us Lin

[HACKERS] getting set up on git (finally)

push Thanks, Joe -- Joe Conway credativ LLC: http://www.credativ.us Linux, PostgreSQL, and general Open Source Training, Service, Consulting, & 24x7 Support mkdir /opt/src/pgsql-git cd /opt/src/pgsql-git git clone --bare --mirror ssh://g...@gitmaster.postgresql.org/postgresql.git cd /opt/

Re: [HACKERS] getting set up on git (finally)

On 10/08/2010 08:12 PM, Robert Haas wrote: > On Fri, Oct 8, 2010 at 4:31 PM, Joe Conway wrote: >> I'm finally trying to get current with the switch to git, following this >> wiki page: >> >> http://wiki.postgresql.org/wiki/Committing_with_Git >&

Re: [HACKERS] clog_redo causing very long recovery time

tMXact. The problem in this case is that they both write XLOG entries, so a simple reversal doesn't help. Joe -- Joe Conway credativ LLC: http://www.credativ.us Linux, PostgreSQL, and general Open Source Training, Service, Consulting, & 24x7 Support signature.asc Description: OpenPGP digital signature

Re: [HACKERS] clog_redo causing very long recovery time

On 05/05/2011 09:00 PM, Tom Lane wrote: > Joe Conway writes: >> Right -- I think another similar problem exists in GetNewMultiXactId >> where ExtendMultiXactOffset could succeed and write an XLOG entry and >> then ExtendMultiXactMember could fail before advancing nextMXa

Re: [HACKERS] possible connection leak in dblink?

On 06/17/2011 01:05 PM, Tom Lane wrote: > Peter Eisentraut writes: >> Is this a bug fix that should be backpatched? > > I pinged Joe Conway about this. He is jetlagged from a trip to the Far > East but promised to take care of it soon. I think we can wait for his > review.

Re: [HACKERS] possible connection leak in dblink?

the change is unnecessary for dblink_record_internal. Looks like the issue with dblink_send_query goes back through 8.4, while dblink_record_internal could be fixed as far back as 8.2. However, since this is really just a case of unused variables and not a leaked connection, I'm inclined to

[HACKERS] SECURITY LABEL on shared database object

does not search the 9.1 documentation? I looked in the 9.1 docs in SQL Commands->SELECT and could find no reference to COLLATE. Can anyone point me to some documentation that would explain what that error message means and how to resolve it? Thanks, Joe -- Joe Conway credativ LLC: h

Re: [HACKERS] SECURITY LABEL on shared database object

On 06/29/2011 04:18 PM, Joe Conway wrote: > 1) COLLATE clause is a new feature in 9.1? > 2) The doc search feature on postgresql.org does not search the 9.1 >documentation? > > I looked in the 9.1 docs in SQL Commands->SELECT and could find no > reference to COLLATE. C

Re: [HACKERS] SECURITY LABEL on shared database object

On 06/29/2011 05:34 PM, Joe Conway wrote: > The third key passed to SearchSysCache is CStringGetTextDatum(provider). > Ultimately FunctionCall2Coll gets called with collation == 0 and > varstr_cmp fails due to the ambiguity. > > Is there something new that should be u

[HACKERS] ERROR: unexpected data beyond EOF ... on NFS mounted PGDATA (SOLVED)

38.el5.nfslseekfixv2.x86_64.rpm http://www.joeconway.com/rpms/kernel-2.6.18-238.el5.nfslseekfixv2.src.rpm HTH, Joe -- Joe Conway credativ LLC: http://www.credativ.us Linux, PostgreSQL, and general Open Source Training, Service, Consulting, & 24x7 Support signature.asc Description: OpenPGP digital signature

[HACKERS] ALTER TABLE deadlock with concurrent INSERT

release notes, I see some marginally related commits, but nothing that jumps out to me as a specific fix. Thoughts? Thanks, Joe -- Joe Conway credativ LLC: http://www.credativ.us Linux, PostgreSQL, and general Open Source Training, Service, Consulting, & 24x7 Support signature.asc Description: OpenPGP digital signature

Re: [HACKERS] ALTER TABLE deadlock with concurrent INSERT

ript with something like: psql dbname < script.sql The concurrent INSERTs are being done by the main application code (running on Tomcat). Joe -- Joe Conway credativ LLC: http://www.credativ.us Linux, PostgreSQL, and general Open Source Training, Service, Consulting, & 24x7 Support signature.asc Description: OpenPGP digital signature

Re: [HACKERS] ALTER TABLE deadlock with concurrent INSERT

On 03/03/2011 03:49 PM, Jim Nasby wrote: > On Mar 2, 2011, at 2:54 PM, Joe Conway wrote: >> On 03/02/2011 12:41 PM, Tom Lane wrote: >>> Looks like the process trying to do the ALTER has already got some >>> lower-level lock on the table. It evidently hasn't

Re: [HACKERS] ALTER TABLE deadlock with concurrent INSERT

orse than the disease. Right. I've already advised they shut down the application during the alter table, which they can do (and in fact already do -- they were restarting the application just prior to this step, which really makes no sense anyway). Thanks, Joe -- Joe Conway credativ LLC: http:

[HACKERS] dblink performance regression

lt;-- In my testing I saw a very consistent 4-5% degradation. I then did a git bisect and traced the performance degradation to this commit: - -- http://git.postgresql.org/gitweb/?p=postgresql.git;a=commit;h=e5de601267d98c5d60df6de8d436685c7105d149 committer

Re: [HACKERS] dblink performance regression

> integer IDs as above, rather than this. Great feedback as always -- thanks! Will make that change. Joe - -- Joe Conway credativ LLC: http://www.credativ.us Linux, PostgreSQL, and general Open Source Training, Service, Consulting, & 24x7 Support -BEGIN PGP SIGNATURE- Version: Gnu

Re: [HACKERS] dblink performance regression

pg_encoding_to_char' too... ;-) > > The attached patch with my review! Awesome, thanks for the review! Joe - -- Joe Conway credativ LLC: http://www.credativ.us Linux, PostgreSQL, and general Open Source Training, Service, Consulting, & 24x7 Support -BEGIN PGP SIGNATURE-

Re: [HACKERS] dblink performance regression

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 12/05/2013 07:05 PM, Joe Conway wrote: > On 12/05/2013 06:53 PM, Tom Lane wrote: >> I seem to remember that at some point we realized that the >> encoding ID assignments are part of libpq's ABI and so can't >> prac

Re: [HACKERS] dblink performance regression

gIfDifferent() (or whatever) we can remove those extra lines in 9.4 ;-) Joe - -- Joe Conway credativ LLC: http://www.credativ.us Linux, PostgreSQL, and general Open Source Training, Service, Consulting, & 24x7 Support -BEGIN PGP SIGNATURE- Version: GnuPG v1.

Re: [HACKERS] Compiling extensions on Windows

ribes how I build PL/R for Windows. I had to match my build system SDK with the one EDB uses to get a compatible binary. It would be nice if we had something equivalent to PGXS on Windows, or maybe even a community build system where authors could get Windows binaries built. Joe - -- Joe Conwa

Re: [HACKERS] Compiling extensions on Windows

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 01/12/2014 06:56 PM, Craig Ringer wrote: > On 01/07/2014 12:41 AM, Joe Conway wrote: >> Yes, this pretty much exactly describes how I build PL/R for >> Windows. I had to match my build system SDK with the one EDB >> uses to ge

Re: [HACKERS] Compiling extensions on Windows

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 01/12/2014 07:22 PM, Craig Ringer wrote: > On 01/13/2014 11:13 AM, Joe Conway wrote: What I mean is that you > should not need a full Pg build tree to compile extensions. Just as > we use PGXS on *nix, so it is possible to just use Visual

Re: [HACKERS] Retiring from the Core Team

On 01/11/2017 04:29 PM, Josh Berkus wrote: > For that reason, as of today, I am stepping down from the PostgreSQL > Core Team. > It's been a long, fun ride, and I'm proud of the PostgreSQL we have > today: both the database, and the community. Thank you for sharing it > with me. End of an era!

Re: [HACKERS] dblink get_connect_string() passes FDW option "updatable" to the connect string, connection fails.

On 11/21/2016 03:59 PM, Corey Huinker wrote: > On 11/21/2016 02:16 PM, Tom Lane wrote: >> The dblink docs recommend using dblink_fdw as the FDW for this purpose, >> which would only accept legal connstr options. However, I can see the >> point of using a postgres_fdw server instead, and considerin

Re: [HACKERS] Getting rid of "unknown error" in dblink and postgres_fdw

On 12/21/2016 08:49 AM, Tom Lane wrote: > We have a report in pgsql-general of a dblink query failing with > ERROR: unknown error > This is, to say the least, unhelpful. And it violates our error > message style guidelines. > > Where that is coming from is a situation where we've failed to

Re: [HACKERS] Getting rid of "unknown error" in dblink and postgres_fdw

On 12/21/2016 09:27 AM, Tom Lane wrote: > Joe Conway writes: >> On 12/21/2016 08:49 AM, Tom Lane wrote: >>> I propose that we should change that string to "could not obtain message >>> string for error on connection "foo"", or something along that

Re: [HACKERS] Getting rid of "unknown error" in dblink and postgres_fdw

On 12/21/2016 10:08 AM, Tom Lane wrote: > I wrote: I propose that we should change that string to "could not obtain message string for error on connection "foo"", or something along that line. > > BTW, looking closer, I notice that the dblink case already has > > errcontext("E

Re: [HACKERS] Getting rid of "unknown error" in dblink and postgres_fdw

On 12/21/2016 04:22 PM, Tom Lane wrote: > Joe Conway writes: >> I did notice that postgres_fdw has the following stanza that I don't see >> in dblink: > >> 8<-- >> /* >> * If we don't get a message from the PGresult, try the PGc

Re: [HACKERS] Getting rid of "unknown error" in dblink and postgres_fdw

On 12/21/2016 09:20 PM, Tom Lane wrote: > Joe Conway writes: >> On 12/21/2016 04:22 PM, Tom Lane wrote: >>> In short, yes, please copy that bit into dblink. > >> The attached should do the trick I think. > > I see that you need to pass the PGconn into dblink_

Re: [HACKERS] dblink get_connect_string() passes FDW option "updatable" to the connect string, connection fails.

On 12/18/2016 02:47 PM, Corey Huinker wrote: > On Sun, Dec 18, 2016 at 4:57 PM, Michael Paquier wrote: >> On Mon, Dec 19, 2016 at 6:48 AM, Joe Conway wrote: >>> Maybe if "CREATE FOREIGN DATA WRAPPER" had a way to specify that the FDW >>> supports a libpq con

Re: [HACKERS] Getting rid of "unknown error" in dblink and postgres_fdw

On 12/22/2016 06:55 AM, Tom Lane wrote: > Joe Conway writes: >> On 12/21/2016 09:20 PM, Tom Lane wrote: >>> I see that you need to pass the PGconn into dblink_res_error() now, but >>> what's the point of the new "bool fail" parameter? > >> That

Re: [HACKERS] RLS related docs

On 09/15/2016 02:34 PM, Joe Conway wrote: > On 09/15/2016 01:33 PM, Robert Haas wrote: >> On Sun, Aug 28, 2016 at 4:23 PM, Joe Conway wrote: >>>>> For COPY, I think perhaps it would be more logical to put the new note >>>>> immediately after the th

Re: [HACKERS] proposal: session server side variables

On 12/23/2016 08:20 AM, Pavel Stehule wrote: > 2016-12-23 16:27 GMT+01:00 Fabien COELHO: >> I have often wished I had such a feature, psql client side :-variables are >> just awful raw text things. Agreed. >> A few comments, mostly about the design: >> >> 1. persistent objects with temporal unsha

Re: [HACKERS] Incautious handling of overlength identifiers

On 12/23/2016 12:44 PM, Tom Lane wrote: > I wrote: >> So what to do? We could run around and fix these individual cases >> and call it good, but if we do, I will bet a very fine dinner that >> more such errors will sneak in before long. Seems like we need a >> coding convention that discourages j

Re: [HACKERS] proposal: session server side variables

On 12/28/2016 10:17 AM, Jim Nasby wrote: > Then IMHO what needs to happen is to have a discussion on actual syntax > instead of calling into question the value of the feature. Following > this thread has been very painful because the communications have not > been very clear. Focus on grammar would

Re: [HACKERS] Compiler warnings

On 12/06/2016 01:59 PM, Robert Haas wrote: > On Tue, Dec 6, 2016 at 3:46 PM, Stephen Frost wrote: >> Good thought, thanks! >> >> Updated patch attached with that change and I also added an Assert() to >> GetCachedPlan(), in case that code gets whacked around later and somehow >> we end up falling

Re: [HACKERS] Compiler warnings

On 01/02/2017 10:18 AM, Robert Haas wrote: > On Thu, Dec 29, 2016 at 10:47 AM, Joe Conway wrote: >> Shouldn't this be back-patched? The plancache warning goes back through >> 9.2 (at least) and the lwlocks warning through 9.5 (or maybe it was 9.4). > > Warnings are goin

Re: [HACKERS] Compiler warnings

On 01/02/2017 11:09 AM, Tom Lane wrote: > Joe Conway writes: >> If there is agreement on fixing these warnings, other than the bison >> generated warning, I would be happy to do it. I'd also be happy to look >> for a fix the bison warning as well if desired, but

Re: [HACKERS] Compiler warnings

On 01/02/2017 10:55 AM, Joe Conway wrote: > On the 9.2 and 9.3 branches I see two warnings: > This one once: > --- > plancache.c:1197:9: warning: ‘plan’ may be used uninitialized in this > function [-Wmaybe-uninitialized] > > And this on

Re: [HACKERS] proposal: session server side variables

On 01/04/2017 04:36 PM, Craig Ringer wrote: > On 5 January 2017 at 08:35, Craig Ringer wrote: >> On 5 January 2017 at 01:49, Fabien COELHO wrote: >>> Good. So we seem to agree that GUCS are transactional? >> >> No. We don't agree. They aren't. > > Uh. I take that back. > > craig=> SET x.s = 'x

Re: [HACKERS] ALTER SYSTEM for pg_hba.conf

On 01/05/2017 08:27 AM, Robert Haas wrote: > There's also the question of whether opening up the ability to do > this sort of thing from the SQL level is a security hazard, It unquestionably is. > but we've already gone fairly far down the path of assuming that > there's not a tremendous amount o

Re: [HACKERS] So, can we stop supporting Windows native now?

On 03/31/2016 06:53 AM, Andrew Dunstan wrote: > The worst thing about developing from my POV isn't something that > actually affects core developers so much, namely the lack of a nice MSVC > equivalent of PGXS. Bingo! +1 -- Crunchy Data - http://crunchydata.com PostgreSQL Support for Secure Ent

Re: [HACKERS] So, can we stop supporting Windows native now?

On 03/30/2016 09:17 PM, Tom Lane wrote: > Craig Ringer writes: >> On 31 March 2016 at 07:49, Josh berkus wrote: >>> So, can we stop supporting Windows native now? > >> Why would we want to? > >> The cost is small. > > Surely you jest. Windows is the single biggest PITA platform from a > porta

Re: [HACKERS] Removing faulty hyperLogLog merge function

On 04/26/2016 07:23 PM, Robert Haas wrote: > On Tue, Apr 26, 2016 at 9:35 PM, Tom Lane wrote: >> Robert Haas writes: >>> I'm not prepared to commit this over the objection offered by Tomas >>> Vondra on that thread. >> >> FWIW, I agree with Peter that we should remove this code. We know that it

Re: [HACKERS] SPI_exec ERROR in pl/r of R 3.2.4 on PostgreSQL on Windows 7

On 04/29/2016 07:58 AM, Andre Mikulec wrote: > I am working with pl/r compiled for R.3.2.4 64 bit on PostgreSQL 9.5.1 > 64 bit on Windows 7 64 bit Who did the compiling? Did you compile everything yourself, or use binary installers for some of it? If so, which ones? Joe -- Crunchy Data - http:/

Re: [HACKERS] Losing memory references - SRF + SPI

On 05/13/2016 09:35 PM, Anderson Carniel wrote: > I am writing a function that returns a set of tuples by using also the > PostGIS. Thuis, I am using SRF too. It successfully returns the expected > result when it has at most 4 tuples. However, this is not the case when > more than 4 tuples have to

Re: [HACKERS] Reviewing freeze map code

On 05/18/2016 09:55 AM, Victor Yegorov wrote: > 2016-05-18 16:45 GMT+03:00 Robert Haas >: > > No, that's what the existing FREEZE option does. This new option is > about unnecessarily vacuuming pages that don't need it. The > expectation is that vacuumi

Re: [HACKERS] Changed SRF in targetlist handling

On 05/23/2016 12:39 PM, Merlin Moncure wrote: > On Mon, May 23, 2016 at 2:13 PM, David Fetter wrote: >> On Mon, May 23, 2016 at 01:28:11PM -0500, Merlin Moncure wrote: >>> On Mon, May 23, 2016 at 12:10 PM, Tom Lane wrote: Andres Freund writes: > discussing executor performance with a nu

Re: [HACKERS] Changed SRF in targetlist handling

On 05/23/2016 02:37 PM, David G. Johnston wrote: > ​But then I don't get Joe's point - if its an implementation detail why > should it matter if rewriting the SRF-in-tlist to be laterals changes > execution from a serial to an interleaved​ implementation. Plus, Joe's > claim: "the capability to pi

Re: [HACKERS] Inheritance

On 05/23/2016 03:05 PM, Tom Lane wrote: > Jim Nasby writes: >> I don't see why partitioning complicates fixing these issues. ISTM it's >> the exact same complaint for both inheritance and partitioning. > > My feeling about it is that we need to provide a partitioning feature > that doesn't rely

[HACKERS] RLS related docs

Please see attached two proposed patches for the docs related to RLS: 1) Correction to pg_restore 2) Additional mentions that "COPY FROM" does not allow RLS to be enabled Comments? Related question: I believe COPY tbl TO ... is internally converted to COPY (select * FROM tbl) TO ... when

Re: [HACKERS] Does people favor to have matrix data type?

On 05/28/2016 07:12 AM, Kouhei Kaigai wrote: > Sparse matrix! It is a disadvantaged area for the current array format. > > I have two ideas. HPC folks often split a large matrix into multiple > grid. A grid is typically up to 1024x1024 matrix, for example. > If a grid is consists of all zero eleme

Re: [HACKERS] Does people favor to have matrix data type?

On 05/28/2016 03:33 PM, Kouhei Kaigai wrote: >> -Original Message- >> From: Joe Conway [mailto:m...@joeconway.com] >> Sent: Sunday, May 29, 2016 1:40 AM >> To: Kaigai Kouhei(海外 浩平); Jim Nasby; Ants Aasma; Simon Riggs >> Cc: pgsql-hackers@postgresql.org >>

Re: [HACKERS] Does people favor to have matrix data type?

On 05/29/2016 04:55 PM, Kouhei Kaigai wrote: > For the closer integration, it may be valuable if PL/R and PL/CUDA can > exchange > the data structure with no serialization/de-serialization when PL/R code tries > to call SQL functions. I had been thinking about something similar. Maybe PL/R can cr

Re: [HACKERS] RLS related docs

On 05/26/2016 12:26 AM, Dean Rasheed wrote: > On 25 May 2016 at 02:04, Joe Conway wrote: >> Please see attached two proposed patches for the docs related to RLS: >> >> 1) Correction to pg_restore >> 2) Additional mentions that "COPY FROM" does not a

Re: [HACKERS] contrib/fuzzystrmatch/dmetaphone.c license

ed > in the past (by those with appropriate letters after their names) > to stop using the Artistic licence. This is why I spent nearly a > year working on changing pgAdmin to the PostgreSQL licence. I committed this (1 July 2004), but cannot remember any details about a license discussion. And

[HACKERS] changing primary key col(s) with minimal impact

. Questions: 1) any major holes in this approach? 2) any better ideas? 3) should we consider an ALTER TABLE ALTER CONSTRAINT command (or some such) to allow demotion of a PRIMARY KEY to a UNIQUE constraint? Thanks for any thoughts/comments. Joe - -- Joe Conway credativ LLC: http://www

Re: [HACKERS] Commitfest problems

s honest. > > Wow, that's radical, and interesting. Actually, to me it sounds a lot like what we did 10 years ago before the commitfests except with a way to track the patches (other than the mail archives) and more people participating in patch reviews. Joe - -- Joe Conway credat

[HACKERS] psql -c does not honor ON_ERROR_STOP

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 This seems like either a psql bug or maybe just a documentation bug. I know the psql docs say that -c behavior can be surprising, but I find the below surprising even after reading the docs a couple of times. Given that ON_ERROR_STOP defaults to off, i

<    1   2   3   4   5   6   7   8   9   10   >