Re: [HACKERS] Fix checkpoint skip logic on idle systems by tracking LSN progress

On Fri, Sep 30, 2016 at 2:05 PM, Kyotaro HORIGUCHI wrote: > At Fri, 30 Sep 2016 14:00:15 +0900 (Tokyo Standard Time), Kyotaro HORIGUCHI > wrote in > <20160930.140015.150178454.horiguchi.kyot...@lab.ntt.co.jp> >> I don't see no

Re: [HACKERS] IF (NOT) EXISTS in psql-completion

At Thu, 29 Sep 2016 16:16:00 +0900 (Tokyo Standard Time), Kyotaro HORIGUCHI wrote in <20160929.161600.224338668.horiguchi.kyot...@lab.ntt.co.jp> > That looks better. I'll change the API as the following. > > COMPLETE_WITH_QUERY(query); >

Re: [HACKERS] [GENERAL] pg_upgrade from 9.5 to 9.6 fails with "invalid argument"

On Fri, Sep 30, 2016 at 1:26 PM, Kyotaro HORIGUCHI wrote: > Hello, > > At Fri, 30 Sep 2016 13:11:21 +0900, Masahiko Sawada > wrote in

Re: [HACKERS] Fix checkpoint skip logic on idle systems by tracking LSN progress

Sorry, it wrote wrong thing. At Fri, 30 Sep 2016 14:00:15 +0900 (Tokyo Standard Time), Kyotaro HORIGUCHI wrote in <20160930.140015.150178454.horiguchi.kyot...@lab.ntt.co.jp> > Sorry, I might have torn off this thread somehow.. > > At Thu, 29 Sep 2016 11:26:29

Re: [HACKERS] Fix checkpoint skip logic on idle systems by tracking LSN progress

Sorry, I might have torn off this thread somehow.. At Thu, 29 Sep 2016 11:26:29 -0400, David Steele wrote in <30095aea-3910-dbb7-1790-a579fb93f...@pgmasters.net> > On 9/28/16 10:32 PM, Michael Paquier wrote: > > On Thu, Sep 29, 2016 at 7:45 AM, David Steele

Re: [HACKERS] Tracking wait event for latches

On Fri, Sep 30, 2016 at 1:48 AM, Robert Haas wrote: > It seems to me that you haven't tested this patch very carefully, > because as far as I can see it breaks wait event reporting for both > heavyweight locks and buffer pins - or in other words two out of the > three

Re: [HACKERS] Renaming of pg_xlog and pg_clog

On Thu, Sep 29, 2016 at 9:17 PM, Michael Paquier wrote: > On Tue, Aug 30, 2016 at 11:04 AM, Michael Paquier > wrote: >> On Mon, Aug 29, 2016 at 9:39 PM, Craig Ringer >> wrote: >>> Cool. I'll mark as waiting on

Re: [HACKERS] Speed up Clog Access by increasing CLOG buffers

On Thu, Sep 29, 2016 at 8:05 PM, Robert Haas wrote: > OK, another theory: Dilip is, I believe, reinitializing for each run, > and you are not. Yes, I am reinitializing for each run. -- Regards, Dilip Kumar EnterpriseDB: http://www.enterprisedb.com -- Sent via

Re: [HACKERS] [GENERAL] pg_upgrade from 9.5 to 9.6 fails with "invalid argument"

Hello, At Fri, 30 Sep 2016 13:11:21 +0900, Masahiko Sawada wrote in

Re: [HACKERS] [GENERAL] pg_upgrade from 9.5 to 9.6 fails with "invalid argument"

On Fri, Sep 30, 2016 at 7:08 AM, Tom Lane wrote: > Alvaro Herrera writes: >> Tom Lane wrote: >>> I wouldn't even put a lot of faith in the errno being meaningful, >>> considering that it does close() calls before capturing the errno. > >> So we do

Re: [HACKERS] Bug in to_timestamp().

The following review has been posted through the commitfest application: make installcheck-world: tested, passed Implements feature: tested, passed Spec compliant: not tested Documentation:tested, passed Appreciate your support. I've tested v6 patch again, looks good

Re: [HACKERS] PoC: Make it possible to disallow WHERE-less UPDATE and DELETE

On Thu, Sep 29, 2016 at 6:19 PM, David Fetter wrote: > On Thu, Sep 29, 2016 at 11:12:11AM +1300, Thomas Munro wrote: >> On Mon, Sep 26, 2016 at 5:11 PM, Thomas Munro >> wrote: >> > On Mon, Sep 26, 2016 at 1:18 PM, Thomas Munro >> >

Re: [HACKERS] Notice lock waits

On Fri, Sep 30, 2016 at 3:00 AM, Jeff Janes wrote: > On Wed, Sep 28, 2016 at 11:57 PM, Haribabu Kommi > wrote: >> >> >> Providing the details of lock wait to the client is good. I fell this >> message >> is useful for the cases where

Re: [HACKERS] Hash Indexes

On Thu, Sep 29, 2016 at 8:53 PM, Peter Geoghegan wrote: > On Fri, Sep 30, 2016 at 1:14 AM, Robert Haas wrote: >>> I, for one, agree with this position. >> >> Well, I, for one, find it frustrating. It seems pretty unhelpful to >> bring this up only after

Re: [HACKERS] Learning to hack Postgres - Keeping track of ctids

On 30 September 2016 at 04:15, Emrul wrote: > Hi, > > I'm working on an idea to implement a graph database in Postgres. At the > moment its just a learning exercise. > > What I'd like to do is store a reference to all the links from one record > using an array type that stores

Re: [HACKERS] Hash Indexes

On Thu, Sep 29, 2016 at 8:29 PM, Andres Freund wrote: > On September 29, 2016 5:28:00 PM PDT, Robert Haas > wrote: >>On Thu, Sep 29, 2016 at 8:16 PM, Andres Freund >>wrote: Well, I, for one, find it frustrating. It seems

Re: [HACKERS] Hash Indexes

On Fri, Sep 30, 2016 at 1:14 AM, Robert Haas wrote: >> I, for one, agree with this position. > > Well, I, for one, find it frustrating. It seems pretty unhelpful to > bring this up only after the code has already been written. The first > post on this thread was on May

Re: [HACKERS] Hash Indexes

On Fri, Sep 30, 2016 at 1:29 AM, Andres Freund wrote: >>To whom? In what context? > > Amit, over dinner. In case it matters, I also talked to Amit about this privately. -- Peter Geoghegan -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make

Re: [HACKERS] Hash Indexes

On September 29, 2016 5:28:00 PM PDT, Robert Haas wrote: >On Thu, Sep 29, 2016 at 8:16 PM, Andres Freund >wrote: >>> Well, I, for one, find it frustrating. It seems pretty unhelpful to >>> bring this up only after the code has already been written.

Re: [HACKERS] Hash Indexes

On Thu, Sep 29, 2016 at 8:16 PM, Andres Freund wrote: >> Well, I, for one, find it frustrating. It seems pretty unhelpful to >> bring this up only after the code has already been written. > > I brought this up in person at pgcon too. To whom? In what context? -- Robert

Re: [HACKERS] Hash Indexes

On 2016-09-29 20:14:40 -0400, Robert Haas wrote: > On Thu, Sep 29, 2016 at 8:07 PM, Peter Geoghegan wrote: > > On Wed, Sep 28, 2016 at 8:06 PM, Andres Freund wrote: > >> On 2016-09-28 15:04:30 -0400, Robert Haas wrote: > >>> Andres already > >>> stated that

Re: [HACKERS] Hash Indexes

On Thu, Sep 29, 2016 at 8:07 PM, Peter Geoghegan wrote: > On Wed, Sep 28, 2016 at 8:06 PM, Andres Freund wrote: >> On 2016-09-28 15:04:30 -0400, Robert Haas wrote: >>> Andres already >>> stated that he things working on btree-over-hash would be more >>>

Re: [HACKERS] Declarative partitioning - another take

On Thu, Sep 29, 2016 at 8:09 AM, Amit Langote wrote: > I removed DEPENDENCY_IGNORE. Does the following look good or am I still > missing something? You missed your commit message, but otherwise looks fine. >> Also, I think this should be rephrased a bit to be

Re: [HACKERS] Hash Indexes

On Wed, Sep 28, 2016 at 8:06 PM, Andres Freund wrote: > On 2016-09-28 15:04:30 -0400, Robert Haas wrote: >> Andres already >> stated that he things working on btree-over-hash would be more >> beneficial than fixing hash, but at this point it seems like he's the >> only one who

Re: [HACKERS] [GENERAL] pg_upgrade from 9.5 to 9.6 fails with "invalid argument"

Alvaro Herrera writes: > Tom Lane wrote: >> I wouldn't even put a lot of faith in the errno being meaningful, >> considering that it does close() calls before capturing the errno. > So we do close() in a bunch of places while closing shop, which calls > _close() on

Re: [HACKERS] pg_basebackup, pg_receivexlog and data durability (was: silent data loss with ext4 / all current versions)

Michael Paquier writes: > Oops. Are you using gcc to see that? I compiled with clang and on > Windows without noticing it. Peter already noted that you'd only see it on platforms that define PG_FLUSH_DATA_WORKS. regards, tom lane -- Sent via

Re: [HACKERS] [GENERAL] pg_upgrade from 9.5 to 9.6 fails with "invalid argument"

Alvaro Herrera writes: > Moreover I think getErrorText() as a whole is misconceived and should be > removed altogether (why pstrdup the string?). Indeed. I think bouncing the error back to the caller is misguided to start with, seeing that the caller is just going to

Re: [HACKERS] [GENERAL] pg_upgrade from 9.5 to 9.6 fails with "invalid argument"

I wrote: > But what gets my attention in this connection is that it doesn't > seem to be taking the trouble to open the files in binary mode. > Could that lead to the reported failure? Not sure, but it seems > like at the least it could result in corrupted VM files. On further thought, it

Re: [HACKERS] pg_basebackup, pg_receivexlog and data durability (was: silent data loss with ext4 / all current versions)

On Fri, Sep 30, 2016 at 1:31 AM, Jeff Janes wrote: > On Thu, Sep 29, 2016 at 8:33 AM, Peter Eisentraut > wrote: >> >> On 9/26/16 10:34 PM, Michael Paquier wrote: >> > I thought that as long as the error string is shown to the user, it >> >

Re: [HACKERS] [GENERAL] pg_upgrade from 9.5 to 9.6 fails with "invalid argument"

Tom Lane wrote: > Thomas Kellerer writes: > > for some reason pg_upgrade failed on Windows 10 for me, with an error > > message that one specifc _vm file couldn't be copied. > > Hmm ... a _vm file would go through rewriteVisibilityMap(), which is new > code for 9.6 and

Re: [HACKERS] [GENERAL] pg_upgrade from 9.5 to 9.6 fails with "invalid argument"

Thomas Kellerer writes: > for some reason pg_upgrade failed on Windows 10 for me, with an error message > that one specifc _vm file couldn't be copied. Hmm ... a _vm file would go through rewriteVisibilityMap(), which is new code for 9.6 and hasn't really gotten that much

[HACKERS] Congrats on the on-time release!

Hackers, I wanted to congratulate everyone involved (and it's a long list of people) in having our first on-schedule major release since 9.3. Especially the RMT, which did a lot to make that happen. Getting the release train to run on time is a major accomplishment, and will help both

Re: [HACKERS] Order of operations in SubPostmasterMain()

On 2016-09-29 15:46:00 -0400, Tom Lane wrote: > I noticed that buildfarm member culicidae, which is running an > EXEC_BACKEND build on Linux, occasionally falls over like this: > > FATAL: could not reattach to shared memory (key=6280001, > addr=0x7fa9df845000): Invalid argument > > That's

Re: [HACKERS] Order of operations in SubPostmasterMain()

Greg Stark writes: > On Thu, Sep 29, 2016 at 8:46 PM, Tom Lane wrote: >> We could probably refactor things enough so that we do pq_init() >> before PGSharedMemoryReAttach(). It would be a little bit ugly, >> and it would fractionally increase the chance of a

[HACKERS] Learning to hack Postgres - Keeping track of ctids

Hi, I'm working on an idea to implement a graph database in Postgres. At the moment its just a learning exercise. What I'd like to do is store a reference to all the links from one record using an array type that stores links to all related tables. At first, I've succeeded in doing this using

Re: [HACKERS] pg_basebackup, pg_receivexlog and data durability

On 9/29/16 12:31 PM, Jeff Janes wrote: > With that in mind, I have committed the v3 series now. > > > I'm getting compiler warnings: Fixed. > > file_utils.c: In function 'fsync_pgdata': > file_utils.c:86: warning: passing argument 2 of 'walkdir' from > incompatible pointer type >

Re: [HACKERS] Order of operations in SubPostmasterMain()

On Thu, Sep 29, 2016 at 8:46 PM, Tom Lane wrote: > We could probably refactor things enough so that we do pq_init() > before PGSharedMemoryReAttach(). It would be a little bit ugly, > and it would fractionally increase the chance of a reattach failure > because pq_init()

Re: [HACKERS] pageinspect: Hash index support

On 9/29/16 4:00 PM, Peter Eisentraut wrote: > Since the commit fest is drawing to a close, I'll set this patch as > returned with feedback. Actually, the CF app informs me that moving to the next CF is more appropriate, so I have done that. -- Peter Eisentraut

Re: [HACKERS] pageinspect: Hash index support

I think we should look into handling the different page types better. The hash_page_stats function was copied from btree, which only has one type. It's not clear whether all the values apply to each page type. At least they should be null if they don't apply. BRIN has a separate function for

[HACKERS] Order of operations in SubPostmasterMain()

I noticed that buildfarm member culicidae, which is running an EXEC_BACKEND build on Linux, occasionally falls over like this: FATAL: could not reattach to shared memory (key=6280001, addr=0x7fa9df845000): Invalid argument That's probably because Andres failed to disable ASLR on that machine,

Re: [HACKERS] pageinspect: Hash index support

I wrote some tests for pageinspect, attached here (hash stuff in a separate patch). I think all the output numbers ought to be deterministic (I excluded everything that might contain xids). Please test. -- Peter Eisentraut http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7

Re: [HACKERS] PL/Python adding support for multi-dimensional arrays

On 09/23/2016 10:27 PM, Jim Nasby wrote: On 9/23/16 2:42 AM, Heikki Linnakangas wrote: How do we handle single-dimensional arrays of composite types at the moment? At a quick glance, it seems that the composite types are just treated like strings, when they're in an array. That's probably OK,

Re: [HACKERS] Patch: Implement failover on libpq connect level.

This patch do not apply on latest code. it fails as follows libpq-failover-9.patch:176: trailing whitespace. thread.o pgsleep.o libpq-failover-9.patch:184: trailing whitespace. check: libpq-failover-9.patch:185: trailing whitespace. $(prove_check) libpq-failover-9.patch:186: trailing whitespace.

Re: [HACKERS] Let file_fdw access COPY FROM PROGRAM

Corey Huinker writes: > [ file_fdw_program_v3.diff ] Pushed with cosmetic adjustments, mostly more work on the comments and documentation. I did not push the proposed test case; it's unportable. The upthread suggestion to add a TAP test would have been all right,

Re: [HACKERS] Notice lock waits

On Wed, Sep 28, 2016 at 11:57 PM, Haribabu Kommi wrote: > > > On Sat, Aug 6, 2016 at 3:00 AM, Jeff Janes wrote: > >> One time too many, I ran some minor change using psql on a production >> server and was wondering why it was taking so much longer

Re: [HACKERS] Tuplesort merge pre-reading

On Thu, Sep 29, 2016 at 11:38 AM, Peter Geoghegan wrote: > On Thu, Sep 29, 2016 at 2:59 PM, Robert Haas wrote: >>> Maybe that was the wrong choice of words. What I mean is that it seems >>> somewhat unprincipled to give over an equal share of memory to

Re: [HACKERS] Tracking wait event for latches

On Wed, Sep 28, 2016 at 9:40 PM, Michael Paquier wrote: > On Wed, Sep 28, 2016 at 9:45 PM, Robert Haas wrote: >> On Wed, Sep 28, 2016 at 8:38 AM, Michael Paquier >> wrote: >>> So should I change back the patch to have

Re: [HACKERS] pg_basebackup, pg_receivexlog and data durability (was: silent data loss with ext4 / all current versions)

On Thu, Sep 29, 2016 at 8:33 AM, Peter Eisentraut < peter.eisentr...@2ndquadrant.com> wrote: > On 9/26/16 10:34 PM, Michael Paquier wrote: > > I thought that as long as the error string is shown to the user, it > > does not matter much if errno is still saved or not. All the callers > > of

Re: [HACKERS] pageinspect: Hash index support

On 09/29/2016 11:58 AM, Peter Eisentraut wrote: On 9/27/16 10:10 AM, Jesper Pedersen wrote: contrib/pageinspect/pageinspect--1.5--1.6.sql | 59 contrib/pageinspect/pageinspect--1.5.sql | 279 -- contrib/pageinspect/pageinspect--1.6.sql | 346

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

> >> The attached patch adds the >> dependencies from create_foreignscan_plan() which is called for any >> foreign access. I have also added testcases to test the functionality. >> Let me know your comments on the patch. > > > Hmm. I'm not sure that that's a good idea. > > I was thinking the

Re: [HACKERS] pageinspect: Hash index support

On 9/27/16 10:10 AM, Jesper Pedersen wrote: > contrib/pageinspect/pageinspect--1.5--1.6.sql | 59 > contrib/pageinspect/pageinspect--1.5.sql | 279 -- > contrib/pageinspect/pageinspect--1.6.sql | 346 ++ I think there is still a misunderstanding

Re: [HACKERS] Set log_line_prefix and application name in test drivers

Tom Lane wrote: > Robert Haas writes: > > As long as we get %t and %p in there we're going to be way ahead, really. > > Could we get consensus on just changing the default to > > log_line_prefix = '%t [%p] ' > > and leaving the rest out of it? +1 from me. --

Re: [HACKERS] Tuplesort merge pre-reading

On Thu, Sep 29, 2016 at 2:59 PM, Robert Haas wrote: >> Maybe that was the wrong choice of words. What I mean is that it seems >> somewhat unprincipled to give over an equal share of memory to each >> active-at-least-once tape, ... > > I don't get it. If the memory is being

Re: [HACKERS] pg_basebackup, pg_receivexlog and data durability (was: silent data loss with ext4 / all current versions)

On 9/26/16 10:34 PM, Michael Paquier wrote: > I thought that as long as the error string is shown to the user, it > does not matter much if errno is still saved or not. All the callers > of durable_rename() on frontends don't check for strerrno(errno) > afterwards. Do you think it matters?

Re: [HACKERS] "Re: Question about grant create on database and pg_dump/pg_dumpall

Robert Haas writes: > On Thu, Sep 29, 2016 at 4:04 AM, Haribabu Kommi > wrote: >> I am also not sure whether pg_dumpall -g and then individual pg_dump >> is the more widely used approach or not? > That's the approach I normally recommend. The

Re: [HACKERS] Fix checkpoint skip logic on idle systems by tracking LSN progress

On 9/28/16 10:32 PM, Michael Paquier wrote: On Thu, Sep 29, 2016 at 7:45 AM, David Steele wrote: In general I agree with the other comments that this could end up being a problem. On the other hand, since the additional locks are only taken at checkpoint or

Re: [HACKERS] Tuplesort merge pre-reading

On 09/29/2016 05:41 PM, Heikki Linnakangas wrote: Here's a new patch version, addressing the points you made. Please have a look! Bah, I fumbled the initSlabAllocator() function, attached is a fixed version. - Heikki >From bd74cb9c32b3073637d6932f3b4552598fcdc92a Mon Sep 17 00:00:00 2001

Re: [HACKERS] PL/Python adding support for multi-dimensional arrays

On 27 September 2016 at 14:58, Heikki Linnakangas wrote: > On 09/27/2016 02:04 PM, Dave Cramer wrote: > >> On 26 September 2016 at 14:52, Dave Cramer wrote: >> >>> This crashes with arrays with non-default lower bounds: postgres=# SELECT * FROM

Re: [HACKERS] Hash Indexes

On Thu, Sep 29, 2016 at 6:04 AM, Robert Haas wrote: > On Wed, Sep 28, 2016 at 3:04 PM, Robert Haas wrote: >> I'll write another email with my thoughts about the rest of the patch. > > I think that the README changes for this patch need a fairly large

Re: [HACKERS] "Re: Question about grant create on database and pg_dump/pg_dumpall

On Thu, Sep 29, 2016 at 4:04 AM, Haribabu Kommi wrote: > I am also not sure whether pg_dumpall -g and then individual pg_dump > is the more widely used approach or not? That's the approach I normally recommend. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com

Re: [HACKERS] Tuplesort merge pre-reading

On 09/29/2016 01:52 PM, Peter Geoghegan wrote: * Variables like maxTapes have a meaning that is directly traceable back to Knuth's description of polyphase merge. I don't think that you should do anything to them, on general principle. Ok. I still think that changing maxTapes would make sense,

Re: [HACKERS] Bug in to_timestamp().

Robert Haas writes: > On Thu, Sep 29, 2016 at 4:54 AM, amul sul wrote: >> Commitfest status left untouched, I am not sure how to deal with >> "Returned With Feedback" patch. Is there any chance that, this can be >> considered again for committer review?

Re: [HACKERS] Set log_line_prefix and application name in test drivers

Christoph Berg writes: > Re: Tom Lane 2016-09-29 <16946.1475157...@sss.pgh.pa.us> >> Personally I'm also on board with using this for regression testing: >> log_line_prefix = '%t [%p] %q%a ' >> but I doubt it can be sold as a general-purpose default. > I don't think it makes

Re: [HACKERS] Speed up Clog Access by increasing CLOG buffers

On Thu, Sep 29, 2016 at 10:14 AM, Tomas Vondra wrote: >> It's not impossible that the longer runs could matter - performance >> isn't necessarily stable across time during a pgbench test, and the >> longer the run the more CLOG pages it will fill. > > Sure, but I'm

Re: [HACKERS] Bug in to_timestamp().

On Thu, Sep 29, 2016 at 4:54 AM, amul sul wrote: > On Thu, Sep 29, 2016 at 2:48 AM, Tom Lane wrote: >> Artur Zakirov writes: >>> - now DCH_cache_getnew() is called after parse_format(). Because now >>> parse_format() can raise an

Re: [HACKERS] Set log_line_prefix and application name in test drivers

Re: Tom Lane 2016-09-29 <16946.1475157...@sss.pgh.pa.us> > Robert Haas writes: > > As long as we get %t and %p in there we're going to be way ahead, really. > > Could we get consensus on just changing the default to > > log_line_prefix = '%t [%p] ' > > and leaving

Re: [HACKERS] Speed up Clog Access by increasing CLOG buffers

On 09/29/2016 03:47 PM, Robert Haas wrote: On Wed, Sep 28, 2016 at 9:10 PM, Tomas Vondra wrote: I feel like we must be missing something here. If Dilip is seeing huge speedups and you're seeing nothing, something is different, and we don't know what it is. Even

Re: [HACKERS] Set log_line_prefix and application name in test drivers

Re: Peter Eisentraut 2016-09-29 <21d2719f-36ff-06d2-5856-25ed48b96...@2ndquadrant.com> > > Christoph/Debian: > > log_line_prefix = '%t [%p-%l] %q%u@%d ' > > Peter: > > log_line_prefix = '%t [%p]: [%l] %qapp=%a ' > > I'm aware of two existing guidelines on log line formats: syslog and >

Re: [HACKERS] Set log_line_prefix and application name in test drivers

Robert Haas writes: > As long as we get %t and %p in there we're going to be way ahead, really. Could we get consensus on just changing the default to log_line_prefix = '%t [%p] ' and leaving the rest out of it? I think pretty much everybody agrees that those

Re: [HACKERS] Tuplesort merge pre-reading

On Thu, Sep 29, 2016 at 6:52 AM, Peter Geoghegan wrote: >> How is it awkward? > > Maybe that was the wrong choice of words. What I mean is that it seems > somewhat unprincipled to give over an equal share of memory to each > active-at-least-once tape, ... I don't get it. If the

Re: [HACKERS] Set log_line_prefix and application name in test drivers

On Wed, Sep 28, 2016 at 10:30 PM, Peter Eisentraut wrote: > On 9/28/16 6:13 PM, Robert Haas wrote: >> Christoph/Debian: >> log_line_prefix = '%t [%p-%l] %q%u@%d ' >> Peter: >> log_line_prefix = '%t [%p]: [%l] %qapp=%a ' > > I'm aware of two existing

Re: [HACKERS] Speed up Clog Access by increasing CLOG buffers

On Wed, Sep 28, 2016 at 9:10 PM, Tomas Vondra wrote: >> I feel like we must be missing something here. If Dilip is seeing >> huge speedups and you're seeing nothing, something is different, and >> we don't know what it is. Even if the test case is artificial, it >>

Re: [HACKERS] postgresql infinite loop

=?GB2312?B?ufkg08I=?= writes: > I have a postgresql infinite problem. > when inserting data, a postgresql process involve to infinite loop and cpu > usage is 100%. perf top show that LWacquirelock is most costful. > Callstack is below. Given that stack trace, I'd have

[HACKERS] postgresql infinite loop

I have a postgresql infinite problem. when inserting data, a postgresql process involve to infinite loop and cpu usage is 100%. perf top show that LWacquirelock is most costful. Callstack is below. Other processes are normal and can process insert operation. But after some minutes, one

Re: [HACKERS] WAL logging problem in 9.4.3?

Hello, At Thu, 29 Sep 2016 16:59:55 +0900, Michael Paquier wrote in > On Mon, Sep 26, 2016 at 5:03 PM, Kyotaro HORIGUCHI > wrote: > > Hello, I return to this before

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

On 2016/09/29 20:03, Ashutosh Bapat wrote: On Tue, Apr 5, 2016 at 10:54 AM, Amit Langote wrote: How about the attached that teaches extract_query_dependencies() to add a foreign table and associated foreign data wrapper and foreign server to invalItems. Also, it

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

On 2016/09/29 20:06, Ashutosh Bapat wrote: On Wed, Aug 24, 2016 at 1:55 PM, Etsuro Fujita wrote: On 2016/04/04 23:24, Tom Lane wrote: A related issue, now that I've seen this example, is that altering FDW-level or server-level options won't cause a replan either.

Re: [HACKERS] Push down more full joins in postgres_fdw

On 2016/09/28 18:35, Etsuro Fujita wrote: Attached is an updated version of the patch. I found a minor bug in that patch; the relation_index added to PgFdwRelationInfo was defined as Index, but I used the modifier %d to print that. So, I changed the data type to int. Also, I added a bit

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

On Wed, Aug 24, 2016 at 1:55 PM, Etsuro Fujita wrote: > 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

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

On Tue, Apr 5, 2016 at 10:54 AM, Amit Langote wrote: > On 2016/04/05 0:23, Tom Lane wrote: >> Amit Langote writes: >>> On Mon, Apr 4, 2016 at 11:24 PM, Tom Lane wrote: A related issue, now that I've seen this

Re: [HACKERS] PATCH: Exclude additional directories in pg_basebackup

On 9/28/16 9:55 PM, Peter Eisentraut wrote: > On 9/28/16 2:45 AM, Michael Paquier wrote: >> After all that fixed, I have moved the patch to "Ready for Committer". >> Please use the updated patch though. > > Committed after some cosmetic changes. Thank you, Peter! -- -David da...@pgmasters.net

Re: [HACKERS] Tuplesort merge pre-reading

On Thu, Sep 29, 2016 at 10:49 AM, Heikki Linnakangas wrote: >> Do I have that right? If so, this seems rather awkward. Hmm. > > > How is it awkward? Maybe that was the wrong choice of words. What I mean is that it seems somewhat unprincipled to give over an equal share of memory

Re: [HACKERS] pg_basebackup stream xlog to tar

On Mon, Sep 5, 2016 at 10:01 AM, Michael Paquier wrote: > On Sat, Sep 3, 2016 at 10:35 PM, Magnus Hagander > wrote: > > Ugh. That would be nice to have, but I think that's outside the scope of > > this patch. > > A test for this patch that could

Re: [HACKERS] Add support for restrictive RLS policies

Hi Stephen, > 4. It will be good if we have an example for this in section > > "5.7. Row Security Policies" > > I haven't added one yet, but will plan to do so. > > I think you are going to add this in this patch itself, right? I have reviewed your latest patch and it fixes almost all my review

Re: [HACKERS] less expensive pg_buffercache on big shmem

On 09/29/2016 02:45 AM, Ivan Kartyshov wrote: > Secondly, I see this bit added to the loop over buffers: > > if (bufHdr->tag.forkNum == -1) > { > fctx->record[i].blocknum = InvalidBlockNumber; > continue; > } > > and I have no idea why this is needed (when it

Re: [HACKERS] Bug in to_timestamp().

2016-09-29 13:54 GMT+05:00 amul sul : > > On Thu, Sep 29, 2016 at 2:48 AM, Tom Lane wrote: > > > > I started looking at your 0001-to-timestamp-format-checking-v4.patch > > and this point immediately jumped out at me. Currently the code relies > > ...

Re: [HACKERS] Tuplesort merge pre-reading

On 09/28/2016 07:20 PM, Peter Geoghegan wrote: On Wed, Sep 28, 2016 at 5:11 PM, Peter Geoghegan wrote: This is why I never pursued batch memory for non-final merges. Isn't that what you're doing here? You're pretty much always setting "state->batchUsed = true". Wait. I guess

Re: [HACKERS] An extra error for client disconnection on Windows

Hello, At Tue, 13 Sep 2016 10:00:32 -0300, Alvaro Herrera wrote in <20160913130032.GA391646@alvherre.pgsql> > Michael Paquier wrote: > > On Tue, Sep 13, 2016 at 10:42 AM, Kyotaro HORIGUCHI > > wrote: > > > If we take a policy to try to

Re: [HACKERS] Bug in to_timestamp().

On Thu, Sep 29, 2016 at 2:48 AM, Tom Lane wrote: > Artur Zakirov writes: >> - now DCH_cache_getnew() is called after parse_format(). Because now >> parse_format() can raise an error and in the next attempt >> DCH_cache_search() could return broken

Re: [HACKERS] asynchronous and vectorized execution

Hello, thank you for the comment. At Fri, 23 Sep 2016 18:15:40 +0530, Amit Khandekar wrote in

Re: [HACKERS] Floating point comparison inconsistencies of the geometric types

> Well, those two results are not contradictory -- notice that you > switched the order of the values in the comparison. I don't think > you've really found the explanation yet. I am sorry I copy-pasted the wrong example: "select_views" test runs: > SELECT name, #thepath FROM iexit ORDER BY 1,

Re: [HACKERS] Renaming of pg_xlog and pg_clog

On Tue, Aug 30, 2016 at 11:04 AM, Michael Paquier wrote: > On Mon, Aug 29, 2016 at 9:39 PM, Craig Ringer > wrote: >> Cool. I'll mark as waiting on author pending that. >> >> It'll be good to get this footgun put away. > > OK, so done. I

Re: [HACKERS] IF (NOT) EXISTS in psql-completion

Hello, At Tue, 20 Sep 2016 16:50:29 +0900, Michael Paquier wrote in > On Mon, Sep 19, 2016 at 6:11 PM, Pavel Stehule > wrote: > > I am thinking so commit's description

Re: [HACKERS] "Re: Question about grant create on database and pg_dump/pg_dumpall

On Mon, Sep 26, 2016 at 2:29 PM, Rafia Sabih wrote: > On Tue, Jul 5, 2016 at 06:39 AM, Haribabu Kommi > kommi(dot)haribabu(at)gmail(dot)com wrote: > > Still i feel the GRANT statements should be present, as the create > database statement > is generated only with -C

Re: [HACKERS] WAL logging problem in 9.4.3?

On Mon, Sep 26, 2016 at 5:03 PM, Kyotaro HORIGUCHI wrote: > Hello, I return to this before my things:) > > Though I haven't played with the patch yet.. Be sure to run the test cases in the patch or base your tests on them then! > Though I don't know how it

Re: [HACKERS] Speed up Clog Access by increasing CLOG buffers

On Thu, Sep 29, 2016 at 12:56 PM, Dilip Kumar wrote: > On Thu, Sep 29, 2016 at 6:40 AM, Tomas Vondra > wrote: >> Yes, definitely - we're missing something important, I think. One difference >> is that Dilip is using longer runs, but I don't

Re: [HACKERS] Speed up Clog Access by increasing CLOG buffers

On Thu, Sep 29, 2016 at 6:40 AM, Tomas Vondra wrote: > Yes, definitely - we're missing something important, I think. One difference > is that Dilip is using longer runs, but I don't think that's a problem (as I > demonstrated how stable the results are). > > I wonder

Re: [HACKERS] IF (NOT) EXISTS in psql-completion

Thank you for reviewing! At Mon, 19 Sep 2016 11:11:03 +0200, Pavel Stehule wrote in

Re: [HACKERS] Handling dropped attributes in pglogical_proto

On 29 September 2016 at 12:53, Petr Jelinek wrote: > On 29/09/16 05:33, Michael Paquier wrote: >> On Wed, Sep 28, 2016 at 11:25 PM, Konstantin Knizhnik >> wrote: >>> But if table was just altered and some attribute was removed from the table, >>>

Re: [HACKERS] Notice lock waits

On Sat, Aug 6, 2016 at 3:00 AM, Jeff Janes wrote: > One time too many, I ran some minor change using psql on a production > server and was wondering why it was taking so much longer than it did > on the test server. Only to discover, after messing around with > opening new

  1   2   >