Re: [HACKERS] expanding inheritance in partition bound order

On 2017/08/05 2:25, Robert Haas wrote: > On Fri, Aug 4, 2017 at 3:38 AM, Amit Langote > wrote: >> The current way to expand inherited tables, including partitioned tables, >> is to use either find_all_inheritors() or find_inheritance_children() >> depending on the context. They return child table

Re: [HACKERS] Tuple-routing for certain partitioned tables not working as expected

On 2017/08/07 15:33, Amit Langote wrote: On 2017/08/07 15:22, Etsuro Fujita wrote: On 2017/08/07 13:11, Amit Langote wrote:> The patch looks good too. Although, looking at the following hunk: + Assert(partrel->rd_rel->relkind == RELKIND_RELATION || +partrel->rd_rel->rel

Re: [HACKERS] Tuple-routing for certain partitioned tables not working as expected

On 2017/08/07 15:22, Etsuro Fujita wrote: > On 2017/08/07 13:11, Amit Langote wrote:> The patch looks good too. > Although, looking at the following hunk: >> >> + Assert(partrel->rd_rel->relkind == RELKIND_RELATION || >> +partrel->rd_rel->relkind == RELKIND_FOREIGN_TABLE); >

Re: [HACKERS] expanding inheritance in partition bound order

On Mon, Aug 7, 2017 at 11:18 AM, Ashutosh Bapat wrote: >> >> One objection to this line of attack is that there might be a good >> case for locking only the partitioned inheritors first and then going >> back and locking the leaf nodes in a second pass, or even only when >> required for a particul

[HACKERS] Adding hook in BufferSync for backup purposes

Hi, hackers! I want to propose adding hook in BufferSync. ==Why==So that extensions could track pages changed between checkpoints. I think this can allow efficient differential backups taken right after checkpoint. And this functionality can be implemented as an extension. ==What==I propose to add

Re: [HACKERS] UPDATE of partition key

On Fri, Aug 4, 2017 at 10:28 PM, Amit Khandekar wrote: > > > > Below are the TODOS at this point : > > > > Fix for bug reported by Rajkumar about update with join. > > I had explained the root issue of this bug here : [1] > > Attached patch includes the fix, which is explained below. > Hi Amit,

Re: [HACKERS] Tuple-routing for certain partitioned tables not working as expected

On 2017/08/07 13:11, Amit Langote wrote:> The patch looks good too. Although, looking at the following hunk: + Assert(partrel->rd_rel->relkind == RELKIND_RELATION || + partrel->rd_rel->relkind == RELKIND_FOREIGN_TABLE); + /*

Re: [HACKERS] [TRAP: FailedAssertion] causing server to crash

On 7 August 2017 at 14:04, Thomas Munro wrote: > On Fri, Jul 21, 2017 at 7:17 PM, Kyotaro HORIGUCHI > wrote: > > In vac_truncate_clog, TruncateCLOG is called before > > SetTransactionIdLimit, which advances > > ShmemVariableCache->oldestXid. Given that the assertion in > > TruncateCLOG is valid,

Re: [HACKERS] [TRAP: FailedAssertion] causing server to crash

On Fri, Jul 21, 2017 at 7:17 PM, Kyotaro HORIGUCHI wrote: > In vac_truncate_clog, TruncateCLOG is called before > SetTransactionIdLimit, which advances > ShmemVariableCache->oldestXid. Given that the assertion in > TruncateCLOG is valid, they should be called in reverse order. I > suppose that CLO

Re: [HACKERS] expanding inheritance in partition bound order

On Fri, Aug 4, 2017 at 10:55 PM, Robert Haas wrote: > On Fri, Aug 4, 2017 at 3:38 AM, Amit Langote > wrote: >> The current way to expand inherited tables, including partitioned tables, >> is to use either find_all_inheritors() or find_inheritance_children() >> depending on the context. They retu

Re: [HACKERS] expanding inheritance in partition bound order

On 2017/08/04 20:28, Ashutosh Bapat wrote: > On Fri, Aug 4, 2017 at 1:08 PM, Amit Langote > wrote: >> The current way to expand inherited tables, including partitioned tables, >> is to use either find_all_inheritors() or find_inheritance_children() >> depending on the context. They return child t

Re: [HACKERS] expanding inheritance in partition bound order

On 4 August 2017 at 22:55, Robert Haas wrote: > > 1. Before calling RelationGetPartitionDispatchInfo, the calling code > should use find_all_inheritors to lock all the relevant relations (or > the planner could use find_all_inheritors to get a list of relation > OIDs, store it in the plan in order

Re: [HACKERS] [TRAP: FailedAssertion] causing server to crash

On Thu, Aug 3, 2017 at 3:03 AM, Robert Haas wrote: > On Fri, Jul 21, 2017 at 1:31 AM, Thomas Munro > wrote: >> Thanks Neha. It's be best to post the back trace and if possible >> print oldestXact and ShmemVariableCache->oldestXid from the stack >> frame for TruncateCLOG. >> >> The failing assert

Re: [HACKERS] Small code improvement for btree

On Sat, Aug 5, 2017 at 3:29 AM, Peter Geoghegan wrote: > On Fri, Aug 4, 2017 at 11:12 AM, Alvaro Herrera > wrote: >> Interesting. We learned elsewhere that it's better to integrate the >> "!= 0" test as part of the macro definition; so a >> better formulation of this patch would be to change the

Re: [HACKERS] Subscription code improvements

On Sun, Aug 6, 2017 at 7:44 AM, Noah Misch wrote: > On Wed, Aug 02, 2017 at 04:09:43PM -0400, Peter Eisentraut wrote: >> On 8/1/17 00:17, Noah Misch wrote: >> > The above-described topic is currently a PostgreSQL 10 open item. Peter, >> > since you committed the patch believed to have created it,

Re: [HACKERS] Subscription code improvements

On Sat, Aug 5, 2017 at 10:29 AM, Peter Eisentraut wrote: > On 8/4/17 12:02, Masahiko Sawada wrote: >> To make ALTER SUBSCRIPTION REFRESH being transactional, I prefer >> Petr's proposal. Because it can make ALTER SUBSCRIPTION and DROP >> SUBSCRIPTION stop the table sync workers that are in progres

Re: [HACKERS] Tuple-routing for certain partitioned tables not working as expected

Fujita-san, On 2017/08/07 12:45, Etsuro Fujita wrote: > Hi, > > I noticed that tuple-routing for partitioned tables that contain > non-writable foreign partitions doesn't work as expected. Here is an > example: > > postgres=# create extension file_fdw; > postgres=# create server file_server for

[HACKERS] Tuple-routing for certain partitioned tables not working as expected

Hi, I noticed that tuple-routing for partitioned tables that contain non-writable foreign partitions doesn't work as expected. Here is an example: postgres=# create extension file_fdw; postgres=# create server file_server foreign data wrapper file_fdw; postgres=# create user mapping for CURR

Re: [HACKERS] Effect of dropping a partitioned table's column over time

On 7 August 2017 at 11:25, Thomas Munro wrote: > On Mon, Aug 7, 2017 at 2:20 PM, Tom Lane wrote: > > Thomas Munro writes: > >> Since partitioned tables have no storage themselves, is there > >> any technical reason we couldn't remove a partitioned table's dropped > >> pg_attribute so that its T

Re: [HACKERS] Effect of dropping a partitioned table's column over time

On Mon, Aug 7, 2017 at 2:35 PM, Amit Langote wrote: > On 2017/08/07 10:58, Thomas Munro wrote: >> Of course there are other usage patterns where you might prefer it >> this way, because you'll mostly be inserting into partitions created >> before the change. In general, would it be better for the

[HACKERS] FYI: branch for v11 devel is planned for next week

The release team discussed this a couple weeks ago, but I don't think anybody mentioned it on -hackers: v10 seems to be in good enough shape that it's okay to make the REL_10_STABLE branch soon, and open HEAD for v11 development. Last year we branched on Aug 15, and we should be able to keep to th

Re: [HACKERS] Effect of dropping a partitioned table's column over time

On Mon, Aug 7, 2017 at 2:20 PM, Tom Lane wrote: > Thomas Munro writes: >> Since partitioned tables have no storage themselves, is there >> any technical reason we couldn't remove a partitioned table's dropped >> pg_attribute so that its TupleDesc matches partitions created later? > > You'd break

Re: [HACKERS] scan on inheritance parent with no children in current session

On 2017/08/04 18:11, Ashutosh Bapat wrote: > After that commit in session 1, we get an Append plan > postgres=# explain verbose select * from parent; > QUERY PLAN > --- > Append (cost=0.00..0.00 rows=1 wid

Re: [HACKERS] Effect of dropping a partitioned table's column over time

Hi Thomas, On 2017/08/07 10:58, Thomas Munro wrote: > Hi hackers, > > If you drop a column from a partitioned table then it has a TupleDesc > that matches existing partitions, but new partitions created after > that have non-same TupleDescs (according to convert_tuples_by_name) > because they don

Re: [HACKERS] Effect of dropping a partitioned table's column over time

Thomas Munro writes: > Since partitioned tables have no storage themselves, is there > any technical reason we couldn't remove a partitioned table's dropped > pg_attribute so that its TupleDesc matches partitions created later? You'd break views referring to the partitioned table, or at least to

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

On 2017/08/05 11:05, Robert Haas wrote: > On Thu, Aug 3, 2017 at 8:45 PM, Amit Langote > wrote: >>> 0003 needs a rebase. >> >> Rebased patch attached. > > Committed. Thank you. > I think 0004 is a new feature, so I'm leaving that for v11. Sure. By the way, bulk of 0004 is refactoring which it

[HACKERS] Effect of dropping a partitioned table's column over time

Hi hackers, If you drop a column from a partitioned table then it has a TupleDesc that matches existing partitions, but new partitions created after that have non-same TupleDescs (according to convert_tuples_by_name) because they don't have the dropped column. That means that inserts to partition

[HACKERS] ICU collation variant keywords and pg_collation entries (Was: [BUGS] Crash report for some ICU-52 (debian8) COLLATE and work_mem values)

On Sun, Aug 6, 2017 at 1:06 PM, Peter Geoghegan wrote: > On Sat, Aug 5, 2017 at 8:26 PM, Tom Lane wrote: >> I'm quite disturbed though that the set of installed collations on these >> two test cases seem to be entirely different both from each other and from >> what you reported. The base collat

Re: [HACKERS] snapbuild woes

On 2017-06-09 09:25:34 +0200, Antonin Houska wrote: > Andres Freund wrote: > > > Looking at 0001: > > - GetOldestSafeDecodingTransactionId() only guarantees to return an xid > > safe for decoding (note how procArray->replication_slot_catalog_xmin > > is checked), not one for the initial snaps

Re: [HACKERS] PostgreSQL not setting OpenSSL session id context?

On 08/04/2017 08:48 PM, Shay Rojansky wrote: On 2017-08-04 07:22:42 +0300, Shay Rojansky wrote: > I'm still not convinced of the risk/problem of simply setting the session > id context as I explained above (rather than disabling the optimization), > but of course either solution r

Re: [HACKERS] [WIP] Zipfian distribution in pgbench

Hello Fabien, > On 5 Aug 2017, at 12:15, Fabien COELHO wrote: > > > Hello Alik, > > I've done some math investigations, which consisted in spending one hour with > Christian, a statistician colleague of mine. He took an old book out of a > shelf, opened it to page 550 (roughly in the middle

[HACKERS] Draft for 2017-08-10 Release

Hi, I have put together a draft of the press release notes for the upcoming 20170810 release. It is available here: https://git.postgresql.org/gitweb/?p=press.git;a=blob_plain;f=update_releases/current/20170810securityrelease.md

Re: [HACKERS] Draft release notes up for review

> On Aug 5, 2017, at 5:37 PM, Tom Lane wrote: > > Jonathan Katz writes: >> I see this one >> > Fix potential data corruption when freezing a tuple whose XMAX is a >> multixact with exactly one still-interesting member >> But I’m unsure how prevalent it is and if it should be highlighted.