Re: [HACKERS] Assert(LWLockHeldByMeInMode(lock, LW_EXCLUSIVE))

On Mon, Jun 20, 2016 at 3:43 PM, Craig Ringer wrote: > On 18 June 2016 at 11:28, Thomas Munro > wrote: >> Several times now when reading, debugging and writing code I've wished >> that LWLockHeldByMe assertions specified the expected mode,

Re: [HACKERS] Experimental dynamic memory allocation of postgresql shared memory

On Mon, Jun 20, 2016 at 12:40 PM, Craig Ringer wrote: > On 18 June 2016 at 02:42, Robert Haas wrote: >> >> On Fri, Jun 17, 2016 at 2:23 PM, Aleksey Demakov >> wrote: >> > Essentially this is pessimizing for the lowest common

Re: [HACKERS] Assert(LWLockHeldByMeInMode(lock, LW_EXCLUSIVE))

On 18 June 2016 at 11:28, Thomas Munro wrote: > Hi hackers, > > Several times now when reading, debugging and writing code I've wished > that LWLockHeldByMe assertions specified the expected mode, especially > where exclusive locking is required. > > What do you

Re: [HACKERS] Experimental dynamic memory allocation of postgresql shared memory

On 18 June 2016 at 02:42, Robert Haas wrote: > On Fri, Jun 17, 2016 at 2:23 PM, Aleksey Demakov > wrote: > > Essentially this is pessimizing for the lowest common denominator > > among OSes. > > I totally agree. That's how we make the server portable.

Re: [HACKERS] parallel.c is not marked as test covered

Robert Haas writes: > On Sun, Jun 19, 2016 at 5:22 PM, Peter Eisentraut > wrote: >> Well, the purpose of the test is to check the error passing between worker >> and leader. If we just silently revert to not doing that, then we can't >>

Re: [HACKERS] Parallel safety tagging of extension functions

Robert Haas writes: > On Sun, Jun 19, 2016 at 4:21 PM, Andreas Karlsson wrote: >> Here they are. Shelve them if you like. They are some of the least important >> extensions that still should be fixed so they can end up in 10 if you do not >> find the

Re: [HACKERS] parallel.c is not marked as test covered

On Sun, Jun 19, 2016 at 5:22 PM, Peter Eisentraut wrote: > Well, the purpose of the test is to check the error passing between worker > and leader. If we just silently revert to not doing that, then we can't > really be sure that we're testing the right thing.

Re: [HACKERS] Parallel safety tagging of extension functions

On Sun, Jun 19, 2016 at 4:21 PM, Andreas Karlsson wrote: > On 06/17/2016 09:11 PM, Robert Haas wrote: >> I was kind of hoping you'd have a new version of this posted already. >> beta2 is wrapping on Monday, and I'm inclined to shelve anything that >> isn't done by then for the

Re: [HACKERS] parallel.c is not marked as test covered

Peter Eisentraut writes: > On 6/19/16 3:09 PM, Robert Haas wrote: >> On Sun, Jun 19, 2016 at 11:36 AM, Tom Lane wrote: >>> No, it *might* execute in a worker. If you can get one. >> Right. > Well, the purpose of the test is to check the

Re: [HACKERS] parallel.c is not marked as test covered

On 6/19/16 3:09 PM, Robert Haas wrote: On Sun, Jun 19, 2016 at 11:36 AM, Tom Lane wrote: Amit Kapila writes: On Sun, Jun 19, 2016 at 10:10 AM, Tom Lane wrote: Would this not result in unstable test output depending on whether

Re: [HACKERS] Parallel safety tagging of extension functions

On 06/17/2016 09:11 PM, Robert Haas wrote: I was kind of hoping you'd have a new version of this posted already. beta2 is wrapping on Monday, and I'm inclined to shelve anything that isn't done by then for the next release. And I don't really plan to work much this weekend. Here they are.

Re: [HACKERS] parallel.c is not marked as test covered

On Sun, Jun 19, 2016 at 11:36 AM, Tom Lane wrote: > Amit Kapila writes: >> On Sun, Jun 19, 2016 at 10:10 AM, Tom Lane wrote: >>> Would this not result in unstable test output depending on whether the >>> code executes in the

Re: [HACKERS] Re: [BUGS] BUG #14199: The pg_ctl status check on server start is not compatible with the silent_mode=on

Michael Paquier writes: > On Sun, Jun 19, 2016 at 12:51 AM, Tom Lane wrote: >> What seems like a more conservative answer to me is to revert c869a7d5b >> in 9.1 only, and address the buildfarm stability issue it sought to >> resolve by increasing

Re: [HACKERS] parallel.c is not marked as test covered

Amit Kapila writes: > On Sun, Jun 19, 2016 at 10:10 AM, Tom Lane wrote: >> Would this not result in unstable test output depending on whether the >> code executes in the leader or a worker? > Before doing that test, we set force_parallel_mode=1, so

Re: [HACKERS] primary_conninfo missing from pg_stat_wal_receiver

On Sun, Jun 19, 2016 at 7:38 PM, Vik Fearing wrote: > On 19/06/16 12:28, Michael Paquier wrote: >> On Sun, Jun 19, 2016 at 5:56 PM, Michael Paquier >> Or in short the attached. > > The code looks good to me but why no documentation? Because that's a long day... Thanks! Now

Re: [HACKERS] Whether to back-patch fix for aggregate transtype width estimates

On 06/18/2016 06:14 PM, Tom Lane wrote: Robert Haas writes: On Fri, Jun 17, 2016 at 10:41 PM, Tom Lane wrote: Ordinarily I'd just summarily back-patch a fix, but that commit shipped in 9.0, which means it's been broken a long time. I'm worried that

[HACKERS] Re: [BUGS] BUG #14199: The pg_ctl status check on server start is not compatible with the silent_mode=on

On Sun, Jun 19, 2016 at 12:51 AM, Tom Lane wrote: > What seems like a more conservative answer to me is to revert c869a7d5b > in 9.1 only, and address the buildfarm stability issue it sought to > resolve by increasing the fixed timeout from 5 seconds to, say, 10. +1 for doing

Re: [HACKERS] New design for FK-based join selectivity estimation

Hi On 06/18/2016 06:52 PM, Tom Lane wrote: Tomas Vondra writes: A few more comments, about re-reading the patch more thoroughly. I wouldn't say any of those qualify as bugs, but rather as discussion about some of the design choices: 1) NULL handling I'd

Re: [HACKERS] primary_conninfo missing from pg_stat_wal_receiver

On 19/06/16 12:28, Michael Paquier wrote: > On Sun, Jun 19, 2016 at 5:56 PM, Michael Paquier > wrote: >> The new pg_stat_wal_receiver does not include primary_conninfo. >> Looking at that now, it looks almost stupid not to include it... >> Adding it now would require a

Re: [HACKERS] primary_conninfo missing from pg_stat_wal_receiver

On Sun, Jun 19, 2016 at 5:56 PM, Michael Paquier wrote: > The new pg_stat_wal_receiver does not include primary_conninfo. > Looking at that now, it looks almost stupid not to include it... > Adding it now would require a catalog bump, so I am not sure if this > is

[HACKERS] primary_conninfo missing from pg_stat_wal_receiver

Hi all, The new pg_stat_wal_receiver does not include primary_conninfo. Looking at that now, it looks almost stupid not to include it... Adding it now would require a catalog bump, so I am not sure if this is acceptable at this stage for 9.6... Regards, -- Michael -- Sent via pgsql-hackers

Re: [HACKERS] parallel.c is not marked as test covered

On Sun, Jun 19, 2016 at 10:10 AM, Tom Lane wrote: > > Peter Eisentraut writes: > > With that, I think it would be preferable to undo the context-hiding > > dance in the tests, as in the attached patch, no? > > Would this not result in