Re: [HACKERS] Missing comment for max_logical_replication_workers in postgresql.conf.sample

On Thu, Jul 27, 2017 at 10:14 AM, Yugo Nagata wrote: > Hi, > > I found that postgresql.conf.sample is missing a comment > to note that changing max_logical_replication_workers requires > restart of the server. > > Other such parameters has the comments, so I think the new >

Re: [HACKERS] Log LDAP "diagnostic messages"?

On Wed, Jul 26, 2017 at 10:40 PM, Ashutosh Bapat wrote: > On Wed, Jul 26, 2017 at 6:51 AM, Thomas Munro > wrote: >> Something like the attached. > > The patch prints errdetail() as "No LDAP diagnostic message > available." when LDAP

[HACKERS] A couple of postgresql.conf.sample discrepancies

Hi hackers, Here's a script that reminds you about GUCs you forgot to put in postgresql.conf.sample. It probably needs some work. Does this already happen somewhere else? I guess not, because it found two discrepancies: $ ./src/tools/check_sample_config.pl enable_gathermerge appears in guc.c

Re: [HACKERS] Transactions involving multiple postgres foreign servers

On Thu, Jul 27, 2017 at 10:28 AM, Robert Haas wrote: > On Fri, Apr 7, 2017 at 10:56 AM, Masahiko Sawada > wrote: >> Vinayak, why did you marked this patch as "Move to next CF"? AFAIU >> there is not discussion yet. > > I'd like to discuss this

Re: [HACKERS] expand_dbname in postgres_fdw

On Thu, Jul 27, 2017 at 12:21 AM, Tom Lane wrote: > Robert Haas writes: >> On Wed, Jul 26, 2017 at 5:38 AM, Ashutosh Bapat >> wrote: >>> According to F.34.1.1 at [1] passing connection string as dbname >>> option should

Re: [HACKERS] AdvanceXLInsertBuffer vs. WAL segment compressibility

On 07/17/17 11:29, Michael Paquier wrote: > FWIW, I would rather see any optimization done in > AdvanceXLInsertBuffer() instead of seeing a second memset re-zeroing > the WAL page header after its data has been initialized by > AdvanceXLInsertBuffer() once. Is that an aesthetic 'rather', or is

Re: [HACKERS] pg_stop_backup(wait_for_archive := true) on standby server

On Fri, Jul 21, 2017 at 07:04:32PM -0400, Stephen Frost wrote: > Masahiko, all, > > * Masahiko Sawada (sawada.m...@gmail.com) wrote: > > On Tue, Jul 18, 2017 at 1:28 PM, Stephen Frost wrote: > > > Masahiko, Michael, > > > > > > * Masahiko Sawada (sawada.m...@gmail.com) wrote:

Re: [HACKERS] segfault in HEAD when too many nested functions call

On Mon, Jul 24, 2017 at 08:04:30AM +0100, Andres Freund wrote: > > > On July 24, 2017 7:10:19 AM GMT+01:00, Noah Misch wrote: > >On Tue, Jul 18, 2017 at 01:04:10PM -0700, Andres Freund wrote: > >> Ok, I'll flesh out the patch till Thursday. But I do think we're > >going > >>

Re: [HACKERS] A bug in mapping attributes in ATExecAttachPartition()

Thanks for looking at this again. On 2017/07/26 23:31, Ashutosh Bapat wrote: > On Wed, Jul 12, 2017 at 7:17 AM, Amit Langote > wrote: >> >> Thanks for the review. Patch updated taking care of the comments. > > The patches still apply and compile. make check runs

Re: [HACKERS] Transactions involving multiple postgres foreign servers

On Fri, Apr 7, 2017 at 10:56 AM, Masahiko Sawada wrote: > Vinayak, why did you marked this patch as "Move to next CF"? AFAIU > there is not discussion yet. I'd like to discuss this patch. Clearly, a lot of work has been done here, but I am not sure about the approach. If

[HACKERS] Missing comment for max_logical_replication_workers in postgresql.conf.sample

Hi, I found that postgresql.conf.sample is missing a comment to note that changing max_logical_replication_workers requires restart of the server. Other such parameters has the comments, so I think the new parameter also needs this. Attached is a simple patch to fix this. Regards, -- Yugo

Re: [HACKERS] Refreshing subscription relation state inside a transaction block

On Wed, Jul 26, 2017 at 10:29 PM, Robert Haas wrote: > On Mon, Jun 19, 2017 at 4:30 AM, Masahiko Sawada > wrote: >>> I think that either of the options you suggested now would be better. >>> We'll need that for stopping the tablesync which is in

Re: [HACKERS] More race conditions in logical replication

Alvaro Herrera wrote: > Hmm, yeah, that's not good. However, I didn't like the idea of putting > it inside the locked area, as it's too much code. Instead I added just > before acquiring the spinlock. We cancel the sleep unconditionally > later on if we didn't need to sleep after all. I just

Re: [HACKERS] asynchronous execution

Robert Haas writes: > Ostensibly, the advantage of this framework over my previous proposal > is that it avoids inserting anything into ExecProcNode(), which is > probably a good thing to avoid given how frequently ExecProcNode() is > called. Unless the parent and the

Re: [HACKERS] bug in locking an update tuple chain

> The attached patch fixes the problem. When locking some old tuple version of > the chain, if we detect that we already hold that lock > (test_lockmode_for_conflict returns HeapTupleSelfUpdated), do not try to lock > it again but instead skip ahead to the next version. This fixes the synthetic

Re: [HACKERS] asynchronous execution

On Tue, Jul 25, 2017 at 5:11 AM, Kyotaro HORIGUCHI wrote: > [ new patches ] I spent some time today refreshing my memory of what's going with this thread today. Ostensibly, the advantage of this framework over my previous proposal is that it avoids inserting

Re: [HACKERS] pg_dump does not handle indirectly-granted permissions properly

Stephen Frost writes: > * Tom Lane (t...@sss.pgh.pa.us) wrote: >> AFAICT, pg_dump has no notion that it needs to be careful about the order >> in which permissions are granted. I did > I'm afraid that's correct, though I believe that's always been the case. > I spent some

Re: [HACKERS] segfault in HEAD when too many nested functions call

Andres Freund writes: > On 2017-07-26 15:03:37 -0400, Tom Lane wrote: >> Hm, that seems kinda backwards to me; I was envisioning the checks >> moving to the callees not the callers. I think it'd end up being >> about the same number of occurrences of CHECK_FOR_INTERRUPTS(),

Re: [HACKERS] Testlib.pm vs msys

On 07/26/2017 11:12 AM, Tom Lane wrote: > Andrew Dunstan writes: > >>> I still find this pretty ugly :-(. >> I'm open to alternative suggestions. But I don't want to spend a heck of >> a lot of time on this. > Well, let's at least do the temp files a little more

Re: [HACKERS] segfault in HEAD when too many nested functions call

On 2017-07-26 15:03:37 -0400, Tom Lane wrote: > Andres Freund writes: > > I've moved the CHECK_FOR_INTERRUPTS() to the callsites. That > > unsurprisingly ends up being somewhat verbose, and there's a bunch of > > minor judgement calls where exactly to place them. While doing

Re: [HACKERS] pg_dump does not handle indirectly-granted permissions properly

Tom, * Tom Lane (t...@sss.pgh.pa.us) wrote: > AFAICT, pg_dump has no notion that it needs to be careful about the order > in which permissions are granted. I did I'm afraid that's correct, though I believe that's always been the case. I spent some time looking into this today and from what I've

Re: [HACKERS] segfault in HEAD when too many nested functions call

Andres Freund writes: > I've moved the CHECK_FOR_INTERRUPTS() to the callsites. That > unsurprisingly ends up being somewhat verbose, and there's a bunch of > minor judgement calls where exactly to place them. While doing so I've > also added a few extra ones. Did this in a

Re: [HACKERS] expand_dbname in postgres_fdw

Robert Haas writes: > On Wed, Jul 26, 2017 at 5:38 AM, Ashutosh Bapat > wrote: >> According to F.34.1.1 at [1] passing connection string as dbname >> option should work, so your question is valid. I am not aware of any >> discussion around

Re: [HACKERS] expand_dbname in postgres_fdw

Robert Haas wrote: > On Wed, Jul 26, 2017 at 5:38 AM, Ashutosh Bapat > wrote: > > According to F.34.1.1 at [1] passing connection string as dbname > > option should work, so your question is valid. I am not aware of any > > discussion around this on hackers.

Re: [HACKERS] Change in "policy" on dump ordering?

I thought of a quite different way that we might attack this problem, but I'm not sure if it's worth pursuing or not. The idea is basically that we should get rid of the existing kluge for pushing ACLs to the end altogether, and instead rely on dependency sorting to make things work. This'd

Re: [HACKERS] expand_dbname in postgres_fdw

On Wed, Jul 26, 2017 at 5:38 AM, Ashutosh Bapat wrote: > According to F.34.1.1 at [1] passing connection string as dbname > option should work, so your question is valid. I am not aware of any > discussion around this on hackers. Comments in connect_pg_server() >

Re: [HACKERS] Increase Vacuum ring buffer.

On 2017-07-26 19:46, Claudio Freire wrote: On Wed, Jul 26, 2017 at 1:39 PM, Sokolov Yura wrote: On 2017-07-24 12:41, Sokolov Yura wrote: test_master_1/pretty.log ... time activity tps latency stddev min max 11130 av+ch 198198ms

Re: [HACKERS] bug in locking an update tuple chain

Amit Kapila wrote: > On Sat, Jul 15, 2017 at 2:30 AM, Alvaro Herrera > wrote: > > a transaction wants to lock the > > updated version of some tuple, and it does so; and some other > > transaction is also locking the same tuple concurrently in a compatible > > way. So

Re: [HACKERS] [patch] pg_dump/pg_restore zerror() and strerror() mishap

Hello Alvaro, thanks for the feedback, fixed all of your points. Attached new version of patch. -- Best regards, Vladimir Kunschikov Lead software developer IDS project InfoTeCS JSC From: Alvaro Herrera Sent: Wednesday, July 26,

Re: [HACKERS] Change in "policy" on dump ordering?

On Wed, Jul 26, 2017 at 9:30 AM, Tom Lane wrote: > Meanwhile, we have problems that bite people who aren't doing anything > stranger than having a matview owned by a non-superuser. How do you > propose to fix that without reordering pg_dump's actions? Obviously changing the

Re: [HACKERS] Proposal: Improve bitmap costing for lossy pages

On Thu, Jun 8, 2017 at 10:44 AM, Dilip Kumar wrote: > On Thu, May 18, 2017 at 8:07 PM, Robert Haas wrote: > > Thanks for the feedback and sorry for the delayed response. > >> You might need to adjust effective_cache_size. > > You are right. But,

Re: [HACKERS] Increase Vacuum ring buffer.

On Wed, Jul 26, 2017 at 1:39 PM, Sokolov Yura wrote: > On 2017-07-24 12:41, Sokolov Yura wrote: > test_master_1/pretty.log ... > time activity tps latency stddev min max > 11130 av+ch 198198ms374ms 7ms 1956ms > 11160

Re: [HACKERS] [patch] pg_dump/pg_restore zerror() and strerror() mishap

Kunshchikov Vladimir wrote: > Hello Alvaro, thanks for the feedback, fixed all of your points. > Attached new version of patch. Looks great -- it's a lot smaller than the original even. One final touch -- see cfread(), where we have an #ifdef where we test for fp->compressedfp; the "#else"

Re: [HACKERS] proposal: psql: check env variable PSQL_PAGER

Hi 2017-07-26 13:15 GMT+02:00 Dagfinn Ilmari Mannsåker : > Pavel Stehule writes: > > > Hi > > > > I wrote a special pager for psql. Surely, this pager is not good for > paging > > of man pages. So is not good to set it as global pager. We can

Re: [HACKERS] pg_dump does not handle indirectly-granted permissions properly

... btw, while you're working on this, it'd be nice if you fixed the header comment for dumpACL(). It is unintelligible as to what racls is, and apparently feels that it need not discuss initacls or initracls at all. I can't say that the reference to "fooacl" is really obvious either.

Re: [HACKERS] Remove old comments in dependencies.c and README.dependencies

atorikoshi wrote: > Attached patch removes the comments about min_group_size. Agreed. Removed those comments. Thanks for the patch. -- Álvaro Herrerahttps://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services -- Sent via pgsql-hackers

[HACKERS] [GSOC] Eliminate O(N^2) scaling from rw-conflict tracking in serializable transactions

Hi, all. There was a very strange phenomenon I couldn't explain. So I was wondering if you can help me. I was trying to replace the linked list with a skip list in serializable transaction object for faster conflict tracking. But the performance is bad. So I used the instruction "rdtsc" to

Re: [HACKERS] Change in "policy" on dump ordering?

Jordan Gigov writes: > But why should a superuser need the ACL to be applied before being allowed > access? If you make the permission-checking function check if the user is a > superuser before looking for per-user grants, wouldn't that solve the issue? The superuser's

Re: [HACKERS] AlterUserStmt anmd RoleSpec rules in grammar.y

Pavel Golub writes: > I need someone to throw some light on grammar (gram.y). > I'm investigating beta2 regression tests, and found new statement > `ALTER USER ALL SET application_name to 'SLAP';` > ^^^ You'll notice that that statement fails in the regression

[HACKERS] GSoC 2017: weekly progress reports (week 8)

Project: Explicitly support predicate locks in index AMs besides b-tree Hi, During this week, I worked on predicate locking in spgist index. I think, for spgist index, predicate lock only on leaf pages will be enough as spgist searches can determine if there is a match or not only at leaf level.

Re: [HACKERS] Testlib.pm vs msys

Andrew Dunstan writes: > On 07/26/2017 09:33 AM, Tom Lane wrote: >> It might be interesting to look into its copy of IPC::Run and see if >> the wait technology is different from later versions. > It's using 0.94 just like my Linux box. Oh well, I hoped maybe we

Re: [HACKERS] UPDATE of partition key

On 26 July 2017 at 02:37, Robert Haas wrote: > Is there any real benefit in this "walker" interface? It looks to me > like it might be simpler to just change things around so that it > returns a list of OIDs, like find_all_inheritors, but generated > differently. Then if

[HACKERS] tab complete for psql pset pager values

Hi attached trivial patch for missing tab complete for \pset pager setting Regards Pavel diff --git a/src/bin/psql/tab-complete.c b/src/bin/psql/tab-complete.c index e9fdc908c7..1b15c5b0d1 100644 --- a/src/bin/psql/tab-complete.c +++ b/src/bin/psql/tab-complete.c @@ -3536,6 +3536,8 @@

Re: [HACKERS] pg_upgrade failed with error - ERROR: column "a" in child table must be marked NOT NULL

On Wed, Jul 26, 2017 at 4:02 PM, Tom Lane wrote: > Not sure what's involved there code-wise, though, nor whether we'd want > to back-patch. I'll try to look at the code around that to come up with a clear conclusion in the next couple of days, likely more as that's a vacation

Re: [HACKERS] A bug in mapping attributes in ATExecAttachPartition()

On Wed, Jul 12, 2017 at 7:17 AM, Amit Langote wrote: > > Thanks for the review. Patch updated taking care of the comments. The patches still apply and compile. make check runs well. I do not have any further review comments. Given that they address a bug, should

Re: [HACKERS] pl/perl extension fails on Windows

On Wed, Jul 26, 2017 at 8:51 AM, Tom Lane wrote: > Robert Haas writes: >> Based on discussion downthread, it seems like what we actually need to >> do is update perl.m4 to extract CCFLAGS. Turns out somebody proposed >> a patch for that back in 2002:

Re: [HACKERS] [PATCH v3] pg_progress() SQL function to monitor progression of long running SQL queries/utilities

2017-07-26 15:27 GMT+02:00 Robert Haas : > On Wed, Jun 21, 2017 at 10:01 AM, Remi Colinet > wrote: > > test=# SELECT pid, ppid, bid, concat(repeat(' ', 3 * indent),name), > value, > > unit FROM pg_progress(0,0); > > pid | ppid | bid |

[HACKERS] AlterUserStmt anmd RoleSpec rules in grammar.y

Hello, hackers. I need someone to throw some light on grammar (gram.y). I'm investigating beta2 regression tests, and found new statement `ALTER USER ALL SET application_name to 'SLAP';` ^^^ I know for sure that in beta1 this operator fails. So I decided to recheck gram.y:

Re: [HACKERS] Change in "policy" on dump ordering?

But why should a superuser need the ACL to be applied before being allowed access? If you make the permission-checking function check if the user is a superuser before looking for per-user grants, wouldn't that solve the issue? On 26 July 2017 at 16:30, Tom Lane wrote: >

Re: [HACKERS] pg_upgrade failed with error - ERROR: column "a" in child table must be marked NOT NULL

Michael Paquier writes: > The documentation says the following: > https://www.postgresql.org/docs/9.3/static/ddl-inherit.html > All check constraints and not-null constraints on a parent table are > automatically inherited by its children. Other types of constraints >

Re: [HACKERS] HACKERS[PATCH] split ProcArrayLock into multiple parts

On Fri, Jun 9, 2017 at 2:39 PM, Jim Van Fleet wrote: > I left out the retry in LWLockAcquire. If you want this to be considered, you should add it to the next CommitFest, currently https://commitfest.postgresql.org/14/ However, I can't see this being acceptable in the

Re: [HACKERS] Testlib.pm vs msys

On 07/26/2017 09:33 AM, Tom Lane wrote: > Andrew Dunstan writes: > >> The latter fact makes me >> theorize that the problem arises from the fairly ancient perl that Msys >> provides, and which we need to use to run prove so the TAP tests >> understand the

Re: [HACKERS] Default Partition for Range

Hi Beena, I have posted the rebased patches[1] for default list partition. Your patch also needs a rebase. [1] https://www.postgresql.org/message-id/CAOgcT0OVwDu%2BbeChWb5R5s6rfKLCiWcZT5617hqu7T3GdA1hAw%40mail.gmail.com Regards, Jeevan Ladhe On Fri, Jul 14, 2017 at 3:28 PM, Beena Emerson

Re: [HACKERS] Update comments in nodeModifyTable.c

On Wed, Jun 14, 2017 at 10:40 PM, Etsuro Fujita wrote: > Agreed, but I think it's better to add that detail to this comment in > ExecInitModifyTable: > > * Initialize the junk filter(s) if needed. INSERT queries need a > filter > * if there are any junk

Re: [HACKERS] Testlib.pm vs msys

Andrew Dunstan writes: > This made no difference. And I'm not really surprised, since the test is > not hanging when run from an MSVC build. Oh well. > The latter fact makes me > theorize that the problem arises from the fairly ancient perl that Msys > provides,

Re: [HACKERS] Change in "policy" on dump ordering?

Robert Haas writes: > On Tue, Jul 25, 2017 at 10:45 PM, Tom Lane wrote: >> Instead, I've prepared the attached draft patch, which addresses the >> problem by teaching pg_backup_archiver.c to process TOC entries in >> three separate passes, "main" then

Re: [HACKERS] Refreshing subscription relation state inside a transaction block

On Mon, Jun 19, 2017 at 4:30 AM, Masahiko Sawada wrote: >> I think that either of the options you suggested now would be better. >> We'll need that for stopping the tablesync which is in progress during >> DropSubscription as well as those will currently still keep running.

Re: [HACKERS] [PATCH v3] pg_progress() SQL function to monitor progression of long running SQL queries/utilities

On Wed, Jun 21, 2017 at 10:01 AM, Remi Colinet wrote: > test=# SELECT pid, ppid, bid, concat(repeat(' ', 3 * indent),name), value, > unit FROM pg_progress(0,0); > pid | ppid | bid | concat | value | unit >

Re: [HACKERS] pg_stop_backup(wait_for_archive := true) on standby server

All, * Masahiko Sawada (sawada.m...@gmail.com) wrote: > On Tue, Jul 25, 2017 at 4:43 AM, Michael Paquier > wrote: > > On Mon, Jul 24, 2017 at 6:45 PM, Stephen Frost wrote: > >> What the change would do is make the pg_stop_backup() caller block

Re: [HACKERS] Patch: Write Amplification Reduction Method (WARM)

On Tue, Apr 18, 2017 at 4:25 AM, Pavan Deolasee wrote: > I'll include the fix in the next set of patches. I haven't see a new set of patches. Are you intending to continue working on this? -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise

Re: [HACKERS] Testlib.pm vs msys

On 07/25/2017 02:45 PM, Andrew Dunstan wrote: >> Anyway, if we believe that it broke with f13ea95f9, hen it's plausible >> that CMD.EXE has been sharing pg_ctl's stdout/stderr all along, and we >> just had not noticed before. Could you check what happens if we >> change the bInheritHandles

Re: [HACKERS] pg_upgrade failed with error - ERROR: column "a" in child table must be marked NOT NULL

On Wed, Jul 26, 2017 at 12:09 PM, tushar wrote: > v9.5/9.6 > > create these objects - > CREATE TABLE constraint_rename_test (a int CONSTRAINT con1 CHECK (a > 0), b > int, c int); > CREATE TABLE constraint_rename_test2 (a int CONSTRAINT con1 CHECK (a > 0), d > int)

Re: [HACKERS] Change in "policy" on dump ordering?

On Tue, Jul 25, 2017 at 10:45 PM, Tom Lane wrote: > Instead, I've prepared the attached draft patch, which addresses the > problem by teaching pg_backup_archiver.c to process TOC entries in > three separate passes, "main" then ACLs then matview refreshes. > It's survived light

Re: [HACKERS] pg_dump issues

Hello, 25.07.2017, 11:17, "Victor Drobny" : > > Hello, > > Do you expect to have some flag like '--rename=test->test2'? Yes, I do. > Will dump with test replaced by test2(of course only in related places) > be valid dump in this case? Yes, it will. > What is the

Re: [HACKERS] proposal: psql: check env variable PSQL_PAGER

Pavel Stehule writes: > Hi > > I wrote a special pager for psql. Surely, this pager is not good for paging > of man pages. So is not good to set it as global pager. We can introduce > new env variable PSQL_PAGER for this purpose. It can work similar like > PSQL_EDITOR

Re: [HACKERS] Log LDAP "diagnostic messages"?

On Wed, Jul 26, 2017 at 6:51 AM, Thomas Munro wrote: > Hi hackers, > > Some LDAP error codes are a bit vague. For example: > >LDAP_CONNECT_ERROR Indicates a connection problem. >LDAP_PROTOCOL_ERROR A protocol violation was detected. > > To learn

[HACKERS] pg_upgrade failed with error - ERROR: column "a" in child table must be marked NOT NULL

v9.5/9.6 create these objects - CREATE TABLE constraint_rename_test (a int CONSTRAINT con1 CHECK (a > 0), b int, c int); CREATE TABLE constraint_rename_test2 (a int CONSTRAINT con1 CHECK (a > 0), d int) INHERITS (constraint_rename_test); ALTER TABLE constraint_rename_test ADD CONSTRAINT con3

Re: [HACKERS] expand_dbname in postgres_fdw

On Wed, Jul 26, 2017 at 12:17 AM, Arseny Sher wrote: > Hi, > > Is there any particular reason why postgres_fdw forbids usage of > connection strings by passing expand_dbname = false to > PQconnectdbParams? Attached patch shows where this happens. > According to F.34.1.1 at

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

On Wed, Jul 26, 2017 at 12:02 PM, Ashutosh Bapat wrote: > > Ok. If those queries have equi-join between partitioned tables and are > not picking up partition-wise join, that case needs to be > investigated. Q21 for example has join between three lineitem >

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

On Wed, Jul 26, 2017 at 10:38 AM, Ashutosh Bapat wrote: > > On Tue, Jul 25, 2017 at 9:39 PM, Dilip Kumar wrote: > > On Tue, Jul 25, 2017 at 8:59 PM, Robert Haas wrote: > >> On Tue, Jul 25, 2017 at 1:31 AM, Rafia

Re: [HACKERS] proposal: psql: check env variable PSQL_PAGER

On Wed, Jul 26, 2017 at 7:11 AM, Pavel Stehule wrote: > Hi > > I wrote a special pager for psql. Surely, this pager is not good for paging > of man pages. So is not good to set it as global pager. We can introduce new > env variable PSQL_PAGER for this purpose. It can

[HACKERS] Parallel Hash take II

Hi hackers, Here is a new version of my parallel-aware hash join patchset. I've dropped 'shared' from the feature name and EXPLAIN output since that's now implied by the word "Parallel" (that only made sense in earlier versions that had Shared Hash and Parallel Shared Hash, but a Shared Hash

Re: [HACKERS] pg_dump does not handle indirectly-granted permissions properly

On 07/26/2017 02:12 AM, Tom Lane wrote: AFAICT, pg_dump has no notion that it needs to be careful about the order in which permissions are granted. I did regression=# create user joe; CREATE ROLE regression=# create user bob; CREATE ROLE regression=# create user alice; CREATE ROLE regression=#

Re: [HACKERS] UPDATE of partition key

On 2017/07/25 21:55, Rajkumar Raghuwanshi wrote: > Got one more observation : update... returning is not working with whole > row reference. please take a look. > > postgres=# create table part (a int, b int) partition by range(a); > CREATE TABLE > postgres=# create table part_p1 partition of

[HACKERS] map_partition_varattnos() and whole-row vars

Rajkumar Raghuwanshi reported [1] on the "UPDATE partition key" thread that whole-row vars don't play nicely with partitioned table operations. For example, when used to convert WITH CHECK OPTION constraint expressions and RETURNING target list expressions, it will error out if the expressions

Re: [HACKERS] On Complex Source Code Reading Strategy

Zeray Kalayu wrote: > I want to be PG hacker but it seems a complex beast to find my way out in it. > So, can anyone suggest me from his experience/style the general > approaches/techniques/strategies on how to read complex source code in > general and PG in particular effectively. > > Can you

[HACKERS] On Complex Source Code Reading Strategy

Hello Dear PostgreSQL Hackers, I want to be PG hacker but it seems a complex beast to find my way out in it. So, can anyone suggest me from his experience/style the general approaches/techniques/strategies on how to read complex source code in general and PG in particular effectively. Can you

Re: [HACKERS] UPDATE of partition key

On 2017/07/26 6:07, Robert Haas wrote: On Thu, Jul 13, 2017 at 1:09 PM, Amit Khandekar wrote: Attached is a WIP patch (make_resultrels_ordered.patch) that generates the result rels in canonical order. This patch is kept separate from the update-partition-key patch, and

Re: [HACKERS] PostgreSQL 10 (latest beta) and older ICU

On Tue, 25 Jul 2017 16:50:38 -0400 Tom Lane wrote: > Victor Wagner writes: > > PostgreSQL 10 when build with --with-icu requires ICU 4.6 and above. > > (because it searches for libicu using pkgconfig, and pgkconfig > > support significantly changed in ICU

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

On Wed, Jul 26, 2017 at 11:08 AM, Rafia Sabih wrote: > > > On Wed, Jul 26, 2017 at 11:06 AM, Ashutosh Bapat > wrote: >> >> On Wed, Jul 26, 2017 at 11:00 AM, Rafia Sabih >> wrote: >> > >> > >> > On Wed,

Re: [HACKERS] cache lookup failed error for partition key with custom opclass

On Tue, Jul 25, 2017 at 7:43 PM, Tom Lane wrote: > Rushabh Lathia writes: > > On Mon, Jul 24, 2017 at 7:23 PM, Tom Lane wrote: > >> Some looking around says that this *isn't* the only place that just > >> blithely assumes that

Re: [HACKERS] [BUGS] BUG #14759: insert into foreign data partitions fail

On 2017/07/25 9:43, David G. Johnston wrote: > On Mon, Jul 24, 2017 at 5:19 PM, Amit Langote > wrote: > >> On 2017/07/25 6:28, mtun...@gmail.com wrote: >>> The following bug has been logged on the website: >>> >>> Bug reference: 14759 >>> Logged by:

Re: [HACKERS] UPDATE of partition key

On 2017/07/26 6:07, Robert Haas wrote: > On Thu, Jul 13, 2017 at 1:09 PM, Amit Khandekar > wrote: >> Attached is a WIP patch (make_resultrels_ordered.patch) that generates >> the result rels in canonical order. This patch is kept separate from >> the update-partition-key