Re: auxiliary processes in pg_stat_ssl

2019-11-04 Thread Kuntal Ghosh
On Mon, Nov 4, 2019 at 9:09 PM Euler Taveira wrote: > > > > But this seems pointless. Should we not hide those? Seems this only > > happened as an unintended side-effect of fc70a4b0df38. It appears to me > > that we should redefine that view to restrict backend_type that's > > 'client backend'

Re: v12.0: ERROR: could not find pathkey item to sort

2019-11-04 Thread Amit Langote
On Sun, Nov 3, 2019 at 4:43 AM Tom Lane wrote: > Amit Langote writes: > >> This would > >> probably require refactoring things so that there are separate > >> entry points to add child equivalences for base rels and join rels. > >> But that seems cleaner anyway than what you've got here. > > > Se

Re: PATCH: logical_work_mem and logical streaming of large in-progress transactions

2019-11-04 Thread Dilip Kumar
On Mon, Nov 4, 2019 at 5:22 PM Amit Kapila wrote: > > On Wed, Oct 30, 2019 at 9:38 AM vignesh C wrote: > > > > On Tue, Oct 22, 2019 at 10:52 PM Tomas Vondra > > wrote: > > > > > > I think the patch should do the simplest thing possible, i.e. what it > > > does today. Otherwise we'll never get it

Re: The command tag of "ALTER MATERIALIZED VIEW RENAME COLUMN"

2019-11-04 Thread Fujii Masao
On Sat, Nov 2, 2019 at 4:40 PM Michael Paquier wrote: > > On Fri, Nov 01, 2019 at 02:17:03PM +0500, Ibrar Ahmed wrote: > > Do we really need a regression test cases for such small oversights? > > It is possible to get the command tags using an event trigger... But > that sounds hack-ish. Yes, so

Re: cost based vacuum (parallel)

2019-11-04 Thread Amit Kapila
On Mon, Nov 4, 2019 at 11:42 PM Andres Freund wrote: > > > > The two approaches to solve this problem being discussed in that > > thread [1] are as follows: > > (a) Allow the parallel workers and master backend to have a shared > > view of vacuum cost related parameters (mainly VacuumCostBalance)

Re: Resume vacuum and autovacuum from interruption and cancellation

2019-11-04 Thread Masahiko Sawada
On Sat, 2 Nov 2019 at 02:10, Robert Haas wrote: > > On Thu, Aug 8, 2019 at 9:42 AM Rafia Sabih wrote: > > Sounds like an interesting idea, but does it really help? Because if > > vacuum was interrupted previously, wouldn't it already know the dead > > tuples, etc in the next run quite quickly, as

Re: [proposal] recovery_target "latest"

2019-11-04 Thread Kyotaro Horiguchi
Hello. At Mon, 4 Nov 2019 16:03:38 +0300, Grigory Smolkin wrote in > Hello, hackers! > > I`d like to propose a new argument for recovery_target parameter, > which will stand to recovering until all available WAL segments are > applied. > > Current PostgreSQL recovery default behavior(when no

<    1   2