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

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

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

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

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

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

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

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

[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

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

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

[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

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

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

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

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

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

[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

[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 >>

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

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

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

[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

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

On Sat, Aug 5, 2017 at 6:22 PM, Robert Haas wrote: > On Sat, Aug 5, 2017 at 4:28 PM, Paul A Jungwirth > wrote: >> I don't have an opinion on the urgency of back-porting a fix, but if >> pg_stop_backup(boolean) allows for inconsistent backups,