Re: [HACKERS] Bug in to_timestamp().

Hi Artur Zakirov, 0001-to-timestamp-format-checking-v3.patch looks pretty reasonable to me, other than following concern: #1. Whitespace @ line # 317. #2. Warning at compilation; formatting.c: In function ‘do_to_timestamp’: formatting.c:3049:37: warning: ‘prev_type’ may be used uninitialized

Re: [HACKERS] pg_stat_lwlock wait time view

2016-08-25 13:46 GMT+09:00 Haribabu Kommi : > On Thu, Aug 25, 2016 at 6:57 AM, Robert Haas wrote: >> On Wed, Aug 24, 2016 at 4:23 AM, Haribabu Kommi >> wrote: >>> >>> Based on the performance impact with the additional

Re: [HACKERS] gettimeofday is at the end of its usefulness?

On Thu, Jun 9, 2016 at 12:56 AM, Tom Lane wrote: > Thom Brown writes: >> On 15 May 2014 at 19:56, Bruce Momjian wrote: >>> On Tue, May 13, 2014 at 06:58:11PM -0400, Tom Lane wrote: A recent question from Tim Kane prompted me to measure

Re: [HACKERS] increasing the default WAL segment size

Hello hackers, I'm no PG hacker, so maybe I'm completely wrong, so sorry if I have wasted your time. I try to make the best out of Tom Lanes comment. What would happen if there's a database on a server with initdb (or whatever) parameter -with-wal-size=64MB and later someone decides to make it

Re: [HACKERS] Stopping logical replication protocol

On 25 August 2016 at 09:22, Craig Ringer wrote: > On 25 August 2016 at 03:26, Vladimir Gordiychuk wrote: >> Hi. It has already passed a few months but patch still have required review >> state. Can I help to speed up the review, or should i wait

Re: [HACKERS] pg_stat_lwlock wait time view

On Thu, Aug 25, 2016 at 6:57 AM, Robert Haas wrote: > On Wed, Aug 24, 2016 at 4:23 AM, Haribabu Kommi > wrote: >> >> Based on the performance impact with the additional timing calculations, >> we can decide the view default behavior, Are there any

Re: [HACKERS] increasing the default WAL segment size

On Thu, Aug 25, 2016 at 12:35 AM, Andres Freund wrote: > FWIW, I'm also doubtful that investing time into making this initdb > configurable is a good use of time: The number of users that'll adjust > initdb time parameters is going to be fairly small. I have to admit that I

Re: [HACKERS] increasing the default WAL segment size

On 2016-08-25 00:28:58 -0400, Robert Haas wrote: > On Wed, Aug 24, 2016 at 11:52 PM, Andres Freund wrote: > > On 2016-08-24 23:26:51 -0400, Robert Haas wrote: > >> On Wed, Aug 24, 2016 at 10:54 PM, Andres Freund wrote: > >> > and I'm also rather doubtful

Re: [HACKERS] increasing the default WAL segment size

On Wed, Aug 24, 2016 at 11:52 PM, Andres Freund wrote: > On 2016-08-24 23:26:51 -0400, Robert Haas wrote: >> On Wed, Aug 24, 2016 at 10:54 PM, Andres Freund wrote: >> > and I'm also rather doubtful that it's actually without overhead. >> >> Really? Where

Re: [HACKERS] increasing the default WAL segment size

On Wed, Aug 24, 2016 at 11:41 PM, Tom Lane wrote: > Robert Haas writes: >> What am I missing? > > Maybe nothing. But I'll point out that of the things that can currently > be configured at initdb time, such as LC_COLLATE, there is not one single > one

Re: [HACKERS] Write Ahead Logging for Hash Indexes

On Wed, Aug 24, 2016 at 11:46 PM, Alvaro Herrera wrote: > Amit Kapila wrote: >> $SUBJECT will make hash indexes reliable and usable on standby. > > Nice work. > > Can you split the new xlog-related stuff to a new file, say hash_xlog.h, > instead of cramming it in hash.h?

Re: [HACKERS] increasing the default WAL segment size

On 2016-08-24 23:26:51 -0400, Robert Haas wrote: > On Wed, Aug 24, 2016 at 10:54 PM, Andres Freund wrote: > > and I'm also rather doubtful that it's actually without overhead. > > Really? Where do you think the overhead would come from? ATM we do a math involving

Re: [HACKERS] increasing the default WAL segment size

Robert Haas writes: > What am I missing? Maybe nothing. But I'll point out that of the things that can currently be configured at initdb time, such as LC_COLLATE, there is not one single one that matters to walsender/walreceiver. If you think there is zero risk involved

Re: [HACKERS] patch proposal

On Thu, Aug 18, 2016 at 3:37 PM, Michael Paquier wrote: > On Tue, Aug 16, 2016 at 11:06 PM, Stephen Frost > wrote: > > I could see supporting an additional "pause" option that means "pause at > > the end of WAL if you don't reach the recovery

Re: [HACKERS] increasing the default WAL segment size

Robert Haas writes: > On Wed, Aug 24, 2016 at 10:33 PM, Tom Lane wrote: >> ... but I think this is just folly. You'd have to do major amounts >> of work to keep, eg, slave servers on the same page as the master >> about what the segment size is. > I

Re: [HACKERS] increasing the default WAL segment size

On Wed, Aug 24, 2016 at 11:02 PM, Tom Lane wrote: > Andres Freund writes: >> On 2016-08-24 22:33:49 -0400, Tom Lane wrote: >>> ... but I think this is just folly. You'd have to do major amounts >>> of work to keep, eg, slave servers on the same page as

Re: [HACKERS] \timing interval

On Wed, Aug 24, 2016 at 10:36 PM, Gerdan Santos wrote: > The following review has been posted through the commitfest application: > make installcheck-world: tested, passed > Implements feature: tested, passed > Spec compliant: tested, passed > Documentation:

Re: [HACKERS] increasing the default WAL segment size

On Wed, Aug 24, 2016 at 10:54 PM, Andres Freund wrote: > On 2016-08-24 22:33:49 -0400, Tom Lane wrote: >> > Possibly it would make sense for this to be configurable at initdb >> > time instead of requiring a recompile; >> >> ... but I think this is just folly. You'd have to

Re: [HACKERS] increasing the default WAL segment size

On Wed, Aug 24, 2016 at 10:33 PM, Tom Lane wrote: > ... but I think this is just folly. You'd have to do major amounts > of work to keep, eg, slave servers on the same page as the master > about what the segment size is. I said an initdb-time parameter, meaning not capable

Re: [HACKERS] increasing the default WAL segment size

Andres Freund writes: > On 2016-08-24 22:33:49 -0400, Tom Lane wrote: >> ... but I think this is just folly. You'd have to do major amounts >> of work to keep, eg, slave servers on the same page as the master >> about what the segment size is. > Don't think it'd actually be

Re: [HACKERS] increasing the default WAL segment size

On 2016-08-24 22:33:49 -0400, Tom Lane wrote: > > Possibly it would make sense for this to be configurable at initdb > > time instead of requiring a recompile; > > ... but I think this is just folly. You'd have to do major amounts > of work to keep, eg, slave servers on the same page as the

Re: [HACKERS] increasing the default WAL segment size

> From: pgsql-hackers-ow...@postgresql.org > [mailto:pgsql-hackers-ow...@postgresql.org] On Behalf Of Robert Haas > Considering those three factors, I think we should consider pushing the > default value up somewhat higher for v10. Reverting to the 64MB size that > we had prior to

Re: [HACKERS] \timing interval

The following review has been posted through the commitfest application: make installcheck-world: tested, passed Implements feature: tested, passed Spec compliant: tested, passed Documentation:tested, passed Sorry, my mistake! I could not find a way to disable this

Re: [HACKERS] increasing the default WAL segment size

Robert Haas writes: > I'd like to propose that we increase the default WAL segment size, > which is currently 16MB. That seems like a reasonable thing to consider ... > Possibly it would make sense for this to be configurable at initdb > time instead of requiring a

Re: [HACKERS] \timing interval

The following review has been posted through the commitfest application: make installcheck-world: tested, failed Implements feature: tested, failed Spec compliant: tested, failed Documentation:tested, failed I could not find a way to disable this functionality , I see

Re: [HACKERS] increasing the default WAL segment size

On Wed, Aug 24, 2016 at 10:31 PM, Robert Haas wrote: > 1. Transaction rates are vastly higher these days. In 1999, I think > we were still limited to ~2^32 transactions during the entire lifetime > of the server; transaction ID wraparound hadn't been invented yet.[1] >

[HACKERS] increasing the default WAL segment size

Hi, I'd like to propose that we increase the default WAL segment size, which is currently 16MB. It was first set to that value in commit 47937403676d913c0e740eec6b85113865c6c8ab in October of 1999; prior to that, it was 64MB. Between 1999 and now, there have been three significant changes that

Re: [HACKERS] Better tracking of free space during SP-GiST index build

On 08/25/2016 01:45 AM, Tom Lane wrote: Over in the thread about the SP-GiST inet opclass, I threatened to post a patch like this, and here it is. The basic idea is to track more than just the very latest page we've used in each of the page categories that SP-GiST works with. I started with

Re: [HACKERS] How to do failover in pglogical replication?

On 24 August 2016 at 19:42, roshan_myrepublic wrote: > Now, I am able to see the last added row in my subscriber table. All the > other 4 rows which were added in the beginning are still missing. What am I > doing wrong here? Hi. This isn't really on topic for the

Re: [HACKERS] pg_dump with tables created in schemas created by extensions

2016-08-24 21:34 GMT-03:00 Michael Paquier : > > Yes, you are right. If I look at the diffs this morning I am seeing > the ACLs being dumped for this aggregate. So we could just fix the > test and be done with it. I did not imagine the index issue though, > and this is

Re: [HACKERS] Stopping logical replication protocol

On 25 August 2016 at 03:26, Vladimir Gordiychuk wrote: > Hi. It has already passed a few months but patch still have required review > state. Can I help to speed up the review, or should i wait commitfest? > I plane complete changes in pgjdbc drive inside PR >

Re: [HACKERS] pg_dump with tables created in schemas created by extensions

On Wed, Aug 24, 2016 at 11:15 PM, Stephen Frost wrote: > * Michael Paquier (michael.paqu...@gmail.com) wrote: >> The patch attached includes all those tests and they are failing. We >> are going to need a patch able to pass all that, and even for master >> this is going to

Re: [HACKERS] pg_stat_lwlock wait time view

From: pgsql-hackers-ow...@postgresql.org > [mailto:pgsql-hackers-ow...@postgresql.org] On Behalf Of Haribabu Kommi > calculations may cause performance problem. Is there any need of writing > this stats information to file? As this just provides the wait time > information. Yes, saving the

[HACKERS] Better tracking of free space during SP-GiST index build

Over in the thread about the SP-GiST inet opclass, I threatened to post a patch like this, and here it is. The basic idea is to track more than just the very latest page we've used in each of the page categories that SP-GiST works with. I started with an arrangement that gave an equal number of

Re: [HACKERS] pg_dump with tables created in schemas created by extensions

2016-08-24 17:01 GMT-03:00 Martín Marqués : > 2016-08-24 11:15 GMT-03:00 Stephen Frost : >> Michael, >> >> * Michael Paquier (michael.paqu...@gmail.com) wrote: >>> The patch attached includes all those tests and they are failing. We >>> are going to need

Re: [HACKERS] pg_stat_lwlock wait time view

On Wed, Aug 24, 2016 at 4:23 AM, Haribabu Kommi wrote: > There was some discussion earlier in adding pg_stat_lwlock view in [1]. > The main objections which I observed for that patch was showing LWLOCK > information to the user that don't understand what this lock used

Re: Collective typos in contrib/postgres_fdw (Was: Re: [HACKERS] Incorrect comment in contrib/postgres_fdw/deparse.c)

On Wed, Aug 24, 2016 at 2:41 AM, Etsuro Fujita wrote: > On 2016/04/04 20:11, Etsuro Fujita wrote: >> I found an incorrect comment in contrib/postgres_fdw/deparse.c: s/FOR >> SELECT or FOR SHARE/FOR UPDATE or FOR SHARE/ Attached is a patch to fix >> that comment. > >

Re: [HACKERS] pg_dump with tables created in schemas created by extensions

2016-08-24 11:15 GMT-03:00 Stephen Frost : > Michael, > > * Michael Paquier (michael.paqu...@gmail.com) wrote: >> The patch attached includes all those tests and they are failing. We >> are going to need a patch able to pass all that, and even for master >> this is going to

Re: [HACKERS] Stopping logical replication protocol

Hi. It has already passed a few months but patch still have required review state. Can I help to speed up the review, or should i wait commitfest? I plane complete changes in pgjdbc drive inside PR https://github.com/pgjdbc/pgjdbc/pull/550 but PR blocked current problem with not available stop

[HACKERS] Re: [COMMITTERS] pgsql: Modify BufferGetPage() to prepare for "snapshot too old" feature

On Wed, Aug 24, 2016 at 1:00 PM, Kevin Grittner wrote: > On Wed, Aug 24, 2016 at 12:40 PM, Alvaro Herrera > wrote: >> #include catalog/catalog.h in storage/bufmgr.h. >> Can we get it removed? > > Will do that now. Done. Back-patched to 9.6

Re: [HACKERS] Pluggable storage

Alvaro Herrera wrote: > Many have expressed their interest in this topic, but I haven't seen any > design of how it should work. Here's my attempt; I've been playing with > this for some time now and I think what I propose here is a good initial > plan. I regret to announce that I'll have to

Re: [HACKERS] Write Ahead Logging for Hash Indexes

Amit Kapila wrote: > $SUBJECT will make hash indexes reliable and usable on standby. Nice work. Can you split the new xlog-related stuff to a new file, say hash_xlog.h, instead of cramming it in hash.h? Removing the existing #include "xlogreader.h" from hash.h would be nice. I volunteer for

[HACKERS] Re: [COMMITTERS] pgsql: Modify BufferGetPage() to prepare for "snapshot too old" feature

On Wed, Aug 24, 2016 at 12:40 PM, Alvaro Herrera wrote: > Kevin Grittner wrote: >> Modify BufferGetPage() to prepare for "snapshot too old" feature > > I just noticed that this commit added a line to #include catalog/catalog.h > in storage/bufmgr.h. I can't find any

Re: [HACKERS] Bug in to_timestamp().

Sorry. I did not get last two mails from Amul. Don't know why. So I reply to another mail. Documented as working case, but unfortunatly it does not : postgres=# SELECT to_timestamp('2000JUN', ' MON'); ERROR: invalid value "---" for "MON" DETAIL: The given value did not match any of

[HACKERS] Re: [COMMITTERS] pgsql: Modify BufferGetPage() to prepare for "snapshot too old" feature

Kevin Grittner wrote: > Modify BufferGetPage() to prepare for "snapshot too old" feature I just noticed that this commit added a line to #include catalog/catalog.h in storage/bufmgr.h. I can't find any reason for it doing so, and I think it's a bad line to have there. Can we get it removed? --

Re: [HACKERS] SP-GiST support for inet datatypes

> Aside from the disturbing frequency of 100-to-1 split ratios, it also > looks like the inclusion of the masklen bit is hardly pulling its weight, > though that might be a artifact of this data set. I was expecting this. Including masklen bit to decision was something we could easily do. It

Re: [HACKERS] Write Ahead Logging for Hash Indexes

On Tue, Aug 23, 2016 at 10:05 PM, Amit Kapila wrote: > On Wed, Aug 24, 2016 at 2:37 AM, Jeff Janes wrote: > > > > > After an intentionally created crash, I get an Assert triggering: > > > > TRAP: FailedAssertion("!(((freep)[(bitmapbit)/32] & > >

Re: [HACKERS] "Some tests to cover hash_index"

On Wed, Aug 24, 2016 at 2:34 AM, Amit Kapila wrote: > On Wed, Aug 24, 2016 at 11:38 AM, Ashutosh Sharma > wrote: >>> Well, that change should be part of Amit's patch to add WAL logging, >>> not this patch, whose mission is just to improve test

Re: [HACKERS] Optimization for lazy_scan_heap

The following review has been posted through the commitfest application: make installcheck-world: tested, passed Implements feature: not tested Spec compliant: not tested Documentation:not tested Hi, I haven't tested the performance yet, but the patch itself looks

Re: [HACKERS] [Patch] Temporary tables that do not bloat pg_catalog (a.k.a fast temp tables)

On August 24, 2016 9:32:48 AM PDT, Tomas Vondra wrote: > > >On 08/24/2016 12:20 AM, Andres Freund wrote: >> On 2016-08-23 19:18:04 -0300, Claudio Freire wrote: >>> On Tue, Aug 23, 2016 at 7:11 PM, Tomas Vondra >>> wrote: Could

Re: [HACKERS] [Patch] Temporary tables that do not bloat pg_catalog (a.k.a fast temp tables)

On 08/24/2016 12:20 AM, Andres Freund wrote: On 2016-08-23 19:18:04 -0300, Claudio Freire wrote: On Tue, Aug 23, 2016 at 7:11 PM, Tomas Vondra wrote: Could someone please explain how the unlogged tables are supposed to fix the catalog bloat problem, as stated

Re: [HACKERS] Strange result with LATERAL query

Andrew Gierth writes: > "Tom" == Tom Lane writes: > Tom> I think it's a bit too stupid as-is, though. We don't need to > Tom> recalculate for Params in aggdirectargs, do we? > In theory we would need to. How come? Those are only passed to

Re: [HACKERS] Strange result with LATERAL query

> "Tom" == Tom Lane writes: Tom> Hm, I was just working on inserting something of the sort into Tom> ExecInitAgg. But I guess we could do it in the planner too. Will Tom> run with your approach. Tom> I think it's a bit too stupid as-is, though. We don't need to

Re: [HACKERS] [Patch] Temporary tables that do not bloat pg_catalog (a.k.a fast temp tables)

On Tue, Aug 23, 2016 at 6:11 PM, Tomas Vondra wrote: > Could someone please explain how the unlogged tables are supposed to fix the > catalog bloat problem, as stated in the initial patch submission? We'd still > need to insert/delete the catalog rows when

Re: [HACKERS] Oddity in EXPLAIN for foreign/custom join pushdown plans

On Tue, Aug 23, 2016 at 11:18 PM, Etsuro Fujita wrote: >> Yes, it seems what we are doing now is not consistent with what >> happens for plain tables; that should probably be fixed. > > OK, I think we should fix the issue that postgres_fdw produces incorrect > aliases

Re: [HACKERS] Strange result with LATERAL query

Andrew Gierth writes: > How about: Hm, I was just working on inserting something of the sort into ExecInitAgg. But I guess we could do it in the planner too. Will run with your approach. I think it's a bit too stupid as-is, though. We don't need to recalculate for

Re: [HACKERS] Strange result with LATERAL query

> "Pavel" == Pavel Stehule writes: Pavel> The result should not depend on GUC - hashagg on/off changing Pavel> output - it is error. I don't think anyone's suggesting leaving it unfixed, just whether the fix should introduce unnecessary rescans of the aggregate

Re: [HACKERS] Strange result with LATERAL query

> "Andrew" == Andrew Gierth writes: > "Tom" == Tom Lane writes: Tom> I'm not sure if it's worth trying to distinguish whether the Param Tom> is inside any aggregate calls or not. How about: -- Andrew (irc:RhodiumToad) diff --git

Re: [HACKERS] Strange result with LATERAL query

> "Tom" == Tom Lane writes: Tom> I'm not sure if it's worth trying to distinguish whether the Param Tom> is inside any aggregate calls or not. The existing code gets the Tom> right answer for Tom> select array(select x+sum(y) from generate_series(1,3) y group by y)

Re: [HACKERS] Strange result with LATERAL query

2016-08-24 17:08 GMT+02:00 Tom Lane : > Andrew Gierth writes: > > Something is wrong with the way chgParam is being handled in Agg nodes. > > The code in ExecReScanAgg seems to assume that if the lefttree doesn't > > have any parameter changes

Re: [HACKERS] Strange result with LATERAL query

Andrew Gierth writes: > Something is wrong with the way chgParam is being handled in Agg nodes. > The code in ExecReScanAgg seems to assume that if the lefttree doesn't > have any parameter changes then it suffices to re-project the data from > the existing hashtable;

Re: [HACKERS] [PATCH] Alter or rename enum value

> That would require changing it from an AlterEnumStmt to a RenameStmt > instead. Those look to me like they're for renaming SQL objects, > i.e. things addressed by identifiers, whereas enum labels are just > strings. Looking at the implementation of a few of the functions called > by

Re: [HACKERS] Showing parallel status in \df+

I wrote: > Peter Eisentraut writes: >> What does it do if you are displaying more than one function? > It prints more than one footer. It's very much like the way that, say, > rules are printed for tables by \d. Or to be concrete: instead of regression=#

Re: [HACKERS] pg_dump with tables created in schemas created by extensions

Michael, * Michael Paquier (michael.paqu...@gmail.com) wrote: > The patch attached includes all those tests and they are failing. We > are going to need a patch able to pass all that, and even for master > this is going to need more thoughts, and let's focus on HEAD/9.6 > first. Are you sure you

Re: [HACKERS] SP-GiST support for inet datatypes

I wrote: > I've pushed this patch with mostly (not entirely) cosmetic adjustments. > I still think it'd be worth looking into why the produced index is larger > than the GiST equivalent, and for that matter exactly why the GiST > equivalent is so much slower to search. I spent some time poking at

Re: [HACKERS] Showing parallel status in \df+

Peter Eisentraut writes: > On 8/22/16 1:52 PM, Pavel Stehule wrote: >> If I understand to purpose of this patch - it is compromise - PL source >> is removed from table, but it is printed in result. > What does it do if you are displaying more than one function?

Re: [HACKERS] dump/restore doesn't preserve row ordering?

On Tue, Aug 23, 2016 at 8:43 PM, Tom Lane wrote: > It's interesting that nobody has complained about this behavior. We have been known to emphasize that unless you have an ORDER BY clause at the outermost level of a query, there is no guarantee about the order of rows

Re: [HACKERS] Strange result with LATERAL query

> "Andrew" == Andrew Gierth writes: > "Jeevan" == Jeevan Chalke writes: Jeevan> Hi, Jeevan> While playing with LATERAL along with some aggregates in Jeevan> sub-query, I have observed somewhat unusual behavior. Andrew>

Re: [HACKERS] Strange result with LATERAL query

> "Jeevan" == Jeevan Chalke writes: Jeevan> Hi, Jeevan> While playing with LATERAL along with some aggregates in Jeevan> sub-query, I have observed somewhat unusual behavior. Simpler example not needing LATERAL: select array(select sum(x+y) from

Re: [HACKERS] Showing parallel status in \df+

On 8/22/16 1:52 PM, Pavel Stehule wrote: > If I understand to purpose of this patch - it is compromise - PL source > is removed from table, but it is printed in result. What does it do if you are displaying more than one function? -- Peter Eisentraut http://www.2ndQuadrant.com/

Re: [HACKERS] [RFC] Change the default of update_process_title to off

On Wed, Aug 24, 2016 at 2:35 PM, Tsunakawa, Takayuki wrote: > From: Peter Geoghegan [mailto:p...@heroku.com] >> On Tue, Aug 23, 2016 at 1:44 PM, Bruce Momjian wrote: >> >> [Windows] >> >> #clients onoff >> >> 12 29793 38169 >> >> 24

Re: [HACKERS] How to do failover in pglogical replication?

Hi Craig, I am trying to set up pglogical replication. I have a table which has around 4 rows in the provider server. = employee_id | visitor_email | vistor_id |date | message

Re: [HACKERS] [PATCH] Alter or rename enum value

Emre Hasegeli writes: >> Here is v4, which changes the command from ALTER VALUE to RENAME VALUE, >> for consistency with RENAME ATTRIBUTE. > > It looks like we always use "ALTER ... RENAME ... old_name TO > new_name" syntax, so it is better that way. I have noticed that all >

Re: [HACKERS] Proposal for CSN based snapshots

On Wed, Aug 24, 2016 at 11:54 AM, Heikki Linnakangas wrote: > On 08/23/2016 06:18 PM, Heikki Linnakangas wrote: > >> On 08/22/2016 08:38 PM, Andres Freund wrote: >> >>> On 2016-08-22 20:32:42 +0300, Heikki Linnakangas wrote: >>> I remember seeing ProcArrayLock

Re: [HACKERS] [RFC] Change the default of update_process_title to off

On Wed, Aug 24, 2016 at 4:35 AM, Tsunakawa, Takayuki < tsunakawa.ta...@jp.fujitsu.com> wrote: > From: Peter Geoghegan [mailto:p...@heroku.com] > > On Tue, Aug 23, 2016 at 1:44 PM, Bruce Momjian wrote: > > >> [Windows] > > >> #clients onoff > > >> 12 29793 38169 > > >>

Re: [HACKERS] Proposal for CSN based snapshots

On 08/23/2016 06:18 PM, Heikki Linnakangas wrote: On 08/22/2016 08:38 PM, Andres Freund wrote: On 2016-08-22 20:32:42 +0300, Heikki Linnakangas wrote: I remember seeing ProcArrayLock contention very visible earlier, but I can't hit that now. I suspect you'd still see contention on bigger

Re: [HACKERS] WAL consistency check facility

On 22 August 2016 at 16:56, Simon Riggs wrote: > On 22 August 2016 at 13:44, Kuntal Ghosh wrote: > >> Please let me know your thoughts on this. > > Do the regression tests pass with this option enabled? Hi, I'd like to be a reviewer on this.

Re: [HACKERS] postgres_fdw : altering foreign table not invalidating prepare statement execution plan.

On 2016/04/04 23:24, Tom Lane wrote: Amit Langote writes: On 2016/04/04 15:17, Rajkumar Raghuwanshi wrote: * .Observation: *Prepare statement execution plan is not getting changed even after altering foreign table to point to new schema. I wonder if

[HACKERS] pg_stat_lwlock wait time view

There was some discussion earlier in adding pg_stat_lwlock view in [1]. The main objections which I observed for that patch was showing LWLOCK information to the user that don't understand what this lock used for and etc. Currently as part of wait_event information in pg_stat_activity the LWLOCK

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

On Tue, Aug 23, 2016 at 3:59 AM, Andres Freund wrote: >> Haribabu's categorization >> scheme seems to need some work, but the idea of categorizing >> statements by type and counting executions per type seems very >> reasonable. > > I'd consider instead using something like

Re: [HACKERS] standalone backend PANICs during recovery

--On 20. August 2016 12:41:48 -0400 Tom Lane wrote: > So at this point I'm pretty baffled as to what the actual use-case is > here. I am tempted to say that a standalone backend should refuse to > start at all if a recovery.conf file is present. If we do want to > allow

Re: [HACKERS] pg_dump with tables created in schemas created by extensions

On Wed, Aug 24, 2016 at 9:07 AM, Michael Paquier wrote: > On Wed, Aug 24, 2016 at 5:34 AM, Martín Marqués > wrote: >> Hi, >> >> 2016-08-23 16:46 GMT-03:00 Martín Marqués : >>> >>> I will add tests for sequence and

Collective typos in contrib/postgres_fdw (Was: Re: [HACKERS] Incorrect comment in contrib/postgres_fdw/deparse.c)

On 2016/04/04 20:11, Etsuro Fujita wrote: I found an incorrect comment in contrib/postgres_fdw/deparse.c: s/FOR SELECT or FOR SHARE/FOR UPDATE or FOR SHARE/ Attached is a patch to fix that comment. Other than this, I ran into some typos in contrib/postgres_fdw, while working on join

Re: [HACKERS] patch: function xmltable

2016-08-23 21:00 GMT+02:00 Pavel Stehule : > Hi > > 2016-08-19 10:58 GMT+02:00 Pavel Stehule : > >> Hi >> >> I am sending implementation of xmltable function. The code should to have >> near to final quality and it is available for testing. >> >>

Re: [HACKERS] Write Ahead Logging for Hash Indexes

On Wed, Aug 24, 2016 at 11:44 AM, Mark Kirkwood wrote: > On 24/08/16 17:01, Mark Kirkwood wrote: >> >> >> ...actually I was wrong there, only 2 of them were the same. So I've >> attached a new log of bt's of them all. >> >> >> > > And I can reproduce with only 1

Re: [HACKERS] "Some tests to cover hash_index"

On Wed, Aug 24, 2016 at 11:38 AM, Ashutosh Sharma wrote: > Hi, > >> Well, that change should be part of Amit's patch to add WAL logging, >> not this patch, whose mission is just to improve test coverage. > > I have just removed the warning message from expected output file

Re: [HACKERS] pgbench - minor doc improvements

I looked at this, but I don't really find any of these changes to be improvements. They just make it harder to read IMO. I marked the patch as rejected in CF 2016-09. -- Fabien. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription:

Re: [HACKERS] Write Ahead Logging for Hash Indexes

On 24/08/16 17:01, Mark Kirkwood wrote: ...actually I was wrong there, only 2 of them were the same. So I've attached a new log of bt's of them all. And I can reproduce with only 1 session, figured that might be a helpful piece of the puzzle (trace attached). $ pgbench -c 1 -T600

Re: [HACKERS] "Some tests to cover hash_index"

Hi, > Well, that change should be part of Amit's patch to add WAL logging, > not this patch, whose mission is just to improve test coverage. I have just removed the warning message from expected output file as i have performed the testing on Amit's latest patch that removes this warning message