Re: [HACKERS] New SQL counter statistics view (pg_stat_sql)

>Andres Freund writes: >> On 2016-08-22 13:54:43 -0400, Robert Haas wrote: >> On Sat, Aug 20, 2016 at 11:17 AM, Tom Lane wrote: I'm inclined to suggest you forget this approach and propose a single counter for "SQL commands executed", which avoids all of the above definitional prob

Re: [HACKERS] New SQL counter statistics view (pg_stat_sql)

On Wed, Aug 24, 2016 at 10:07 AM, Gavin Flower < gavinflo...@archidevsys.co.nz> wrote: > On 24/08/16 12:02, neha khatri wrote: > >> >Andres Freund mailto:and...@anarazel.de>> writes: >> >> On 2016-08-22 13:54:43 -0400, Robert Haas wrote: >> >

Re: [HACKERS] RFC: replace pg_stat_activity.waiting with something more descriptive

Hello, I noticed that a small optimization is possible in the flow of wait stat reporting for the LWLocks, when the pgstat_track_activities is disabled. If the check for pgstat_track_activities is done before invoking LWLockReportWaitStart() instead of inside the pgstat_report_wait_start(), it ca

Re: [HACKERS] Unsafe use of relation->rd_options without checking its type

> > > ^ > > The reason for the error is that transformOnConflictArbiter applies > RelationIsUsedAsCatalogTable() to something that it doesn't know to > be a plain relation --- it's a view in this case. And that macro > blindly assumes th

[HACKERS] Resolved typo in a comment

Hi, Attached is a patch that fixes a comment typo in varlena.c Thanks, Neha typo_correction.patch Description: Binary data -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] [PATCH] SortSupport for macaddr type

Hi Brandur, Couple of typo corrections required in patch: s/converstion/conversion s/go the heap/go to the heap The performance results you shared are for he Index Creation operation. Are there similar results for the sorting using ORDER BY queries too? Just curious. Regards, Neha

Re: [HACKERS] [NOVICE] opr_charset rule in gram.y

On Tue, Mar 7, 2017 at 4:30 PM, Tom Lane wrote: > Neha Khatri writes: > > I was going through the grammer rule for Character types in gram.y and > > found an optional sub rule in is "opt_charset" > > This question seems quite off-topic for pgsql-novice, so I'

Re: [HACKERS] [NOVICE] opr_charset rule in gram.y

I see it is already addressed in master. Thanks. Regards, Neha

Re: [HACKERS] bytea_output vs make installcheck

On Fri, Mar 10, 2017 at 6:14 AM, Peter Eisentraut wrote: > On 2/14/17 16:50, Jeff Janes wrote: > > make installcheck currently fails against a server running > > with bytea_output = escape. > > > > Making it succeed is fairly easy, and I think it is worth doing. > > > > Attached are two options f

Re: [HACKERS] [NOVICE] Why is there a doubtful copyObject call in add_vars_to_targetlist

On Mon, Mar 13, 2017 at 3:52 PM, Tom Lane wrote: > David Rowley writes: > > On 13 March 2017 at 14:22, Neha Khatri wrote: > >> This copyObject still exits in the current code. So I was wondering if > the > >> comment question still holds good and why the q

Re: [HACKERS] [NOVICE] Why is there a doubtful copyObject call in add_vars_to_targetlist

Sure, understood. Regards, Neha

Re: [HACKERS] strange parallel query behavior after OOM crashes

On Fri, Mar 31, 2017 at 8:29 AM, Kuntal Ghosh wrote: > On Fri, Mar 31, 2017 at 2:05 AM, Kuntal Ghosh > wrote: > > > > 1. Put an Assert(0) in ParallelQueryMain(), start server and execute > > any parallel query. > > In LaunchParallelWorkers, you can see > >nworkers = n nworkers_launched

Re: [HACKERS] strange parallel query behavior after OOM crashes

Looking further in this context, number of active parallel workers is: parallel_register_count - parallel_terminate_count Can active workers ever be greater than max_parallel_workers, I think no. Then why should there be greater than check in the following condition: if (parallel && (Back

Re: [HACKERS] strange parallel query behavior after OOM crashes

On Wed, Apr 5, 2017 at 5:34 PM, Kuntal Ghosh wrote: > On Tue, Apr 4, 2017 at 12:16 PM, Neha Khatri > wrote: > > > I feel there should be an assert if > > (BackgroundWorkerData->parallel_register_count - > > BackgroundWorkerData->parallel_termin

Re: [HACKERS] strange parallel query behavior after OOM crashes

On Tue, Apr 11, 2017 at 1:16 AM, Robert Haas wrote: > > 1. Forget BGW_NEVER_RESTART workers in > ResetBackgroundWorkerCrashTimes() rather than leaving them around to > be cleaned up after the conclusion of the restart, so that they go > away before rather than after shared memory is reset. Now

Re: [HACKERS] tablesync patch broke the assumption that logical rep depends on?

On Thu, Apr 27, 2017 at 4:01 AM, Tom Lane wrote: > Jeff Janes writes: > > This gives me compiler warning: > > launcher.c: In function 'logicalrep_worker_launch': > > launcher.c:257: warning: 'slot' may be used uninitialized in this > function > > Yeah, me too. Fix pushed. Somewhat off the mar

[HACKERS] Description of create_singleton_array()

Is it intentional to have the existing $SUBJECT. The commit 33f43725 updated the function text_to_array() such that it does not directly invoke create_singlet

Re: [HACKERS] Description of create_singleton_array()

On Tue, May 2, 2017 at 5:47 AM, Tom Lane wrote: > > > Well, now that we've been burnt once by the specific call site moving, > I think we should learn from experience and not have this say where > it's called from. That's a lousy substitute for defining the API > expectations explicitly, anyway.

Re: [HACKERS] Duplicate usage of tablespace location?

As Kyotaro san pointed out, the commit 22817041 started allowing creation of multiple "tablespace version directories" in same location. However the original purpose of that commit was to allow that just for the upgrade purpose. So couple of points: - The commit violated the requirement of emptines

Re: [HACKERS] Should pg_current_wal_location() become pg_current_wal_lsn()

On Sat, May 6, 2017 at 4:09 PM, Tom Lane wrote: > Noah Misch writes: > > On Fri, May 05, 2017 at 03:36:39AM +1200, David Rowley wrote: > >> Do any of the committers who voted for this change feel inclined to > >> pick this patch up? > > > I'll echo that question. This open item lacks a clear ow

Re: [HACKERS] Should pg_current_wal_location() become pg_current_wal_lsn()

On Fri, May 12, 2017 at 12:56 AM, Tom Lane wrote: > Neha Khatri writes: > > [In case forgotten] pg_controdata and pg_waldump interfaces should also > be > > considered for this standardization. > > > Following are pg_controldata interfaces that might require change

Re: [HACKERS] Time based lag tracking for logical replication

On Fri, May 12, 2017 at 8:19 PM, Simon Riggs wrote: > > On 11 May 2017 at 18:29, Simon Riggs wrote: > > On 11 May 2017 at 18:13, Andres Freund wrote: > > > >>>New patch, v3. > >>> > >>>Applying in 90 minutes, barring objections. > >> > >> Could you please wait till tomorrow?  I've bigger pending

Re: [HACKERS] If subscription to foreign table valid ?

On 5/11/17, Petr Jelinek wrote: > Hi, > > On 11/05/17 14:25, tushar wrote: >> Hi, >> >> I observed that -we cannot publish "foreign table" in Publication >> >> but same thing is not true for Subscription >> >> postgres=# create foreign table t (n int) server db1_server options >> (table_name 't');

Re: [HACKERS] If subscription to foreign table valid ?

[Correction below] On 5/12/17, Neha Khatri wrote: > On 5/11/17, Petr Jelinek wrote > >> However, the foreign tables indeed can't be subscribed. Yes, I suspect that a user would _not_ want to subcribe a foreign table in real world. -- Sent via pgsql-hackers mailing li

Re: [HACKERS] Time based lag tracking for logical replication

On Sat, May 13, 2017 at 12:04 AM, Petr Jelinek wrote: > > After this commit 024711bb544645c8b1061e9f02b261e2e336981d I get > > following error while executing CREATE SUBSCRIPTION: > > > > CREATE SUBSCRIPTION sub1 CONNECTION 'dbname=postgres host=localhost > > user=neha port=5432' PUBLICATION mypu

Re: [HACKERS] If subscription to foreign table valid ?

> > > > I sent my version of patch in parallel. I think we don't need to do the > relation open like you did, all the info is in syscache. > That's right. > Regards, Neha

Re: [HACKERS] If subscription to foreign table valid ?

On Fri, May 12, 2017 at 11:58 PM, Petr Jelinek wrote: > On 11/05/17 15:43, Petr Jelinek wrote: > > Hi, > > > > > We do check for this, but only during replication which we have to do > > because the fact that relation 't' was foreign table during ALTER > > SUBSCRIPTION does not mean that it won't

[HACKERS] Incorrect mention of pg_xlog_switch() in xlogfuncs.c

While reading some code, noticed that the headers of functions pg_walfile_name_offset() and pg_walfile_name() incorrecty refer pg_xlog_switch() since the inception of code in commit 704ddaaa. In PG10 implementation, actual name of the referred function is pg_switch_wal(). So either refer the corre

[HACKERS] wal_level > WAL_LEVEL_LOGICAL

As per my understabding, current postgres server supports only three values for wal_level i.e. 'minimal' , 'replica' or 'logical'. But following error message brought to notice that there are various code spots that try to look for wal_level >= WAL_LEVEL_LOGICAL: select * from pg_create_logical_

[HACKERS] Improve logical decoding error message (was wal_level > WAL_LEVEL_LOGICAL)

On Mon, May 22, 2017 at 11:08 PM, Neha Khatri wrote: > As per my understabding, current postgres server supports only three > values for wal_level i.e. 'minimal' , 'replica' or 'logical'. But > following error message brought to notice that there are va

Re: [HACKERS] Improve logical decoding error message (was wal_level > WAL_LEVEL_LOGICAL)

On Tue, May 23, 2017 at 10:26 AM, Michael Paquier wrote: > On Tue, May 23, 2017 at 8:08 AM, Neha Khatri > wrote: > > The Logical Decoding example in the documentation says: > > > > "Before you can use logical decoding, you must set wal_level to logical > &

Re: [HACKERS] Improve logical decoding error message (was wal_level > WAL_LEVEL_LOGICAL)

On Tue, 23 May 2017 at 10:55 am, Alvaro Herrera wrote: > Neha Khatri wrote: > > On Tue, May 23, 2017 at 10:26 AM, Michael Paquier < > michael.paqu...@gmail.com > > > > There is no wal_level higher than logical, so the current sense looks > > > perfectl

Re: [HACKERS] wal_level > WAL_LEVEL_LOGICAL

On Wed, 24 May 2017 at 10:29 pm, Robert Haas wrote: > On Mon, May 22, 2017 at 9:08 AM, Neha Khatri > wrote: > > As per my understabding, current postgres server supports only three > > values for wal_level i.e. 'minimal' , 'replica' or 'logical&#

[HACKERS] Typo in xlogfuncs.c [WAS Re: Incorrect mention of pg_xlog_switch() in xlogfuncs.c]

Simplifying $subject. There are typos in xlogfuncs.c. So Either s/pg_xlog_switch/pg_switch_wal Or Remove "pg_xlog_switch" from the comments. Attached patches both ways. Regards, Neha On Sat, May 20, 2017 at 1:08 AM, Neha Khatri wrote: > While reading some code, noticed that t

Re: [HACKERS] PG 10 release notes

On Mon, May 15, 2017 at 12:45 PM, Bruce Momjian wrote: > On Thu, May 11, 2017 at 11:50:03PM -0400, Tom Lane wrote: > > Michael Paquier writes: > > > Bruce, the release notes do not mention yet that support for cleartext > > > passwords is removed. This has been done recently by Heikki in > > > e

Re: [HACKERS] Does pg_upgrade really support "make installcheck"?

On 6/7/17, Tom Lane wrote: > src/bin/pg_upgrade/TESTING claims (much further down in the file > than I'd like): > > The shell script test.sh in this directory performs more or less this > procedure. You can invoke it by running > make check > or by running >

Re: [HACKERS] bytea_output vs make installcheck

On Wed, Feb 15, 2017 at 8:50 AM, Jeff Janes wrote: > make installcheck currently fails against a server running > with bytea_output = escape. > > Making it succeed is fairly easy, and I think it is worth doing. > > Attached are two options for doing that. One overrides bytea_output > locally whe

Re: [HACKERS] bytea_output vs make installcheck

On Wed, Feb 15, 2017 at 10:04 AM, neha khatri wrote:. > > >> Attached are two options for doing that. One overrides bytea_output >> locally where-ever needed, and the other overrides it for the entire >> 'regression' database. >> > > The solu

Re: [HACKERS] bytea_output vs make installcheck

Agreed with Jeff, false alarms should be avoided, whenever it is easy to put the avoiding mechanism in place. Regards, Neha