Re: [HACKERS] Curing plpgsql's memory leaks for statement-lifespan values

On 22 July 2016 at 13:24, Craig Ringer wrote: > > On 22 July 2016 at 07:02, Tom Lane wrote: > >> In >> >> https://www.postgresql.org/message-id/tencent_5c738eca65bad6861aa43...@qq.com >> it was pointed out that you could get an intra-function-call

Re: [HACKERS] Curing plpgsql's memory leaks for statement-lifespan values

On 22 July 2016 at 07:02, Tom Lane wrote: > In > > https://www.postgresql.org/message-id/tencent_5c738eca65bad6861aa43...@qq.com > it was pointed out that you could get an intra-function-call memory leak > from something like > > LOOP > BEGIN >

Re: [HACKERS] Password identifiers, protocol aging and SCRAM protocol

On 22 July 2016 at 01:31, Tom Lane wrote: > David Steele writes: > > On 7/21/16 12:19 PM, Robert Haas wrote: > >> On Wed, Jul 20, 2016 at 7:42 PM, Michael Paquier > >> wrote: > People have, in the past, expressed concerns

Re: [HACKERS] Constraint merge and not valid status

On 2016/07/22 0:38, Robert Haas wrote: > On Wed, Jul 13, 2016 at 5:22 AM, Amit Langote > wrote: >> Consider a scenario where one adds a *valid* constraint on a inheritance >> parent which is then merged with a child table's *not valid* constraint >> during

Re: [HACKERS] Visual Studio 2015 and telemetry calls

On 22 July 2016 at 10:45, Michael Paquier wrote: > Hi all, > > Some people may have bumped into the following surprise for VS2015: > > https://yro.slashdot.org/story/16/06/10/1350245/visual-studio-2015-c-compiler-secretly-inserts-telemetry-code-into-binaries > > VS

Re: [HACKERS] Oddity in handling of cached plans for FDW queries

On 2016/07/21 16:30, Etsuro Fujita wrote: One thing I'd like to discuss is GetUserMappingById/GetUserMappingId. Though those functions aren't used in any places, I didn't take them out, because I thought somebody else would need them someday. But considering that user mapping OIDs now aren't

Re: [HACKERS] Visual Studio 2015 and telemetry calls

On Fri, Jul 22, 2016 at 11:45 AM, Michael Paquier wrote: > Some people may have bumped into the following surprise for VS2015: > https://yro.slashdot.org/story/16/06/10/1350245/visual-studio-2015-c-compiler-secretly-inserts-telemetry-code-into-binaries > > VS 2015 is

[HACKERS] Visual Studio 2015 and telemetry calls

Hi all, Some people may have bumped into the following surprise for VS2015: https://yro.slashdot.org/story/16/06/10/1350245/visual-studio-2015-c-compiler-secretly-inserts-telemetry-code-into-binaries VS 2015 is adding calls to telemetry (surprise!) to track activity of an application... I can't

Re: [HACKERS] fixes for the Danish locale

Jeff Janes writes: > On Thu, Jul 21, 2016 at 2:11 PM, Tom Lane wrote: >> I see that the core tests fall over in Turkish still :-( > Turkish has never passed (at least back to 9.0). It looks like it is > in the stemming functions. I don't understand

Re: [HACKERS] fixes for the Danish locale

On Thu, Jul 21, 2016 at 2:11 PM, Tom Lane wrote: > Jeff Janes writes: >> In Danish, the sequence 'aa' is sometimes treated as a single letter >> which collates after 'z'. >> Some regression tests got into 9.5, and are still in 9.6beta3, which >> fail due

[HACKERS] Rethinking TupleTableSlot deforming

Hi, I've previously mentioned (e.g. [1]) that tuple deforming is a serious bottlneck. I've also experimented successfully [2] making slot_deform_tuple() faster. But nontheless, tuple deforming is still a *major* bottleneck in many cases, if not the *the* major bottleneck. We could partially

Re: [HACKERS] Password identifiers, protocol aging and SCRAM protocol

On Fri, Jul 22, 2016 at 9:02 AM, Tom Lane wrote: > Michael Paquier writes: >> One thing about my current set of patches is that I have begun adding >> files from src/common/ to libpq's list of files. As that would be new >> I am wondering if I

[HACKERS] mostly null slots in hash-aggs cause performance degradation

Hi, To build the representative tuple for each group in hash-aggregates we do: static AggHashEntry lookup_hash_entry(AggState *aggstate, TupleTableSlot *inputslot) { ... /* if first time through, initialize hashslot by cloning input slot */ if (hashslot->tts_tupleDescriptor ==

Re: [HACKERS] Password identifiers, protocol aging and SCRAM protocol

Michael Paquier writes: > On Fri, Jul 22, 2016 at 8:48 AM, Tom Lane wrote: >> I'm confused. We need that code in both libpq and backend, no? >> src/common is the place for stuff of that description. > Not necessarily. src/interfaces/libpq/Makefile

Re: [HACKERS] Password identifiers, protocol aging and SCRAM protocol

On Fri, Jul 22, 2016 at 8:48 AM, Tom Lane wrote: > Michael Paquier writes: >> Because I would like to just change my set of patches to have the SHA >> and the encoding functions in src/backend/libpq instead of src/common, >> and then have pgcrypto

Re: [HACKERS] Password identifiers, protocol aging and SCRAM protocol

Michael Paquier writes: > On Fri, Jul 22, 2016 at 2:31 AM, Tom Lane wrote: >> Note that "crypto" for this purpose generally means reversible encryption; >> I've never heard that one-way hashes are illegal anywhere. So password >> hashing such as

Re: [HACKERS] RecoveryTargetTLI dead variable in XLogCtlData

On Fri, Jul 22, 2016 at 12:54 AM, Robert Haas wrote: > On Tue, Jul 12, 2016 at 11:29 PM, Michael Paquier > wrote: >> I just bumped into $subject, a variable that is never set and never used: >> --- a/src/backend/access/transam/xlog.c >> +++

Re: [HACKERS] Password identifiers, protocol aging and SCRAM protocol

On Fri, Jul 22, 2016 at 2:31 AM, Tom Lane wrote: > Way back when, like fifteen years ago, there absolutely were US export > control restrictions on software containing crypto. I believe the US has > figured out that that was silly, but I'm not sure everyplace else has.

[HACKERS] Curing plpgsql's memory leaks for statement-lifespan values

In https://www.postgresql.org/message-id/tencent_5c738eca65bad6861aa43...@qq.com it was pointed out that you could get an intra-function-call memory leak from something like LOOP BEGIN EXECUTE 'bogus command'; EXCEPTION WHEN OTHERS THEN END;

Re: [HACKERS] PoC: Make it possible to disallow WHERE-less UPDATE and DELETE

On Thu, Jul 21, 2016 at 04:48:37PM -0500, Jim Nasby wrote: > On 7/21/16 11:46 AM, David Fetter wrote: > > > > Can't you implement this as a extension? > > Yes. In that case, I'd want to make it a contrib extension, as it is > > at least in theory attached to specific major versions of the

Re: [HACKERS] PoC: Make it possible to disallow WHERE-less UPDATE and DELETE

On 7/21/16 11:46 AM, David Fetter wrote: > Can't you implement this as a extension? Yes. In that case, I'd want to make it a contrib extension, as it is at least in theory attached to specific major versions of the backend. Howso? -- Jim Nasby, Data Architect, Blue Treble Consulting, Austin

Re: [HACKERS] fixes for the Danish locale

Jeff Janes writes: > In Danish, the sequence 'aa' is sometimes treated as a single letter > which collates after 'z'. > Some regression tests got into 9.5, and are still in 9.6beta3, which > fail due to assuming they know how things will sort or compare. As of HEAD,

Re: [HACKERS] pg_restore & search_path, COPY failed for table "mytable": ERROR: function myinnerfunction(integer) does not exist

On Thu, Jul 21, 2016 at 1:57 PM, Jean-Pierre Pelletier < jppellet...@e-djuster.com> wrote: > > I'm puzzled as to how search_path should be used,. > Should all references be schema qualified inside functions body ? > ​Pretty much...you can also do: CREATE FUNCTION funcname() SET search_path TO

Re: [HACKERS] fixes for the Danish locale

On 07/21/2016 02:26 PM, Greg Stark wrote: On Thu, Jul 21, 2016 at 5:44 PM, Tom Lane wrote: Confirmed here. Will deal with it, but I wonder why we have no buildfarm members covering this ... We're not going to have a build farm member for every locale the local systems

[HACKERS] pg_restore & search_path, COPY failed for table "mytable": ERROR: function myinnerfunction(integer) does not exist

Hi, The following steps reproduce an error with pg_restore: DROP TABLE IF EXISTS myTable; DROP FUNCTION IF EXISTS myInnerFunction(INTEGER); DROP FUNCTION IF EXISTS myOuterFunction(INTEGER); DROP SCHEMA IF EXISTS myOtherSchema; CREATE SCHEMA myOtherSchema; SET search_path = myPrimarySchema,

Re: [HACKERS] fixes for the Danish locale

On Thu, Jul 21, 2016 at 11:49 AM, Jeff Janes wrote: > Does testing in other locales ever uncover bugs other than those in > the tests themselves? Is it worth trying to maintain broad coverage? Potentially, yes. The strxfrm() inconsistency issue disproportionately affected

Re: [HACKERS] fixes for the Danish locale

On Thu, Jul 21, 2016 at 11:44 AM, Tom Lane wrote: > Note that there are certain locales we've deliberately chosen not to > support in some regression tests (see e.g. plpython_unicode.sql), so > I'm not really willing to buy into the idea that "any random locale found > on a

Re: [HACKERS] fixes for the Danish locale

On Thu, Jul 21, 2016 at 9:44 AM, Tom Lane wrote: > Jeff Janes writes: >> In Danish, the sequence 'aa' is sometimes treated as a single letter >> which collates after 'z'. >> Some regression tests got into 9.5, and are still in 9.6beta3, which >> fail due

Re: [HACKERS] fixes for the Danish locale

Peter Geoghegan writes: > On Thu, Jul 21, 2016 at 11:29 AM, Tom Lane wrote: >> Nah, we have a hard enough time with reproducibility of buildfarm results >> without deliberately injecting transient failures. > It could be pseudo-random, and so deterministic

Re: [HACKERS] fixes for the Danish locale

On Thu, Jul 21, 2016 at 11:29 AM, Tom Lane wrote: >> Perhaps the build farm script should pick a random locale for each >> run. Either a random locale from the set on the OS or a random >> language from a list of locale that the regression tests are intended >> to be safe for.

Re: [HACKERS] fixes for the Danish locale

Greg Stark writes: > On Thu, Jul 21, 2016 at 5:44 PM, Tom Lane wrote: >> Confirmed here. Will deal with it, but I wonder why we have no buildfarm >> members covering this ... > We're not going to have a build farm member for every locale the local > systems

Re: [HACKERS] fixes for the Danish locale

On Thu, Jul 21, 2016 at 11:26 AM, Greg Stark wrote: > Perhaps the build farm script should pick a random locale for each > run. Either a random locale from the set on the OS or a random > language from a list of locale that the regression tests are intended > to be safe for.

Re: [HACKERS] fixes for the Danish locale

On Thu, Jul 21, 2016 at 5:44 PM, Tom Lane wrote: > > Confirmed here. Will deal with it, but I wonder why we have no buildfarm > members covering this ... We're not going to have a build farm member for every locale the local systems support. Perhaps the build farm script

Re: [HACKERS] Password identifiers, protocol aging and SCRAM protocol

David Steele writes: > On 7/21/16 12:19 PM, Robert Haas wrote: >> On Wed, Jul 20, 2016 at 7:42 PM, Michael Paquier >> wrote: People have, in the past, expressed concerns about linking in pgcrypto. Apparently, in some countries, it's a

Re: [HACKERS] One question about transformation ANY Sublinks into joins

On Thu, Jul 21, 2016 at 9:53 PM, Robert Haas wrote: > It would need to be a Hash Semi Join rather than a Hash Join, wouldn't it? I guess, Hash Join will do here, because inner hash node is, on hash aggregate with group key on t2.id2, t2.c2 and hash join condition is

Re: [HACKERS] Password identifiers, protocol aging and SCRAM protocol

On 7/21/16 12:19 PM, Robert Haas wrote: > On Wed, Jul 20, 2016 at 7:42 PM, Michael Paquier > wrote: >>> People have, in the past, expressed concerns about linking in >>> pgcrypto. Apparently, in some countries, it's a legal problem. >> >> Do you have any references? I

Re: [HACKERS] PoC: Make it possible to disallow WHERE-less UPDATE and DELETE

On Thu, Jul 21, 2016 at 12:49 PM, Abhijit Menon-Sen wrote: > At 2016-07-21 12:46:29 -0400, robertmh...@gmail.com wrote: >> >> I join with others in thinking it's a reasonable contrib module. > > I don't like the use of the term "empty" to describe an UPDATE or DELETE >

Re: [HACKERS] PoC: Make it possible to disallow WHERE-less UPDATE and DELETE

At 2016-07-21 12:46:29 -0400, robertmh...@gmail.com wrote: > > I join with others in thinking it's a reasonable contrib module. I don't like the use of the term "empty" to describe an UPDATE or DELETE without a WHERE clause. -- Abhijit -- Sent via pgsql-hackers mailing list

Re: [HACKERS] PoC: Make it possible to disallow WHERE-less UPDATE and DELETE

On Thu, Jul 21, 2016 at 12:51:50PM -0400, Robert Haas wrote: > On Thu, Jul 21, 2016 at 12:49 PM, Abhijit Menon-Sen > wrote: > > At 2016-07-21 12:46:29 -0400, robertmh...@gmail.com wrote: > >> > >> I join with others in thinking it's a reasonable contrib module. > > > > I

Re: [HACKERS] PoC: Make it possible to disallow WHERE-less UPDATE and DELETE

On Thu, Jul 21, 2016 at 12:46:29PM -0400, Robert Haas wrote: > On Thu, Jul 21, 2016 at 12:39 PM, David Fetter wrote: > > On Thu, Jul 21, 2016 at 06:20:37PM +0300, Teodor Sigaev wrote: > >> > Please find attached a patch which makes it possible to disallow > >> > UPDATEs and

Re: [HACKERS] PoC: Make it possible to disallow WHERE-less UPDATE and DELETE

On Thu, Jul 21, 2016 at 09:21:55AM -0400, Jim Mlodgenski wrote: > On Thu, Jul 21, 2016 at 12:57 AM, David Fetter wrote: > > Please find attached a patch which makes it possible to disallow > > UPDATEs and DELETEs which lack a WHERE clause. As this changes > > query behavior,

Re: [HACKERS] PoC: Make it possible to disallow WHERE-less UPDATE and DELETE

On Thu, Jul 21, 2016 at 12:39 PM, David Fetter wrote: > On Thu, Jul 21, 2016 at 06:20:37PM +0300, Teodor Sigaev wrote: >> > Please find attached a patch which makes it possible to disallow >> > UPDATEs and DELETEs which lack a WHERE clause. As this changes query >> > behavior,

Re: [HACKERS] fixes for the Danish locale

Jeff Janes writes: > In Danish, the sequence 'aa' is sometimes treated as a single letter > which collates after 'z'. > Some regression tests got into 9.5, and are still in 9.6beta3, which > fail due to assuming they know how things will sort or compare. Confirmed here.

Re: [HACKERS] Regression tests vs existing users in an installation

On Mon, Jul 18, 2016 at 11:13 AM, Tom Lane wrote: >> I don't particularly like your suggestion of spooky action at a >> distance between force_parallel_mode and regression_test_mode. That >> just seems kooky. > > It's certainly a judgment call as to which way is cleaner, but

Re: [HACKERS] PoC: Make it possible to disallow WHERE-less UPDATE and DELETE

On Thu, Jul 21, 2016 at 06:20:37PM +0300, Teodor Sigaev wrote: > > Please find attached a patch which makes it possible to disallow > > UPDATEs and DELETEs which lack a WHERE clause. As this changes query > > behavior, I've made the new GUCs PGC_SUSET. > > > > What say? > > DELETE FROM tbl

Re: [HACKERS] Regression tests vs existing users in an installation

On Mon, Jul 18, 2016 at 1:34 AM, Michael Paquier wrote: > One downside of the plugin is that any users willing to do make > installcheck would need to install it as well. Not really. If the only purpose of the plugin is to verify that we're not creating regression

Re: [HACKERS] One question about transformation ANY Sublinks into joins

On Sun, Jul 17, 2016 at 5:33 AM, Armor wrote: > Hi > I run a simple SQL with latest PG： > postgres=# explain select * from t1 where id1 in (select id2 from t2 where > c1=c2); > QUERY PLAN >

Re: [HACKERS] Password identifiers, protocol aging and SCRAM protocol

On Wed, Jul 20, 2016 at 7:42 PM, Michael Paquier wrote: >> People have, in the past, expressed concerns about linking in >> pgcrypto. Apparently, in some countries, it's a legal problem. > > Do you have any references? I don't see that as a problem. I don't have a

[HACKERS] freeze map open item

The open items list says this: heap_update sets xmax and infomask without logging the changes or clearing PD_ALL_VISIBLE or visibility map bits * volunteer owner wanted * This has been buggy essentially forever but the freeze map changes give it new urgency. * Andres working on committing patches

[HACKERS] Re: [COMMITTERS] pgsql: Avoid extra locks in GetSnapshotData if old_snapshot_threshold

On Wed, Jul 20, 2016 at 9:15 PM, Noah Misch wrote: > This PostgreSQL 9.6 open item now needs a permanent owner. Would any other > committer like to take ownership? If this role interests you, please read > this thread and the policy linked above, then send an initial status

Re: [HACKERS] RecoveryTargetTLI dead variable in XLogCtlData

On Tue, Jul 12, 2016 at 11:29 PM, Michael Paquier wrote: > Hi all, > > I just bumped into $subject, a variable that is never set and never used: > --- a/src/backend/access/transam/xlog.c > +++ b/src/backend/access/transam/xlog.c > @@ -631,8 +631,6 @@ typedef struct

[HACKERS] fixes for the Danish locale

In Danish, the sequence 'aa' is sometimes treated as a single letter which collates after 'z'. Some regression tests got into 9.5, and are still in 9.6beta3, which fail due to assuming they know how things will sort or compare. I thought the easiest way to deal with it was just to change the

Re: [HACKERS] Constraint merge and not valid status

On Wed, Jul 13, 2016 at 5:22 AM, Amit Langote wrote: > Consider a scenario where one adds a *valid* constraint on a inheritance > parent which is then merged with a child table's *not valid* constraint > during inheritance recursion. If merged, the constraint is

Re: [HACKERS] PoC: Make it possible to disallow WHERE-less UPDATE and DELETE

Please find attached a patch which makes it possible to disallow UPDATEs and DELETEs which lack a WHERE clause. As this changes query behavior, I've made the new GUCs PGC_SUSET. What say? DELETE FROM tbl WHERE true; ? -- Teodor Sigaev E-mail:

Re: [HACKERS] PoC: Make it possible to disallow WHERE-less UPDATE and DELETE

On 07/21/2016 06:49 AM, Tom Lane wrote: David Fetter writes: Please find attached a patch which makes it possible to disallow UPDATEs and DELETEs which lack a WHERE clause. As this changes query behavior, I've made the new GUCs PGC_SUSET. What say? -1 -1. This is

Re: [HACKERS] PoC: Make it possible to disallow WHERE-less UPDATE and DELETE

David Fetter writes: > Please find attached a patch which makes it possible to disallow > UPDATEs and DELETEs which lack a WHERE clause. As this changes query > behavior, I've made the new GUCs PGC_SUSET. > What say? -1. This is an express violation of the SQL standard, and

Re: [HACKERS] Unexpected memory usage for repeated inserts within plpgsql function

On Thu, Jul 21, 2016 at 4:09 PM, happy times wrote: > My question: Is this problem as-designed? > Actually problem is in exec_stmt_dynexecute function, We make a copy of the query string, and before we free it, it thow an error from SPI_execute (because table does not

Re: [HACKERS] [BUG] pg_basebackup from disconnected standby fails

On Thu, Jul 21, 2016 at 5:19 PM, Kyotaro HORIGUCHI wrote: > + * minRecoveryPoint can go behind the last checkpoint's redo location when > + * the checkpoint writes out no buffer. This does no harm to performing a > + * recovery but such inversion seems

Re: [HACKERS] PoC: Make it possible to disallow WHERE-less UPDATE and DELETE

On 21 July 2016 at 15:49, Amit Kapila wrote: > On Thu, Jul 21, 2016 at 10:27 AM, David Fetter wrote: > > Folks, > > > > Please find attached a patch which makes it possible to disallow > > UPDATEs and DELETEs which lack a WHERE clause. As this changes

Re: [HACKERS] PoC: Make it possible to disallow WHERE-less UPDATE and DELETE

On Thu, Jul 21, 2016 at 12:57 AM, David Fetter wrote: > Folks, > > Please find attached a patch which makes it possible to disallow > UPDATEs and DELETEs which lack a WHERE clause. As this changes query > behavior, I've made the new GUCs PGC_SUSET. > > What say? > > Can't you

Re: [HACKERS] [BUG] pg_basebackup from disconnected standby fails

Hello, At Mon, 11 Jul 2016 16:47:53 +0900, Michael Paquier wrote in

Re: [HACKERS] [BUG] pg_basebackup from disconnected standby fails

Sorry for the absense. I've reached here. At Thu, 21 Jul 2016 12:20:30 +0900, Michael Paquier wrote in > On Thu, Jul 21, 2016 at 11:56 AM, Amit Kapila wrote: > > On Thu, Jul

Re: [HACKERS] PoC: Make it possible to disallow WHERE-less UPDATE and DELETE

On Thu, Jul 21, 2016 at 10:27 AM, David Fetter wrote: > Folks, > > Please find attached a patch which makes it possible to disallow > UPDATEs and DELETEs which lack a WHERE clause. As this changes query > behavior, I've made the new GUCs PGC_SUSET. > > What say? > The use case

Re: [HACKERS] Oddity in handling of cached plans for FDW queries

On 2016/07/16 6:25, Tom Lane wrote: Pushed, after fooling around with it some more so that it would cover the case we discussed where the join could be allowed if we restrict the plan to be executed by the owner of a view used in the query. I left that for future work, but I'm happy to have