Re: [HACKERS] Transactions involving multiple postgres foreign servers

On Tue, Sep 27, 2016 at 2:54 PM, Masahiko Sawada wrote: > On Mon, Sep 26, 2016 at 9:07 PM, Ashutosh Bapat > wrote: >> On Mon, Sep 26, 2016 at 5:25 PM, Masahiko Sawada >> wrote: >>> On Mon, Sep 26, 2016 at 7:28 PM,

Re: [HACKERS] pageinspect: Hash index support

On 09/26/2016 10:45 PM, Peter Eisentraut wrote: On 9/26/16 1:39 PM, Jesper Pedersen wrote: Left as is, since BuildTupleFromCStrings() vs. xyzGetDatum() are equally readable in this case. But, I can change the patch if needed. The point is that to use BuildTupleFromCStrings() you need to

[HACKERS]

On Tue, Sep 27, 2016 at 3:08 PM, Robert Haas wrote: > I don't know what any of that means. You said we need something like > an LWLock, but I think we don't. The workers just write the results > of their own final merges into shm_mqs. The leader can read from any > given

[HACKERS] assert violation in logical messages serialization

Hello. During processing of logical messages in ReorderBufferSerializeChange() pointer to ondisk structure isn’t updated after possible reorder buffer realloc by ReorderBufferSerializeReserve(). Actual reason spotted by Konstantin Knizhnik. reorderbuffer.patch Description: Binary data --

Re: [HACKERS] pgbench more operators & functions

Hello Jeevan. 1. About documentation, I think it will be good idea to arrange the operators table with the precedence and add a line at top: "In decreasing order of precedence". Done, see attached. 2. You may want to remove the comment: + /* should it do a lazy evaluation of the

Re: [HACKERS] Make flex/bison checks stricter in Git trees

Daniel Gustafsson writes: > When running ./configure on a system without Flex/Bison it’s easy to miss > the > warning that flies past and then run into compilation error instead. When it > happened to a colleague yesterday a brief discussion came to the conclusion > that it

Re: [HACKERS] Password identifiers, protocol aging and SCRAM protocol

On Tue, Sep 27, 2016 at 10:42 PM, Heikki Linnakangas wrote: > The libpq-side is not. Just calling random() won't do. We haven't needed for > random numbers in libpq before, but now we do. Is the pgcrypto solution > portable enough that we can use it in libpq? Do you think that

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

On 9/26/16 2:36 AM, Michael Paquier wrote: > > Just a nit: > > - postmaster.pid > + postmaster.pid and postmaster.opts > > Having one block for each file would be better. I grouped these because they are related and because there are now other bullets where

Re: [HACKERS] WIP: Covering + unique indexes.

On Mon, Sep 26, 2016 at 11:17 AM, Anastasia Lubennikova wrote: >> Is there any fundamental problem in storing them in ordered way? I >> mean to say, you need to anyway store all the column values on leaf >> page, so why can't we find the exact location for the

Re: [HACKERS]

You seem to have erased the subject line from this email somehow. On Tue, Sep 27, 2016 at 10:18 AM, Peter Geoghegan wrote: > On Tue, Sep 27, 2016 at 3:08 PM, Robert Haas wrote: >> I don't know what any of that means. You said we need something like >> an

Re: [HACKERS] Detect supported SET parameters when pg_restore is run

On Mon, Sep 26, 2016 at 9:56 PM, Vitaly Burovoy wrote: > At work we use several major versions of PostgreSQL, and developers > use non-local clusters for developing and debugging. > We do dump/restore schemas/data via custom/dir formats and we have to > keep several

Re: [HACKERS]

On Tue, Sep 27, 2016 at 3:31 PM, Robert Haas wrote: > You seem to have erased the subject line from this email somehow. I think that that was Gmail. Maybe that's new? Generally, I have to go out of my way to change the subject line, so it seems unlikely that I fat-fingered

Re: [HACKERS] Password identifiers, protocol aging and SCRAM protocol

On 09/27/2016 04:19 PM, Michael Paquier wrote: On Tue, Sep 27, 2016 at 9:01 PM, Heikki Linnakangas wrote: * A source of random values. This currently uses PostmasterRandom() similarly to how the MD5 salt is generated, in the server, but plain old random() in the client. If

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

Robert Haas writes: > On Mon, Sep 26, 2016 at 3:06 PM, Stephen Frost wrote: >> That doesn't mean, at least to me, that we should forgo considering >> better alternatives. > I don't think so, either, but if we could agree that "Tom's patch > > doing

[HACKERS] Make flex/bison checks stricter in Git trees

When running ./configure on a system without Flex/Bison it’s easy to miss the warning that flies past and then run into compilation error instead. When it happened to a colleague yesterday a brief discussion came to the conclusion that it would be neat it the flex and bison checks took the

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

On Mon, Sep 26, 2016 at 3:06 PM, Stephen Frost wrote: > I feel like we're getting wrapped around the axle as it regards who is > perceived to be voting for what. True. It's not very clear; thanks for trying to shed some light on it. > I don't particularly care for it

Re: [HACKERS] Refactoring speculative insertion with unique indexes a little

On Tue, Sep 27, 2016 at 2:13 PM, Tom Lane wrote: > I can see the value of processing unique indexes before non-unique ones. > I'm pretty suspicious of trying to prioritize primary keys first, though, > because (a) it's not clear why bother, and (b) PG is a tad squishy about >

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

On 9/26/16 2:36 AM, Michael Paquier wrote: > Just a nit: > > - postmaster.pid > + postmaster.pid and postmaster.opts > > Having one block for each file would be better. OK, changed. > +const char *excludeFile[] = > excludeFiles[]? > > +# Move pg_replslot

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

* Tom Lane (t...@sss.pgh.pa.us) wrote: > I think the debate is more about whether moving the source display > functionality over to \sf is a better solution than rearranging \df+ > output. (If we had consensus to do that, I'd be happy to go code it, > but I'm not going to invest the effort when

Re: [HACKERS] Password identifiers, protocol aging and SCRAM protocol

On Tue, Sep 27, 2016 at 9:01 PM, Heikki Linnakangas wrote: > * Added error-handling for OOM and other errors in liybpq > * In libpq, added check that the server sent back the same client-nonce > * Turned ERRORs into COMMERRORs and removed DEBUG4 lines (they could reveal > useful

Re: [HACKERS] Parallel tuplesort (for parallel B-Tree index creation)

On Mon, Sep 26, 2016 at 3:40 PM, Peter Geoghegan wrote: > On Mon, Sep 26, 2016 at 6:58 PM, Robert Haas wrote: >>> That requires some kind of mutual exclusion mechanism, like an LWLock. >> >> No, it doesn't. Shared memory queues are single-reader,

[HACKERS] Some information about the small portion of source code of postgreSQL

Hi, I am working in optimizer module of postgreSQL 9.4.1. My project is concerned with the plan returned by the optimizer. I am trying to return a subplan for a query instead of full plan. For this I need to return a path form *RelOptInfo *standard_join_search() *at* allpaths.c *other than

Re: [HACKERS] Refactoring speculative insertion with unique indexes a little

Heikki Linnakangas writes: > On 09/24/2016 02:34 PM, Peter Geoghegan wrote: >> I go on to explain how this patch represents a partial solution to >> that [1]. That's what I mean by "useful practical consequences". As I >> say in [1], I think we could even get a full solution, if

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

Hi, I apologize in advance that the comments in this message might one of the ideas discarded in the past thread.. I might not grasp the discussion completely X( The attached patches are rebased to the master and additional one mentioned below. At Wed, 18 May 2016 17:57:49 -0400, Michael

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

On 26 September 2016 at 14:52, Dave Cramer wrote: > > > >> >> This crashes with arrays with non-default lower bounds: >> >> postgres=# SELECT * FROM test_type_conversion_array_int >> 4('[2:4]={1,2,3}'); >> INFO: ([1, 2, ], ) >> server closed the connection unexpectedly >>

Re: [HACKERS] Declarative partitioning - another take

On 2016/09/27 18:09, Ashutosh Bapat wrote: >>> I tried to debug the problem somewhat. In set_append_rel_pathlist(), >>> it finds that at least one child has a parameterized path as the >>> cheapest path, so it doesn't create an unparameterized path for append >>> rel. At the same time there is a

Re: [HACKERS] Add support for restrictive RLS policies

On Tue, Sep 27, 2016 at 12:45 PM, Jeevan Chalke < jeevan.cha...@enterprisedb.com> wrote: > Hello Stephen, > > I am reviewing the latest patch in detail now and will post my review > comments later. > Here are the review comments: 1. In documentation, we should put both permissive as well as

Re: [HACKERS] [PATCH] Generic type subscription

On Fri, 9 Sep 2016 18:29:23 +0700 Dmitry Dolgov <9erthali...@gmail.com> wrote: > Hi, > > Regarding to the previous conversations [1], [2], here is a patch > (with some improvements from Nikita Glukhov) for the generic type > subscription. It allows > to define type-specific subscription logic

Re: [HACKERS] pgbench more operators & functions

Hi, The patch has correct precedence now. Further minor comments: 1. About documentation, I think it will be good idea to arrange the operators table with the precedence and add a line at top: "In decreasing order of precedence". 2. You may want to remove the comment: + /* should it

Re: [HACKERS] typedef FileName not const?

Hi, Can we please keep this topic in one thread? Anybody motivated to apply these isn't going to have an easy time applying things, and everyone else is just having a harder time sorting through the mails. On 2016-09-27 17:08:24 -0700, Mark Dilger wrote: > along the lines of other similar

Re: [HACKERS] LLVM Address Sanitizer (ASAN) and valgrind support

On 2016-09-27 19:31:57 -0400, Tom Lane wrote: > Andres Freund writes: > > On 2016-09-28 00:23:11 +0100, Greg Stark wrote: > >> I would love to remove all the #ifdef's and have the > >> macros just be no-ops if they're compiled out for example... > > > Don't we pretty much

[HACKERS] casting away const in comparators

Friends, comparators usually take arguments like (const void *a, const void *b) and do something read-only to a and b. In our sources, we typically cast these to something else, like (char *), and do something read-only. This generates a lot of warnings if using -Wcast-qual. To fix that, I

Re: [HACKERS] typedef FileName not const?

> I think the better fix here is to simply remove the typedef. It doesn't > seem to have much of a benefit, and makes using correct types harder as > demonstrated here. We don't even use it internally in fd.c.. > Fine by me. -- Sent via pgsql-hackers mailing list

Re: [HACKERS] Detect supported SET parameters when pg_restore is run

2016-09-27 23:12 GMT+02:00 Tom Lane : > Vitaly Burovoy writes: > > On 9/27/16, Tom Lane wrote: > >> I'm not exactly convinced that you did. There's only one copy of > >> Archive->remoteVersion, and you're overwriting it long

Re: [HACKERS] Some information about the small portion of source code of postgreSQL

This mail looks exactly same as that from Shrinivas. Please check answers there. On Tue, Sep 27, 2016 at 11:32 AM, davinder singh wrote: > Hi, >I am working in optimizer module of postgreSQL 9.4.1. My project is > concerned with the plan returned by the

Re: [HACKERS] asynchronous execution

On 24 September 2016 at 06:39, Robert Haas wrote: > Since Kyotaro Horiguchi found that my previous design had a > system-wide performance impact due to the ExecProcNode changes, I > decided to take a different approach here: I created an async > infrastructure where both

Re: [HACKERS] Supporting huge pages on Windows

On Wed, Sep 28, 2016 at 1:26 PM, Tsunakawa, Takayuki wrote: >> From: pgsql-hackers-ow...@postgresql.org >> [mailto:pgsql-hackers-ow...@postgresql.org] On Behalf Of Robert Haas >> On Sun, Sep 25, 2016 at 10:45 PM, Tsunakawa, Takayuki >>

Re: [HACKERS] Some information about the small portion of source code of postgreSQL

On 2016/09/28 13:30, Ashutosh Bapat wrote: > This mail looks exactly same as that from Shrinivas. Please check answers > there. Here is a link to the discussion thread that Ashutosh is referring to:

Re: [HACKERS] Requesting some information about the small portion of source code of postgreSQL

On Tue, Sep 27, 2016 at 11:43 AM, Srinivas Karthik V wrote: > Dear PostgresSQL Hackers, >I am working in optimizer module of postgreSQL 9.4.1. I am trying to > return a subplan for a query instead of full plan.For this I need to return > an intermediate plan (or

Re: [HACKERS] Transactions involving multiple postgres foreign servers

On Tue, Sep 27, 2016 at 9:06 PM, Ashutosh Bapat wrote: > On Tue, Sep 27, 2016 at 2:54 PM, Masahiko Sawada > wrote: >> On Mon, Sep 26, 2016 at 9:07 PM, Ashutosh Bapat >> wrote: >>> On Mon, Sep 26, 2016 at

Re: [HACKERS] Tracking wait event for latches

On Wed, Sep 28, 2016 at 9:39 AM, Thomas Munro wrote: > Ok, if they really are independent then shouldn't we take advantage of > that at call sites where we might be idle but we might also be waiting > for the network? For example we could do this: > >

Re: [HACKERS] [COMMITTERS] pgsql: pg_ctl: Detect current standby state from pg_control

On Tue, Sep 27, 2016 at 9:55 AM, Michael Paquier wrote: > Seems overcomplicated to me. How about returning the control file all > the time and let the caller pfree the result? You could then use > crc_ok in pg_ctl.c's get_control_dbstate() to do the decision-making. In

Re: [HACKERS] Detect supported SET parameters when pg_restore is run

On 9/27/16, Vitaly Burovoy wrote: > On 9/27/16, Tom Lane wrote: >> (The other thing I'd want here is a --target-version option so that >> you could get the same output alterations in pg_dump or pg_restore to >> text. Otherwise it's nigh

Re: [HACKERS] Supporting huge pages on Windows

> From: pgsql-hackers-ow...@postgresql.org > [mailto:pgsql-hackers-ow...@postgresql.org] On Behalf Of Robert Haas > On Sun, Sep 25, 2016 at 10:45 PM, Tsunakawa, Takayuki > wrote: > > Credit: This patch is based on Thomas Munro's one. > > How are they different?

Re: [HACKERS] Re: [GENERAL] inconsistent behaviour of set-returning functions in sub-query with random()

Tom van Tilburg writes: > Good to know and I agree that it is not an urgent case. > I think this practice might be more common in the POSTGIS community where > there are plenty of set-returning-functions used in this way. My use was > taking a random sample of a

Re: [HACKERS] LLVM Address Sanitizer (ASAN) and valgrind support

On 2016-09-28 00:23:11 +0100, Greg Stark wrote: > On Tue, Sep 27, 2016 at 11:02 PM, Andres Freund wrote: > > Any plans to pick this up again? > > Yeah, I was just thinking I should pick this up again. > > > I vote for renaming the VALGRIND names etc. to something more

[HACKERS] typedef FileName not const?

Friends, along the lines of other similar emails from me of late, I tried to avoid casting away const when using the FileName typedef. There are several calls where a (const char *) has to be cast to (char *) due to FileName being typedef'd as non-const. But changing the typedef to const

Re: [HACKERS] gratuitous casting away const

Friends, here is another patch, this time fixing the casting away of const in the regex code. Mark Dilger regex.patch.1 Description: Binary data -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription:

Re: [HACKERS] LLVM Address Sanitizer (ASAN) and valgrind support

On Tue, Sep 27, 2016 at 11:02 PM, Andres Freund wrote: > Any plans to pick this up again? Yeah, I was just thinking I should pick this up again. > I vote for renaming the VALGRIND names etc. to something more tool-neutral. I > think it's going to be too confusing otherwise.

[HACKERS] sloppy handling of pointers

rangetypes_spgist.c contains a call to detoast a pointer which was just returned from a detoast operation. This seems to do no harm, but is to my mind a sloppy thinko. Fix attached. tsgistidx.c contains a detoast of a pointer where detoast of a datum was likely intended. Fix attached.

Re: [HACKERS] [RFC] Should we fix postmaster to avoid slow shutdown?

> From: pgsql-hackers-ow...@postgresql.org > [mailto:pgsql-hackers-ow...@postgresql.org] On Behalf Of Tom Lane > Allowing SIGQUIT to prompt fast shutdown of the stats collector seems sane, > though. Try to make sure it doesn't leave partly-written stats files > behind. The attached patch based

Re: [HACKERS] LLVM Address Sanitizer (ASAN) and valgrind support

Andres Freund writes: > On 2016-09-28 00:23:11 +0100, Greg Stark wrote: >> I would love to remove all the #ifdef's and have the >> macros just be no-ops if they're compiled out for example... > Don't we pretty much have that? I think "((void) 0)" is a more common spelling of

Re: [HACKERS] hash_create(nelem = 0) does invalid memory accesses

Andres Freund writes: > debugging a citus valgrind bleat I noticed that hash_create() accesses > the result of palloc(0) as an hash element: > Do we consider this an API usage error that we want to fix? I think Assert(nelem > 0) would be an appropriate response. There are

Re: [HACKERS] Tracking wait event for latches

On Mon, Sep 26, 2016 at 7:07 PM, Michael Paquier wrote: > On Mon, Sep 26, 2016 at 1:46 PM, Thomas Munro > wrote: >> If the class really is strictly implied by the WaitEventIdentifier, >> then do we really need to supply it everywhere when

Re: [HACKERS] Transactions involving multiple postgres foreign servers

On Tue, Sep 27, 2016 at 6:24 PM, Masahiko Sawada wrote: > * Providing the prepare id of 2PC. > Current patch adds new API prepare_id_provider() but we can use the > prepare id of 2PC that is used on parent server. And we assume that when this is used across many servers

Re: [HACKERS] make async slave to wait for lsn to be replayed

On Thu, Sep 15, 2016 at 2:41 PM, Thomas Munro wrote: > On Thu, Sep 1, 2016 at 2:16 AM, Ivan Kartyshov > wrote: >> Hi hackers, >> >> Few days earlier I've finished my work on WAITLSN statement utility, so I’d >> like to share it. >> [...]

Re: [HACKERS] Detect supported SET parameters when pg_restore is run

On 9/27/16, Tom Lane wrote: > Vitaly Burovoy writes: >> On 9/27/16, Tom Lane wrote: >>> I'm not exactly convinced that you did. There's only one copy of >>> Archive->remoteVersion, and you're overwriting it long before the >>>

Re: [HACKERS] LLVM Address Sanitizer (ASAN) and valgrind support

Hi, On 2015-09-07 17:05:10 +0100, Greg Stark wrote: > I feel like I remember hearing about this before but I can't find any > mention of it in my mail archives. It seems pretty simple to add > support for LLVM's Address Sanitizer (asan) by using the hooks we > already have for valgrind. Any

[HACKERS] hash_create(nelem = 0) does invalid memory accesses

Hi, debugging a citus valgrind bleat I noticed that hash_create() accesses the result of palloc(0) as an hash element: HTAB * hash_create(const char *tabname, long nelem, HASHCTL *info, int flags) { ... if ((flags & HASH_SHARED_MEM) || nelem < hctl->nelem_alloc) {

[HACKERS] should xlog_outdesc modify its argument?

The function static void xlog_outdesc(StringInfo buf, XLogReaderState *record); in src/backend/access/transam/xlog.c is called by XLogInsertRecord, and after returning a string describing an XLogRecord, it clears the state data in its XLogReaderState argument. That mixes the read-only

Re: [HACKERS] Declarative partitioning - another take

>> >> Please check if you are able to reproduce these errors in your >> repository. I made sure that I cleaned up all partition-wise join code >> before testing this, but ... . > > Thanks for the test case. I can reproduce the same. > >> I tried to debug the problem somewhat. In

Re: [HACKERS] Declarative partitioning - another take

On 2016/09/27 15:44, Ashutosh Bapat wrote: >> By the way, I fixed one thinko in your patch as follows: >> >> -result->oids[i] = oids[mapping[i]]; >> +result->oids[mapping[i]] = oids[i]; > > While I can not spot any problem with this logic, when I make that > change and run

Re: [HACKERS] Declarative partitioning - another take

On Tue, Sep 27, 2016 at 2:46 PM, Amit Langote wrote: > On 2016/09/27 15:44, Ashutosh Bapat wrote: >>> By the way, I fixed one thinko in your patch as follows: >>> >>> -result->oids[i] = oids[mapping[i]]; >>> +result->oids[mapping[i]] = oids[i]; >> >>

[HACKERS] Re: [GENERAL] inconsistent behaviour of set-returning functions in sub-query with random()

Good to know and I agree that it is not an urgent case. I think this practice might be more common in the POSTGIS community where there are plenty of set-returning-functions used in this way. My use was taking a random sample of a pointcloud distrubution. I took the liberty to post your answer at

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

On Sun, 25 Sep 2016 17:31:53 +0530 Mithun Cy wrote: > I have some more comments on libpq-failover-8.patch > > + /* FIXME need to check that port is numeric */ > > Is this still applicable?. > Unfortunately, it was. I've fixed this problem in 9-th version of patch

Re: [HACKERS] Transactions involving multiple postgres foreign servers

On Mon, Sep 26, 2016 at 9:07 PM, Ashutosh Bapat wrote: > On Mon, Sep 26, 2016 at 5:25 PM, Masahiko Sawada > wrote: >> On Mon, Sep 26, 2016 at 7:28 PM, Ashutosh Bapat >> wrote: >>> My original patch added

Re: [HACKERS] Write Ahead Logging for Hash Indexes

On 09/25/2016 01:00 AM, Amit Kapila wrote: Attached patch fixes the problem, now we do perform full page writes for bitmap pages. Apart from that, I have rebased the patch based on latest concurrent index patch [1]. I have updated the README as well to reflect the WAL logging related

Re: [HACKERS] Redesigning parallel dump/restore's wait-for-workers logic

Kevin Grittner writes: > This patch applies with a few minor offsets, compiles without > warning, and passes all regression tests including `make > check-world` with TAP tests enabled. This and the related patch > dealing with the parallel API definitely make things cleaner

Re: [HACKERS] Supporting huge pages on Windows

On Sun, Sep 25, 2016 at 10:45 PM, Tsunakawa, Takayuki wrote: > Credit: This patch is based on Thomas Munro's one. How are they different? -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers

Re: [HACKERS] Detect supported SET parameters when pg_restore is run

Robert Haas writes: > On Mon, Sep 26, 2016 at 9:56 PM, Vitaly Burovoy > wrote: >> We do dump/restore schemas/data via custom/dir formats and we have to >> keep several client versions for 9.2, 9.4 and 9.5 versions on local >> workstations because

Re: [HACKERS] Redesigning parallel dump/restore's wait-for-workers logic

This patch applies with a few minor offsets, compiles without warning, and passes all regression tests including `make check-world` with TAP tests enabled. This and the related patch dealing with the parallel API definitely make things cleaner and easier to follow. I find it disappointing that

Re: [HACKERS] Fix some corner cases that cube_in rejects

Amul Sul writes: > The following review has been posted through the commitfest application: > make installcheck-world: tested, passed > Implements feature: tested, passed > Spec compliant: tested, passed > Documentation:not tested > Note for

Re: [HACKERS] Password identifiers, protocol aging and SCRAM protocol

On 9/26/16 2:02 AM, Michael Paquier wrote: > On Mon, Sep 26, 2016 at 2:15 AM, David Steele wrote: > > Thanks for the review and the comments! > >> I notice that the copyright from pgcrypto/sha1.c was carried over but >> not the copyright from pgcrypto/sha2.c. I'm no expert

[HACKERS] Requesting some information about the small portion of source code of postgreSQL

Dear PostgresSQL Hackers, I am working in optimizer module of postgreSQL 9.4.1. I am trying to return a subplan for a query instead of full plan. For this I need to return an intermediate plan (or path) from the DP lattice (i.e. from *RelOptInfo *standard_join_search() *at* allpaths.c)

Re: [HACKERS] Remove superuser() checks from pgstattuple

On Tue, Sep 27, 2016 at 4:43 AM, Stephen Frost wrote: > * Peter Eisentraut (peter.eisentr...@2ndquadrant.com) wrote: >> This is now being obsoleted by the later idea of allowing base installs >> from a chain of upgrade scripts. But if your upgrade scripts contain >> ALTER

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

On Thu, May 19, 2016 at 6:57 AM, Michael Paquier wrote: > I am adding that to the commit fest of September. And a lot of activity has happened here since. Attached are refreshed patches based on da6c4f6. v11 still applies correctly but it's always better to avoid hunks

Re: [HACKERS] Requesting some information about the small portion of source code of postgreSQL

On 27 September 2016 at 14:13, Srinivas Karthik V wrote: > Dear PostgresSQL Hackers, >I am working in optimizer module of postgreSQL 9.4.1. Why would you target a severely obsolete patch release? > Also I would like to know for what targetlist stands for. Can't

Re: [HACKERS] Declarative partitioning - another take

> > With this patch, the mapping is created *only once* during > RelationBuildPartitionDesc() to assign canonical indexes to individual > list values. The partition OID array will also be rearranged such that > using the new (canonical) index instead of the old > catalog-scan-order-based index

Re: [HACKERS] Misdesigned command/status APIs for parallel dump/restore

This patch also applied with minor offsets, compiled without warning, and passes regression tests, including `make check-world` with TAP tests enabled. It looks good to me, presenting a cleaner API. I really want to get this to the point where we can dump and restore nested materialized views

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

On Fri, Sep 9, 2016 at 4:25 PM, Kevin Grittner wrote: > On Sun, Sep 4, 2016 at 12:42 PM, Emre Hasegeli wrote: > These patches apply and build on top of 5c609a74 with no problems, > but `make check` finds differences per the attached. Please > investigate

Re: [HACKERS] Detect supported SET parameters when pg_restore is run

On 9/27/16, Tom Lane wrote: > Robert Haas writes: >> On Mon, Sep 26, 2016 at 9:56 PM, Vitaly Burovoy >> wrote: >>> We do dump/restore schemas/data via custom/dir formats and we have to >>> keep several client versions for 9.2,

Re: [HACKERS] Partition-wise join for join between (declaratively) partitioned tables

On Thu, Sep 22, 2016 at 6:41 AM, Ashutosh Bapat wrote: > [ new patch ] This should probably get updated since Rajkumar reported a crash. Meanwhile, here are some comments from an initial read-through: + * Multiple relations may be partitioned in the same way.

Re: [HACKERS] Refactoring speculative insertion with unique indexes a little

On Tue, Sep 27, 2016 at 9:10 AM, Heikki Linnakangas wrote: > Hmm, yeah, that'd be nice to fix. I'd like to see a patch specifically to > fix that. I'm not convinced that we need all the complications of this > patch, to get that fixed. (In particular, indexam's still wouldn't

Re: [HACKERS] Refactoring speculative insertion with unique indexes a little

On 09/27/2016 11:22 AM, Peter Geoghegan wrote: On Tue, Sep 27, 2016 at 9:10 AM, Heikki Linnakangas wrote: Hmm, yeah, that'd be nice to fix. I'd like to see a patch specifically to fix that. I'm not convinced that we need all the complications of this patch, to get that fixed.

Re: [HACKERS] Refactoring speculative insertion with unique indexes a little

On Tue, Sep 27, 2016 at 9:25 AM, Heikki Linnakangas wrote: > I didn't think very hard about it, but yeah, think so.. Do you think it's worth a backpatch? Or, too early to tell? -- Peter Geoghegan -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make

Re: [HACKERS] Declarative partitioning - another take

Sorry about the delay in replying. On 2016/09/15 21:58, Ashutosh Bapat wrote: > Hi Amit, > > It looks like there is some problem while creating paramterized paths > for multi-level partitioned tables. Here's a longish testcase > > [ ... ] > > Please check if you are able to reproduce these

Re: [HACKERS] Refactoring speculative insertion with unique indexes a little

On 09/27/2016 11:38 AM, Peter Geoghegan wrote: On Tue, Sep 27, 2016 at 9:25 AM, Heikki Linnakangas wrote: I didn't think very hard about it, but yeah, think so.. Do you think it's worth a backpatch? Or, too early to tell? Too early to tell.. - Heikki -- Sent via

Re: [HACKERS] Add support for restrictive RLS policies

Hello Stephen, On Tue, Sep 27, 2016 at 12:57 AM, Stephen Frost wrote: > Jeevan, > > * Jeevan Chalke (jeevan.cha...@enterprisedb.com) wrote: > > I have started reviewing this patch and here are couple of points I have > > observed so far: > > > > 1. Patch applies cleanly > >

Re: [HACKERS] Fix some corner cases that cube_in rejects

The following review has been posted through the commitfest application: make installcheck-world: tested, passed Implements feature: tested, passed Spec compliant: tested, passed Documentation:not tested Note for committer : There are unnecessary files (cube_1.out,

Re: [HACKERS] Refactoring speculative insertion with unique indexes a little

On 09/24/2016 02:34 PM, Peter Geoghegan wrote: On Tue, Sep 20, 2016 at 8:55 AM, Heikki Linnakangas wrote: Likewise, in ExecInsertIndexTuples(), this makes the deferred-index case work slightly differently from speculative insertion. It's not a big difference, but it again

Re: [HACKERS] Detect supported SET parameters when pg_restore is run

Vitaly Burovoy writes: > On 9/27/16, Tom Lane wrote: >> The general policy has always been that pg_dump output is only expected to >> restore without errors into a server that's the same or newer version as >> pg_dump (regardless of the server

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

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 test_type_conversion_array_int 4('[2:4]={1,2,3}'); INFO: ([1, 2, ], ) server closed the connection

Re: [HACKERS] Hash Indexes

On 09/20/2016 09:02 AM, Amit Kapila wrote: On Fri, Sep 16, 2016 at 11:22 AM, Amit Kapila wrote: I do want to work on it, but it is always possible that due to some other work this might get delayed. Also, I think there is always a chance that while doing that work,

Re: [HACKERS] Make flex/bison checks stricter in Git trees

> On 27 Sep 2016, at 15:49, Tom Lane wrote: > > Daniel Gustafsson writes: >> When running ./configure on a system without Flex/Bison it’s easy to miss the >> warning that flies past and then run into compilation error instead. When it >> happened to a

Re: [HACKERS] to_date_valid()

Peter Eisentraut writes: > I think using ValidateDate() was the right idea. That is what we use > for checking date validity everywhere else. Note that we've got two different CF entries, and threads, covering fundamentally the same territory here, ie making

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

On 09/26/2016 08:48 PM, Tomas Vondra wrote: On 09/26/2016 07:16 PM, Tomas Vondra wrote: The averages (over the 10 runs, 5 minute each) look like this: 3.2.80 1 8 16 32 64128192

Re: [HACKERS] Detect supported SET parameters when pg_restore is run

On 9/27/16, Tom Lane wrote: > Vitaly Burovoy writes: >> On 9/27/16, Tom Lane wrote: >>> The general policy has always been that pg_dump output is only expected >>> to >>> restore without errors into a server that's the same or

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

On 9/27/16 6:16 AM, Kyotaro HORIGUCHI wrote: I apologize in advance that the comments in this message might one of the ideas discarded in the past thread.. I might not grasp the discussion completely X( The attached patches are rebased to the master and additional one mentioned below. I

Re: [HACKERS] Detect supported SET parameters when pg_restore is run

Vitaly Burovoy writes: > On 9/27/16, Tom Lane wrote: >> I'm not exactly convinced that you did. There's only one copy of >> Archive->remoteVersion, and you're overwriting it long before the >> dump process is over. > It does not seem that I'm

Re: [HACKERS] Add support for restrictive RLS policies

Jeevan, * Jeevan Chalke (jeevan.cha...@enterprisedb.com) wrote: > Here are the review comments: [... many good comments ...] Many thanks for the review, I believe I agree with pretty much all your comments and will update the patch accordingly. Responses for a couple of them are below. > 6. I

  1   2   >