Re: [HACKERS] 10.0

On 5/16/16 9:53 AM, Greg Stark wrote: On Sat, May 14, 2016 at 1:00 AM, Tom Lane wrote: If that were the standard, we'd never have bumped the major version at all, and would still be on 4.something (or whatever Berkeley was using when they tossed it over the wall; I'm not

[HACKERS] trivia: cancel{,l}{ed,ing,ation}

I never know how to spell the various derived forms of "cancel" that come up from time to time. [rhaas pgsql]$ for a in canceled cancelled canceling cancelling cancelation cancellation; do echo -n $a:; git grep $a | wc -l; done canceled: 161 cancelled: 10 canceling: 141 cancelling:

Re: [HACKERS] HeapTupleSatisfiesToast() busted? (was atomic pin/unpin causing errors)

On Mon, May 16, 2016 at 8:28 AM, Andres Freund wrote: > On 2016-05-10 17:58:33 -0700, Andres Freund wrote: >> FWIW, I've commented out the relevant sections from xlog_redo and since >> then I've not been able to reproduce the issue. > > A couple days of running later, and it

Re: [HACKERS] Postgres_fdw join pushdown - getting server crash in left outer join of three table

On Fri, May 13, 2016 at 6:40 PM, Michael Paquier wrote: > On Fri, May 13, 2016 at 11:14 PM, Robert Haas wrote: >> So, barring objections, I intend to apply the attached fixup patch, >> which replaces Michael's logic with Ashutosh's logic and

Re: [HACKERS] 10.0

On Sat, May 14, 2016 at 1:00 AM, Tom Lane wrote: > If that were the standard, we'd never have bumped the major version at > all, and would still be on 4.something (or whatever Berkeley was using > when they tossed it over the wall; I'm not too clear on whether there was >

Re: [HACKERS] Odd oid-system-column handling in postgres_fdw

On Wed, May 11, 2016 at 3:44 AM, Etsuro Fujita wrote: > I'll add this to the next CF. Makes sense. I think this is basically a new feature, so let's treat it that way. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company --

Re: [HACKERS] Optimization for updating foreign tables in Postgres FDW

On Wed, May 11, 2016 at 3:20 AM, Etsuro Fujita wrote: > Thanks for the review! > > I'll add this to the next CF. I think this should be addressed in advance > of the release of 9.6, though. I agree. Committed. -- Robert Haas EnterpriseDB:

Re: [HACKERS] HeapTupleSatisfiesToast() busted? (was atomic pin/unpin causing errors)

On 2016-05-10 17:58:33 -0700, Andres Freund wrote: > FWIW, I've commented out the relevant sections from xlog_redo and since > then I've not been able to reproduce the issue. A couple days of running later, and it hasn't yet re-triggered. So I assume that's indeed the fix. -- Sent via

Re: [HACKERS] Reviewing freeze map code

On Tue, May 10, 2016 at 10:40 PM, Masahiko Sawada wrote: > Or second way I came up with is having tool to remove particular _vm > file safely, which is executed via SQL or client tool like > pg_resetxlog. > > Attached updated VACUUM SCAN_ALL patch. > Please find it. We

Re: [HACKERS] 10.0

Peter Eisentraut writes: > On 5/16/16 9:53 AM, Greg Stark wrote: >> I thought the idea was that Berkeley tossed an source tree over the >> wall with no version number and then the first five releases were >> Postgres95 0.x, Postgres95 1.0, Postgres95 1.0.1,

[HACKERS] pg_upgrade fails in 9.6 beta1

Hi, When trying an upgrade from postgresql94 -> postgresql96 (beta1) using pg_upgrade: pg_upgrade -p 5433 -P 5434 -b /usr/local/bin -B /home/girgen/postgres96/bin -d /tank/opt96/pgsql/data94 -D /tank/opt96/pgsql/data96 -U pgsql96 -k I eventually get this: pg_restore: creating TABLE

[HACKERS] Re: [HACKERS] Re: [HACKERS] Re: [HACKERS] Re: [HACKERS] Windows service is not starting so there’s message in log: FATAL: "could not create shared memory segment “Global/PostgreSQL.851401618

On Mon, May 16, 2016 at 9:45 AM, Michael Paquier wrote: > > On Sun, May 15, 2016 at 3:34 PM, Amit Kapila wrote: > > Sounds sensible, but if we want to that route, shall we have some mechanism > > such that if retrying it for 10 times (10 is

Re: [HACKERS] 10.0

On Sat, May 14, 2016 at 8:37 PM, Tom Lane wrote: > Jeff Janes writes: >> There are lots of improvement which get done to in-memory data >> structures that wouldn't require a pg_dump/pg_upgrade, which could in >> principle be ported into prior major

Re: [HACKERS] A couple of cosmetic changes around shared memory code

On Tue, May 17, 2016 at 4:40 AM, Piotr Stefaniak wrote: > while investigating the shm_mq code and its testing module I made some > cosmetic improvements there. You can see them in the attached diff file. -toc_bytes = offsetof(shm_toc, toc_entry) +nentry *

[HACKERS] Re: [HACKERS] Re: [HACKERS] Re: [HACKERS] Re: [HACKERS] Windows service is not starting so there’s message in log: FATAL: "could not create shared memory segment “Global/PostgreSQL.851401618

On Tue, May 17, 2016 at 4:16 AM, Amit Kapila wrote: > On Mon, May 16, 2016 at 9:45 AM, Michael Paquier > wrote: >> >> On Sun, May 15, 2016 at 3:34 PM, Amit Kapila >> wrote: >> > Sounds sensible, but if we want to that

[HACKERS] A couple of cosmetic changes around shared memory code

Hello, while investigating the shm_mq code and its testing module I made some cosmetic improvements there. You can see them in the attached diff file. commit 0e202cb6e0eca2e7fb3e1353b550f3d2ace9680e Author: Piotr Stefaniak Date: Thu Apr 28 18:36:16 2016 +0200

[HACKERS] Re: [HACKERS] Re: [HACKERS] Re: [HACKERS] Re: [HACKERS] Windows service is not starting so there’s message in log: FATAL: "could not create shared memory segment “Global/PostgreSQL.851401618

On Tue, May 17, 2016 at 6:01 AM, Michael Paquier wrote: > EACCES is a bit too low-level... I had in mind to check GetLastError > with only ERROR_ACCESS_DENIED, and retry only in this case, which is > the case where one postmaster is trying to access the segment of >

Re: [HACKERS] A Modest Upgrade Proposal

David Fetter wrote: > As a relatively (to our users) minor course correction, I would like > to propose the following: > - Develop a logical upgrade path as a part of the (Yay! Sexy!) logical > replication that's already in large part built. > > This path would, of course, run either

Re: [HACKERS] A Modest Upgrade Proposal

On 05/16/2016 06:22 PM, Alvaro Herrera wrote: David Fetter wrote: As a relatively (to our users) minor course correction, I would like to propose the following: - Develop a logical upgrade path as a part of the (Yay! Sexy!) logical replication that's already in large part built. This

[HACKERS] A Modest Upgrade Proposal

Folks, We have a problem. With all due respect to the valiant efforts of people over the years who have tried to make an upgrade-in-place system work, I would like to note that such a system faces what I believe are insurmountable barriers to being done correctly. I will then propose an

Re: [HACKERS] A Modest Upgrade Proposal

On 05/16/2016 05:52 PM, David Fetter wrote: Folks, This path would, of course, run either locally or across a network, and be testable in both cases. There would be a downgrade path, namely switching origin nodes. What say? What happens when the database is 5TB in size and you only have

Re: [HACKERS] [COMMITTERS] pgsql: Correctly align page's images in generic wal API

On Tue, May 17, 2016 at 6:01 AM, Teodor Sigaev wrote: > Correctly align page's images in generic wal API > > Page image should be MAXALIGN'ed because existing code could directly align > pointers in page instead of align offset from beginning of page. > > Found during play with

[HACKERS] Re: [COMMITTERS] pgsql: Correctly align page's images in generic wal API

Instead of allocating this memory unconditionally for each buffer, wouldn't it be better to set all the page pointers to NULL in GenericXLogStart and allocate memory only once a buffer is registered in GenericXLogRegisterBuffer when finding a free slot? This patch is wasting many cycles.

Re: [HACKERS] pg_upgrade fails in 9.6 beta1

On Tue, May 17, 2016 at 12:07 AM, Palle Girgensohn wrote: > pg_restore: creating TABLE "public.cal_event" > pg_restore: [archiver (db)] Error while PROCESSING TOC: > pg_restore: [archiver (db)] Error from TOC entry 205; 1259 3538451239 TABLE > cal_event nobody > pg_restore:

Re: [HACKERS] Declarative partitioning

Hi Amit, I'm running some experiments based on your infrastructure trying to optimize SELECT queries. At some point I need to get PartitionDesc for relation and to do it I'm using RelationGetPartitionDesc() function. Problem is that this function copies relcache data and it can be quite slow

[HACKERS] [PATCH][Documination] Add optional USING keyword before opclass name in INSERT statemet

If I read gram.y code for insert statement, I see that there is an optional USING keyword before opclass name opt_class: any_name{ $$ = $1; } | USING any_name{ $$ = $2; } | /*EMPTY*/ {

Re: [HACKERS] A Modest Upgrade Proposal

On 05/16/2016 06:32 PM, Alvaro Herrera wrote: Joshua D. Drake wrote: Alvaro, Thank you for bringing this to light. Is there a contributor FAQ for PgLogical so that people can help? Hmm, I don't think there's any contributor FAQ. It's supposed to be a regular patch submission, after all --

Re: [HACKERS] A Modest Upgrade Proposal

Joshua D. Drake wrote: > Alvaro, > > Thank you for bringing this to light. Is there a contributor FAQ for > PgLogical so that people can help? Hmm, I don't think there's any contributor FAQ. It's supposed to be a regular patch submission, after all -- it needs user interface review, a review

Re: [HACKERS] A Modest Upgrade Proposal

On Mon, May 16, 2016 at 06:20:34PM -0700, Joshua D. Drake wrote: > On 05/16/2016 05:52 PM, David Fetter wrote: > > Folks, > > > This path would, of course, run either locally or across a > > network, and be testable in both cases. There would be a > > downgrade path, namely switching origin

Re: [HACKERS] A Modest Upgrade Proposal

Joshua D. Drake wrote: > On 05/16/2016 06:32 PM, Alvaro Herrera wrote: > >Joshua D. Drake wrote: > > > >>Alvaro, > >> > >>Thank you for bringing this to light. Is there a contributor FAQ for > >>PgLogical so that people can help? > > > >Hmm, I don't think there's any contributor FAQ. It's

Re: [HACKERS] 10.0

On 14 May 2016 at 02:49, Tom Lane wrote: > > * This year's major release will be 9.6.0, with minor updates 9.6.1, > 9.6.2, etc. It's too late to do otherwise for this release cycle. > > * Next year's major release will be 10.0, with minor updates 10.1, > 10.2, etc. > > *

[HACKERS] The rewritting of join conditions caused a very slow query plan.

Hi,all I have a query that is very slow,and the reason may be in the rewritting of join conditions. this is the simplied version table and the key part of the sql. level1_table and level2_table hold the tree data nodes, and all_level_status table holds the current status all all nodes of all

Re: [HACKERS] Lets (not) break all the things. Was: [pgsql-advocacy] 9.6 -> 10.0

On Sun, May 15, 2016 at 03:23:52PM -0500, Jim Nasby wrote: > 2) There's no ability at all to revert, other than restore a backup. That > means if you pull the trigger and discover some major performance problem, > you have no choice but to deal with it (you can't switch back to the old > version

[HACKERS] Backup doc typo

Hi, Attached patch adds missing "is" in a sentence in backup.sgml. Thanks, Amit diff --git a/doc/src/sgml/backup.sgml b/doc/src/sgml/backup.sgml index b036183..96fc9a0 100644 --- a/doc/src/sgml/backup.sgml +++ b/doc/src/sgml/backup.sgml @@ -906,8 +906,8 @@ SELECT * FROM pg_stop_backup(false);