Re: [HACKERS] application_name in process name?

2016-07-16 Thread Jim Nasby
On 7/13/16 12:07 PM, Tom Lane wrote: Mike Blackwell writes: There are times when it would be useful to have the application_name connection parameter displayed in the process name - and thus in ps and pg_top - in addition to the user and database name. Would there be any downside to this?

Re: [HACKERS] Constraint merge and not valid status

2016-07-16 Thread Jim Nasby
On 7/13/16 4: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 not checked for the child data even though it may ha

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

2016-07-16 Thread Noah Misch
On Wed, Jul 13, 2016 at 03:57:02PM -0500, Kevin Grittner wrote: > On Wed, Jul 13, 2016 at 12:48 PM, Andres Freund wrote: > > On 2016-07-13 10:06:52 -0500, Kevin Grittner wrote: > >> On Wed, Jul 13, 2016 at 7:57 AM, Amit Kapila > >> wrote: > >>> On Tue, Jul 12, 2016 at 8:34 PM, Kevin Grittner wr

[HACKERS] plperl loading files

2016-07-16 Thread Jeff Janes
After putting "plperl" into shared_preload_libraries so that things get loaded upon server start, I was surprised to see that each backend was still accessing a handful of perl files the first time it used a plperl function. I see that the cause is src/pl/plperl/plc_trusted.pl, which loads some mo

Re: [HACKERS] DO with a large amount of statements get stuck with high memory consumption

2016-07-16 Thread Jan Wieck
On Tue, Jul 12, 2016 at 3:29 PM, Merlin Moncure wrote: > I've noticed that pl/pgsql functions/do commands do not behave well > when the statement resolves and frees memory. To be clear: > > FOR i in 1..100 > LOOP > INSERT INTO foo VALUES (i); > END LOOP; > > ...runs just fine while > > BE

Re: [HACKERS] GiST index build versus NaN coordinates

2016-07-16 Thread Tom Lane
Andreas Seltenreich writes: > I wrote: >> Sounds like some fuzz testing with nan/infinity is in order. > related fallout: close_ps returns a NULL pointer with NaNs around: > select close_ps('(nan,nan)', '(nan,nan),(nan,nan)'); > -- TRAP: FailedAssertion("!(result != ((void *)0))", File: "geo_ops.

Re: [HACKERS] Reviewing freeze map code

2016-07-16 Thread Andres Freund
On July 16, 2016 8:49:06 AM PDT, Tom Lane wrote: >Amit Kapila writes: >> On Sat, Jul 16, 2016 at 7:02 AM, Andres Freund >wrote: >>> I think we have two choices how to deal with that: First, we can add >a >>> new flags variable to xl_heap_lock similar to >>> xl_heap_insert/update/... and bump p

Re: [HACKERS] Reviewing freeze map code

2016-07-16 Thread Tom Lane
Amit Kapila writes: > On Sat, Jul 16, 2016 at 7:02 AM, Andres Freund wrote: >> I think we have two choices how to deal with that: First, we can add a >> new flags variable to xl_heap_lock similar to >> xl_heap_insert/update/... and bump page magic, > +1 for going in this way. This will keep us

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

2016-07-16 Thread Tom Lane
Alvaro Herrera writes: > Tom Lane wrote: >> We've talked before about how the regression tests should be circumspect >> about what role names they create/drop, so as to avoid possibly blowing >> up an installation's existing users during "make installcheck". In >> particular I believe there was c

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

2016-07-16 Thread Tom Lane
Stephen Frost writes: > * Tom Lane (t...@sss.pgh.pa.us) wrote: >> One could certainly argue that these are safe enough because nobody would >> ever create real roles by those names anyway. I'm not very comfortable >> with that though; if we believe that, why did we go to the trouble of >> making

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

2016-07-16 Thread Stephen Frost
Tom, * Tom Lane (t...@sss.pgh.pa.us) wrote: > We've talked before about how the regression tests should be circumspect > about what role names they create/drop, so as to avoid possibly blowing > up an installation's existing users during "make installcheck". In > particular I believe there was co

Re: [HACKERS] GiST index build versus NaN coordinates

2016-07-16 Thread Andreas Seltenreich
I wrote: > Sounds like some fuzz testing with nan/infinity is in order. related fallout: close_ps returns a NULL pointer with NaNs around: select close_ps('(nan,nan)', '(nan,nan),(nan,nan)'); -- TRAP: FailedAssertion("!(result != ((void *)0))", File: "geo_ops.c", Line: 2860) regards, Andreas

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

2016-07-16 Thread Greg Stark
On 16 Jul 2016 12:59 pm, "Michael Paquier" wrote: > > Thanks for doing this. +1 Though I might highlight this as the kind of issue that a bug tracker would help avoid falling through the cracks and make visible to newcomers. > I am -1 for dropping the tests. We could just have a CFLAGS that ad

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

2016-07-16 Thread Amit Kapila
On Wed, Jul 13, 2016 at 8:56 AM, Michael Paquier wrote: > On Tue, Jul 12, 2016 at 12:22 PM, Amit Kapila wrote: >> I think updating minRecoveryPoint unconditionally can change it's >> purpose in some cases. Refer below comments in code: >> >> * minRecoveryPoint is updated to the latest replayed L

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

2016-07-16 Thread Michael Paquier
On Sat, Jul 16, 2016 at 7:13 AM, Tom Lane wrote: > We've talked before about how the regression tests should be circumspect > about what role names they create/drop, so as to avoid possibly blowing > up an installation's existing users during "make installcheck". In > particular I believe there w

Re: [HACKERS] visibilitymap_clear()s in vacuumlazy.c aren't WAL logged

2016-07-16 Thread Michael Paquier
On Sat, Jul 16, 2016 at 10:23 AM, Andres Freund wrote: > The $subject says it all. Am I missing something, or is that not ok? Indeed, it would be a good thing to get those sanity checks logged so as standbys get the call, or at least perform the sanity check as well on the block that the system i

Re: [HACKERS] Reviewing freeze map code

2016-07-16 Thread Amit Kapila
On Sat, Jul 16, 2016 at 7:02 AM, Andres Freund wrote: > On 2016-07-13 23:06:07 -0700, Andres Freund wrote: >> > + /* Clear only the all-frozen bit on visibility map if needed */ >> > + if (PageIsAllVisible(BufferGetPage(buffer)) && >> > + VM_ALL_FROZEN(relatio

Re: [HACKERS] raw output from copy

2016-07-16 Thread Pavel Stehule
Hi 2016-04-05 10:45 GMT+02:00 Pavel Stehule : > Hi > > here is cleaned/finished previous implementation of RAW_TEXT/RAW_BINARY > formats for COPY statements. > > The RAW with text formats means unescaped data, but with correct encoding > - input/output is realised with input/output function. RAW