Re: [HACKERS] application_name in process name?

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

Re: [HACKERS] Constraint merge and not valid status

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

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

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

[HACKERS] plperl loading files

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

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

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

Re: [HACKERS] GiST index build versus NaN coordinates

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

Re: [HACKERS] Reviewing freeze map code

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

Re: [HACKERS] Reviewing freeze map code

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, >

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

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 >>

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

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

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

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

Re: [HACKERS] GiST index build versus NaN coordinates

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

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

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

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: >> >> *

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

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 >

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

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

Re: [HACKERS] Reviewing freeze map code

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)) && >> > +

Re: [HACKERS] raw output from copy

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