Re: [HACKERS] pg_rewind failure by file deletion in source server

On Fri, Jun 12, 2015 at 3:17 PM, Michael Paquier wrote: > On Thu, Jun 11, 2015 at 5:48 PM, Fujii Masao wrote: >> On Thu, Jun 11, 2015 at 2:14 PM, Michael Paquier >> wrote: >>> On Thu, Jun 11, 2015 at 1:51 AM, Fujii Masao wrote: Shouldn't pg_rewind ignore that failure of operation? If the f

Re: [HACKERS] pg_rewind failure by file deletion in source server

On Thu, Jun 11, 2015 at 5:48 PM, Fujii Masao wrote: > On Thu, Jun 11, 2015 at 2:14 PM, Michael Paquier > wrote: >> On Thu, Jun 11, 2015 at 1:51 AM, Fujii Masao wrote: >>> Shouldn't pg_rewind ignore that failure of operation? If the file is not >>> found in source server, the file doesn't need to

Re: [HACKERS] Comfortably check BackendPID with psql

> > >Not a big fan of that abbreviation itself. What I'd wondered about > > >instead - and actually had patched into my psql at some point - is > > >adding an appropriate escape to psql's PROMPT. I think that'd serve your > > >purpose as well? > > > > +3.14159; that would be hugely helpful when us

Re: [HACKERS] Is it possible to have a "fast-write" Index?

On 5 June 2015 at 18:07, deavid wrote: > There are several use cases where I see useful an index, but adding it > will slow too much inserts and updates. > For example, when we have 10 million rows on a table, and it's a table > which has frequent updates, we need several index to speed up select

Re: [HACKERS] The purpose of the core team

On 12 June 2015 at 06:48, Noah Misch wrote: > On Thu, Jun 11, 2015 at 03:47:06PM -0300, Alvaro Herrera wrote: > > Bruce Momjian wrote: > > > http://www.postgresql.org/developer/core/ > > > After going over this a few times, there is one thing that strikes me > > that nobody has mentioned:

Re: [HACKERS] Reconsidering the behavior of ALTER COLUMN TYPE

On Thu, Jun 11, 2015 at 03:41:49PM -0500, Merlin Moncure wrote: > On Thu, Jun 11, 2015 at 3:12 PM, Tom Lane wrote: > > Specifically, it's not clear why you can change the type of a uuid[] > > column with > > > > alter table t alter u type text[]; > > > > but then you can't change it back with > >

Re: [HACKERS] Comfortably check BackendPID with psql

On Thu, Jun 11, 2015 at 04:05:13PM -0500, Jim Nasby wrote: > On 6/11/15 4:55 AM, Andres Freund wrote: > >On 2015-06-11 09:41:17 +, Naoya Anzai wrote: > >>This is a so tiny patch but I think it is very useful for hackers and DBAs. > >>When we debug with psql, we frequently use "SELECT pg_backend

Re: [HACKERS] The purpose of the core team

On Thu, Jun 11, 2015 at 03:47:06PM -0300, Alvaro Herrera wrote: > Bruce Momjian wrote: > > http://www.postgresql.org/developer/core/ > After going over this a few times, there is one thing that strikes me > that nobody has mentioned: the list of tasks mentioned there has one > that's compl

Re: [HACKERS] On columnar storage

On Fri, Jun 12, 2015 at 4:33 AM, Alvaro Herrera wrote: > > We hope to have a chance to discuss this during the upcoming developer > unconference in Ottawa. Here are some preliminary ideas to shed some > light on what we're trying to do. > > > I've been trying to figure out a plan to enable native

Re: [HACKERS] 9.5 release notes

On Thu, Jun 11, 2015 at 1:15 PM, Bruce Momjian wrote: > I have committed the first draft of the 9.5 release notes. You can view > the output here: > > http://momjian.us/pgsql_docs/release-9-5.html > > and it will eventually appear here: > > http://www.postgresql.org/docs/devel/sta

Re: [HACKERS] 9.5 release notes

On Thu, Jun 11, 2015 at 8:24 PM, Bruce Momjian wrote: > > On Thu, Jun 11, 2015 at 10:20:13AM +0530, Amit Kapila wrote: > > On Thu, Jun 11, 2015 at 9:45 AM, Bruce Momjian wrote: > > > > > > I have committed the first draft of the 9.5 release notes. You can view > > > the output here: > > > > > >

Re: [HACKERS] Useless mention of RMGRDESCSOURCES in src/bin/pg_rewind/Makefile

On Tue, Jun 9, 2015 at 1:39 PM, Michael Paquier wrote: > Hi all, > > pg_rewind's Makefile uses RMGRDESCSOURCES: > EXTRA_CLEAN = $(RMGRDESCSOURCES) xlogreader.c > However this variable is defined only in the Makefile of pg_xlogdump > so it has no utility in this case. > Attached is a cleanup patch.

Re: [HACKERS] Is it possible to have a "fast-write" Index?

On Fri, Jun 5, 2015 at 10:59 AM, Tom Lane wrote: > So I really doubt that anyone would have any enthusiasm for saddling btree > with a similar mechanism. It's complicated (and has been the cause of > multiple bugs); it's hard to figure out when is the optimal time to flush > the pending insertion

Re: [HACKERS] On columnar storage

Josh, * Josh Berkus (j...@agliodbs.com) wrote: > On 06/11/2015 04:03 PM, Alvaro Herrera wrote: > > We hope to have a chance to discuss this during the upcoming developer > > unconference in Ottawa. Here are some preliminary ideas to shed some > > light on what we're trying to do. > > Added to: >

Re: [HACKERS] The purpose of the core team

On 06/11/2015 05:08 PM, Peter Geoghegan wrote: > On Thu, Jun 11, 2015 at 9:49 AM, Andrew Dunstan wrote: >>> JoshB: Advocacy. There is a strong argument that does not need to be a >>> core position. >>> >> >> I strongly disagree with this. On the contrary, I think there is a very good >> argument t

Re: [HACKERS] On columnar storage

On 06/11/2015 04:03 PM, Alvaro Herrera wrote: > We hope to have a chance to discuss this during the upcoming developer > unconference in Ottawa. Here are some preliminary ideas to shed some > light on what we're trying to do. Added to: https://wiki.postgresql.org/wiki/PgCon_2015_Developer_Unconfe

Re: [HACKERS] The purpose of the core team

On Thu, Jun 11, 2015 at 9:49 AM, Andrew Dunstan wrote: >> JoshB: Advocacy. There is a strong argument that does not need to be a >> core position. >> > > I strongly disagree with this. On the contrary, I think there is a very good > argument that FOR such a position in core. +1. -- Peter Geoghe

Re: [HACKERS] On columnar storage

On Thu, Jun 11, 2015 at 4:03 PM, Alvaro Herrera wrote: > I've been trying to figure out a plan to enable native column stores > (CS or "colstore") for Postgres. Motivations: > > * avoid the 32 TB limit for tables > * avoid the 1600 column limit for tables > * increased performance > And better co

Re: [HACKERS] DBT-3 with SF=20 got failed

Hi, On 06/11/15 16:28, Robert Haas wrote: On Wed, Jun 10, 2015 at 10:57 PM, Kouhei Kaigai wrote: The attached patch replaces this palloc0() by MemoryContextAllocHuge() + memset(). Indeed, this hash table is constructed towards the relation with nrows=119994544, so, it is not strange even if

[HACKERS] On columnar storage

We hope to have a chance to discuss this during the upcoming developer unconference in Ottawa. Here are some preliminary ideas to shed some light on what we're trying to do. I've been trying to figure out a plan to enable native column stores (CS or "colstore") for Postgres. Motivations: * avo

Re: [HACKERS] CREATE POLICY and RETURNING

Dean, * Dean Rasheed (dean.a.rash...@gmail.com) wrote: > On 8 June 2015 at 16:53, Stephen Frost wrote: > > I definitely don't like the idea of returning a portion of the data in a > > RETURNING clause. Returning an error if the RETURNING clause ends up > > not passing the SELECT policy is an int

Re: [HACKERS] Construction of Plan-node by CSP (RE: Custom/Foreign-Join-APIs)

> Robert Haas writes: > > Tom, do you want to review this patch and figure out how to solve the > > underlying problem? If not, I will take care of it. But I will be > > unhappy if I put time and effort into this and then you insist on > > changing everything afterwards, again. > > [ sorry for

Re: [HACKERS] 9.5 release notes

On Thu, Jun 11, 2015 at 2:17 PM, Robert Haas wrote: > On Thu, Jun 11, 2015 at 4:23 PM, Peter Geoghegan wrote: >> Secondly, Robert didn't credit himself as an author in his commit >> message for the abbreviated keys infrastructure + text opclass support >> *at all*. However, I think that Robert sh

Re: [HACKERS] Is it possible to have a "fast-write" Index?

On 6/5/15 6:54 PM, deavid wrote: So the problem is: i see a low iowait, and CPU time for one core is at 80-90% most of the time. I can buy more ram, better disks, or cpu's with more cores. But one cpu core would have more-or-less the same speed no matter how much money you invest. When someone

Re: [HACKERS] 9.5 release notes

On Thu, Jun 11, 2015 at 4:23 PM, Peter Geoghegan wrote: > Secondly, Robert didn't credit himself as an author in his commit > message for the abbreviated keys infrastructure + text opclass support > *at all*. However, I think that Robert should be listed as a secondary > author of the abbreviated

Re: [HACKERS] Comfortably check BackendPID with psql

On 6/11/15 4:55 AM, Andres Freund wrote: Hi, On 2015-06-11 09:41:17 +, Naoya Anzai wrote: This is a so tiny patch but I think it is very useful for hackers and DBAs. When we debug with psql, we frequently use "SELECT pg_backend_pid();". This can change the input of the 24 characters to the

Re: [HACKERS] The purpose of the core team

On Thu, Jun 11, 2015 at 3:22 PM, Alvaro Herrera wrote: > I think #1 is the part that we seem to have the most trouble with. It > seems easily fixable: establish a new mailing list for that task (say > pgsql-release) and get all the current -core in there, plus the set of > active committers. Tha

Re: [HACKERS] Cancel race condition

Thanks for the extra consideration Robert. Since I'm implementing a generic driver, users can send either single-statement transactions or actual multiple-statement transaction. However, whether we're in a transaction or not doesn't seem to affect Npgsql logic (unless I'm missing something) - if t

Re: [HACKERS] Reconsidering the behavior of ALTER COLUMN TYPE

On Thu, Jun 11, 2015 at 3:12 PM, Tom Lane wrote: > A recent thread in pgsql-general shows yet another user who's befuddled by > the need to add a USING clause to an ALTER TABLE ... ALTER COLUMN TYPE > command: > > http://www.postgresql.org/message-id/flat/CAD25zGDiaqCG=eqXp=byvzcdgvcqubh7kbpjpjqse

Re: [HACKERS] Postgres GSSAPI Encryption

Robbie, * Robbie Harwood (rharw...@redhat.com) wrote: > I've coded up the GSSAPI encryption and is on my github[0]. It's > missing a number of things before merge, including proper error > handling, correct ACL behavior (by and large, it currently doesn't > respect hba.conf), and exposing configu

Re: [HACKERS] 9.5 release notes

On Thu, Jun 11, 2015 at 1:23 PM, Peter Geoghegan wrote: > * Add sortsupport (support for non-SQL callable interface for > comparators) with abbreviation capability to text/varlena operator > class. This significantly accelerates sorting on text columns. > (4ea51cdfe85 too, but also b34e37bf. Worth

Re: [HACKERS] 9.5 release notes

On Wed, Jun 10, 2015 at 9:15 PM, Bruce Momjian wrote: > I have committed the first draft of the 9.5 release notes. You can view > the output here: + + +Improve the speed of sorting character and numeric fields (Robert +Haas, Peter Geoghegan, Andrew Gierth) + +

[HACKERS] Reconsidering the behavior of ALTER COLUMN TYPE

A recent thread in pgsql-general shows yet another user who's befuddled by the need to add a USING clause to an ALTER TABLE ... ALTER COLUMN TYPE command: http://www.postgresql.org/message-id/flat/CAD25zGDiaqCG=eqXp=byvzcdgvcqubh7kbpjpjqsespowfv...@mail.gmail.com Specifically, it's not clear why

Re: [HACKERS] Entities created in one query not available in another in extended protocol

Thanks everyone for your time (or rather sorry for having wasted it). Just in case it's interesting to you... The reason we implemented things this way is in order to avoid a deadlock situation - if we send two queries as P1/D1/B1/E1/P2/D2/B2/E2, and the first query has a large resultset, PostgreS

[HACKERS] Why does replication need the old history file?

Hackers, Sequence of events: 1. PITR backup of server on timeline 2. 2. Restored the backup to a new server, new-master. 3. Restored the backup to another new server, new-replica. 4. Started and promoted new-master (now on Timeline 3). 5. Started new-replica, connecting over streaming to new-

Re: [HACKERS] The purpose of the core team

Robert Haas wrote: > The release process has multiple parts: > > 1. Deciding that we need to do a release, either because $BUG is > really bad or because we have security fixes to release or because > enough time has gone by. > 2. Updating translations and time zones and release notes and stampin

Re: [HACKERS] 9.5 release notes

On Thu, Jun 11, 2015 at 8:56 PM, Josh Berkus wrote: > On 06/10/2015 09:50 PM, Amit Kapila wrote: > > Also shall we mention about below in Migrations to 9.5 section > > > > "pg_basebackup will not not work in tar mode against 9.4 and older > servers, > > as we have introduced a new protocol optio

Re: [HACKERS] 9.5 release notes

On 06/10/2015 09:50 PM, Amit Kapila wrote: > Also shall we mention about below in Migrations to 9.5 section > > "pg_basebackup will not not work in tar mode against 9.4 and older servers, > as we have introduced a new protocol option in that mode." AFAIK, pg_basebackup has never worked across ve

Re: [HACKERS] The purpose of the core team

On Thu, Jun 11, 2015 at 2:50 PM, Josh Berkus wrote: > On 06/11/2015 11:47 AM, Alvaro Herrera wrote: >> After going over this a few times, there is one thing that strikes me >> that nobody has mentioned: the list of tasks mentioned there has one >> that's completely unlike the others. These are re

Re: [HACKERS] The purpose of the core team

On 06/11/2015 11:47 AM, Alvaro Herrera wrote: > After going over this a few times, there is one thing that strikes me > that nobody has mentioned: the list of tasks mentioned there has one > that's completely unlike the others. These are related to human > relations: > > Acting as a conduit f

Re: [HACKERS] Cancel race condition

On Tue, Jun 9, 2015 at 4:42 AM, Shay Rojansky wrote: > Ah, OK - I wasn't aware that cancellation was actually delivered as a > regular POSIX signal... You're right about the lack of guarantees then. > > In that case, I'm guessing not much could be do to guarantee sane > cancellation behavior... I

Re: [HACKERS] The purpose of the core team

Bruce Momjian wrote: > There has been some confusion by old and new community members about the > purpose of the core team, and this lack of understanding has caused some > avoidable problems. Therefore, the core team has written a core charter > and published it on our website: > > http:

Re: [HACKERS] Draft release notes for 9.4.4 et al

On 06/10/2015 11:35 PM, Noah Misch wrote: > On Tue, Jun 09, 2015 at 04:31:43PM -0700, Josh Berkus wrote: >> First draft of the release announcement. Noah, thank you for corrections! -- Josh Berkus PostgreSQL Experts Inc. http://pgexperts.com -- Sent via pgsql-hackers mailing list (pgsql-hack

Re: [HACKERS] The purpose of the core team

On 06/11/2015 10:20 AM, Robert Haas wrote: True but that isn't the fault of core outside of communication. The hackers, reviewers and committers of those patches should be required to communicate with core in a way that expresses the true severity of a situation so core can make a: Management

Re: [HACKERS] [GENERAL] 9.4.1 -> 9.4.2 problem: could not access status of transaction 1

On Wed, Jun 10, 2015 at 7:16 PM, Noah Misch wrote: > On Mon, Jun 08, 2015 at 03:15:04PM +0200, Andres Freund wrote: > > One more thing: > > Our testing infrastructure sucks. Without writing C code it's basically > > impossible to test wraparounds and such. Even if not particularly useful > > for

Re: [HACKERS] 9.5 release notes

On Thu, Jun 11, 2015 at 12:14 PM, Bruce Momjian wrote: > On Thu, Jun 11, 2015 at 12:13:26PM -0400, Robert Haas wrote: >> On Thu, Jun 11, 2015 at 11:32 AM, Bruce Momjian wrote: >> > Improve hash creation and lookup performance (Tomas Vondra, >> > Teodor Sigaev, Tom Lane, Robert Haa

Re: [HACKERS] 9.5 release notes

Robert Haas writes: > On Thu, Jun 11, 2015 at 11:32 AM, Bruce Momjian wrote: >> Improve hash creation and lookup performance (Tomas Vondra, >> Teodor Sigaev, Tom Lane, Robert Haas) > I suggest haveing two separate items. One of those is about the Hash > executor node and the other is about our

Re: [HACKERS] 9.5 release notes

Bruce Momjian writes: > On Thu, Jun 11, 2015 at 05:16:07PM +1200, David Rowley wrote: >> Would you also be able to mention something about f15821e and d222585 ? > I am going to defer to Tom on that. I have added optimizer changes in > the past but he didn't feel it made sense unless there was so

Re: [HACKERS] The purpose of the core team

On Thu, Jun 11, 2015 at 12:29 PM, Joshua D. Drake wrote: >> However, the core team needs to know when it should initiate a >> release, and to do that it needs to understand the impact of bugs that >> have been fixed and bugs that have not been fixed. The recent >> discussion of multixacts seems

Re: [HACKERS] The purpose of the core team

On 06/11/2015 10:10 AM, Magnus Hagander wrote: Magnus: Committer, primary Windows dude and reviews patches here and there. Not sure that's a fair title at this point. Both Andrew and Michael seem to be doing more of that than me these days, for example. (I do review patches here and t

Re: [HACKERS] The purpose of the core team

On Thu, Jun 11, 2015 at 6:29 PM, Joshua D. Drake wrote: > > On 06/11/2015 07:12 AM, Robert Haas wrote: > >> >> Hopefully this will be helpful to people. >>> >> >> I believe the core team is suffering from a lack of members who are >> involved in writing, reviewing, and committing patches. Those

Re: [HACKERS] The purpose of the core team

On 06/11/2015 09:49 AM, Andrew Dunstan wrote: On 06/11/2015 12:29 PM, Joshua D. Drake wrote: JoshB: Advocacy. There is a strong argument that does not need to be a core position. I strongly disagree with this. On the contrary, I think there is a very good argument that FOR such a positi

Re: [HACKERS] The purpose of the core team

On Thu, Jun 11, 2015 at 12:13 PM, Joshua D. Drake wrote: > This is crap. I am on the packagers list. Core always asks what people think > and no it is not always accepted. There have been many times that the > release has been pushed off because of resources available or new > information being p

Re: [HACKERS] The purpose of the core team

On 06/11/2015 12:29 PM, Joshua D. Drake wrote: JoshB: Advocacy. There is a strong argument that does not need to be a core position. I strongly disagree with this. On the contrary, I think there is a very good argument that FOR such a position in core. cheers andrew -- Sent via pgs

Re: [HACKERS] The purpose of the core team

On 06/11/2015 07:12 AM, Robert Haas wrote: Hopefully this will be helpful to people. I believe the core team is suffering from a lack of members who are involved in writing, reviewing, and committing patches. Those things are not core functions of the core team, as that charter illustrates.

Re: [HACKERS] 9.5 release notes

On Thu, Jun 11, 2015 at 11:32 AM, Bruce Momjian wrote: > Improve hash creation and lookup performance (Tomas Vondra, > Teodor Sigaev, Tom Lane, Robert Haas) I suggest haveing two separate items. One of those is about the Hash executor node and the other is about our dynahash stuf

Re: [HACKERS] 9.5 release notes

On Thu, Jun 11, 2015 at 12:13:26PM -0400, Robert Haas wrote: > On Thu, Jun 11, 2015 at 11:32 AM, Bruce Momjian wrote: > > Improve hash creation and lookup performance (Tomas Vondra, > > Teodor Sigaev, Tom Lane, Robert Haas) > > I suggest haveing two separate items. One of those i

Re: [HACKERS] The purpose of the core team

On 06/11/2015 08:26 AM, Robert Haas wrote: Timing *decisions* are not made by -core, as I've told you in the past. They are made by the packagers who do the actual work, based on suggestions from -core. You have told me that in the past, and I do not accept that it is true. The suggestions f

Re: [HACKERS] The purpose of the core team

On Thu, Jun 11, 2015 at 4:26 PM, Robert Haas wrote: > >> Timing *decisions* are not made by -core, as I've told you in the >> past. They are made by the packagers who do the actual work, based on >> suggestions from -core. > > You have told me that in the past, and I do not accept that it is true.

Re: [HACKERS] 9.5 release notes

On Thu, Jun 11, 2015 at 02:16:59PM +0200, Tomas Vondra wrote: > Hi, > > On 06/11/15 06:15, Bruce Momjian wrote: > >I have committed the first draft of the 9.5 release notes. You can view > >the output here: > > > > http://momjian.us/pgsql_docs/release-9-5.html > > > >and it will eventual

Re: [HACKERS] The purpose of the core team

On Thu, Jun 11, 2015 at 11:13 AM, Dave Page wrote: > Yes, and we have recently been discussing how best to solicit those > opinions this year. Great! >> As a non-core team member, I find it quite frustrating that getting a >> release triggered requires emailing a closed mailing list. > > It does

Re: [HACKERS] Entities created in one query not available in another in extended protocol

On 11 June 2015 at 16:56, Shay Rojansky wrote: Npgsql (currently) sends Parse for the second command before sending > Execute for the first one. > Look no further than that. -- Simon Riggshttp://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Sup

Re: [HACKERS] 9.5 release notes

On Thu, Jun 11, 2015 at 05:16:07PM +1200, David Rowley wrote: > > On 11 June 2015 at 16:15, Bruce Momjian wrote: > > I have committed the first draft of the 9.5 release notes.  You can view > the output here: > >         http://momjian.us/pgsql_docs/release-9-5.html > > > > Thank

Re: [HACKERS] 9.5 release notes

On Thu, Jun 11, 2015 at 02:00:08PM +0900, Amit Langote wrote: > On 2015-06-11 PM 01:15, Bruce Momjian wrote: > > I have committed the first draft of the 9.5 release notes. You can view > > the output here: > > > > http://momjian.us/pgsql_docs/release-9-5.html > > > > and it will eventual

Re: [HACKERS] The purpose of the core team

On Thu, Jun 11, 2015 at 3:12 PM, Robert Haas wrote: > On Tue, Jun 9, 2015 at 6:35 PM, Bruce Momjian wrote: >> There has been some confusion by old and new community members about the >> purpose of the core team, and this lack of understanding has caused some >> avoidable problems. Therefore, the

Re: [HACKERS] 9.5 release notes

On Thu, Jun 11, 2015 at 01:54:23PM +0900, Michael Paquier wrote: > On Thu, Jun 11, 2015 at 1:15 PM, Bruce Momjian wrote: > > I have committed the first draft of the 9.5 release notes. You can view > > the output here: > > > > http://momjian.us/pgsql_docs/release-9-5.html > > > > and it wi

Re: [HACKERS] DBT-3 with SF=20 got failed

On 06/11/15 16:54, Tom Lane wrote: Tomas Vondra writes: Interestingly, the hash code checks for INT_MAX overflows on a number of places, but does not check for this ... Yeah, and at least at one time there were checks to prevent the hash table request from exceeding MaxAllocSize. Did those

Re: [HACKERS] Entities created in one query not available in another in extended protocol

I just understood the same thing Tom wrote, yes, Npgsql (currently) sends Parse for the second command before sending Execute for the first one. I will look into that implementation decision. It might be worth looking into Simon's comment though, I'll report if I still see the same problematic beha

Re: [HACKERS] Entities created in one query not available in another in extended protocol

Andres Freund writes: > On 2015-06-11 10:50:31 -0400, Tom Lane wrote: >> I do note that if a transaction is implicitly started to execute these >> messages, it's not closed until Sync. But that should only affect the >> visibility of the results to other sessions, not to the current one. >> There

Re: [HACKERS] Entities created in one query not available in another in extended protocol

On 2015-06-11 10:50:31 -0400, Tom Lane wrote: > I do note that if a transaction is implicitly started to execute these > messages, it's not closed until Sync. But that should only affect the > visibility of the results to other sessions, not to the current one. > There's definitely a CommandCounte

Re: [HACKERS] DBT-3 with SF=20 got failed

Tomas Vondra writes: > Interestingly, the hash code checks for INT_MAX overflows on a number of > places, but does not check for this ... Yeah, and at least at one time there were checks to prevent the hash table request from exceeding MaxAllocSize. Did those get removed by somebody?

Re: [HACKERS] 9.5 release notes

On Thu, Jun 11, 2015 at 10:20:13AM +0530, Amit Kapila wrote: > On Thu, Jun 11, 2015 at 9:45 AM, Bruce Momjian wrote: > > > > I have committed the first draft of the 9.5 release notes.  You can view > > the output here: > > > >         http://momjian.us/pgsql_docs/release-9-5.html > > > > Thanks f

Re: [HACKERS] DBT-3 with SF=20 got failed

2015-06-11 23:33 GMT+09:00 Tomas Vondra : > Hi, > > On 06/11/15 16:20, Jan Wieck wrote: >> >> On 06/11/2015 09:53 AM, Kouhei Kaigai wrote: curious: what was work_mem set to? >>> work_mem=48GB >>> >>> My machine mounts 256GB physical RAM. >> >> >> work_mem can be allocated several tim

Re: [HACKERS] Entities created in one query not available in another in extended protocol

Simon Riggs writes: > On 11 June 2015 at 11:20, Shay Rojansky wrote: >> It appears that when we send two messages in an extended protocol (so two >> Parse/Bind/Execute followed by a single Sync), where the first one creates >> some entity (function, table), and the second one can't query that ent

Re: [HACKERS] skipping pg_log in basebackup (was Re: pg_basebackup and pg_stat_tmp directory)

Michael Paquier wrote: > After spending the night thinking about that, honestly, I think that > we should go with (2) and keep the base backup as light-weight as > possible and not bother about a GUC. (3) would need some extra > intelligence to decide if some files can be skipped or not. Imagine >

Re: [HACKERS] DBT-3 with SF=20 got failed

2015-06-11 23:28 GMT+09:00 Robert Haas : > On Wed, Jun 10, 2015 at 10:57 PM, Kouhei Kaigai wrote: >> The attached patch replaces this palloc0() by MemoryContextAllocHuge() + >> memset(). >> Indeed, this hash table is constructed towards the relation with >> nrows=119994544, >> so, it is not stra

Re: [HACKERS] The Future of Aggregation

Robert Haas writes: > On Tue, Jun 9, 2015 at 11:00 AM, Alvaro Herrera > wrote: >> Uh, this also requires serialization and deserialization of non- >> finalized transition state, no? > A bunch of this stuff does, but I recently had a Brilliant Insight: we > don't need to add a new method for seri

Re: [HACKERS] DBT-3 with SF=20 got failed

Hi, On 06/11/15 16:20, Jan Wieck wrote: On 06/11/2015 09:53 AM, Kouhei Kaigai wrote: curious: what was work_mem set to? work_mem=48GB My machine mounts 256GB physical RAM. work_mem can be allocated several times per backend. Nodes like sort and hash_aggregate may each allocate that much. Y

Re: [HACKERS] Entities created in one query not available in another in extended protocol

On Thu, Jun 11, 2015 at 5:38 AM, Simon Riggs wrote: > On 11 June 2015 at 11:20, Shay Rojansky wrote: >> >> In Npgsql, the .NET driver for PostgreSQL, we've switched from simple to >> extended protocol and have received a user complaint. >> >> It appears that when we send two messages in an extend

Re: [HACKERS] DBT-3 with SF=20 got failed

On Wed, Jun 10, 2015 at 10:57 PM, Kouhei Kaigai wrote: > The attached patch replaces this palloc0() by MemoryContextAllocHuge() + > memset(). > Indeed, this hash table is constructed towards the relation with > nrows=119994544, > so, it is not strange even if hash-slot itself is larger than 1GB.

Re: [HACKERS] DBT-3 with SF=20 got failed

2015-06-11 23:20 GMT+09:00 Jan Wieck : > On 06/11/2015 09:53 AM, Kouhei Kaigai wrote: >>> >>> curious: what was work_mem set to? >>> >> work_mem=48GB >> >> My machine mounts 256GB physical RAM. > > > work_mem can be allocated several times per backend. Nodes like sort and > hash_aggregate may each

Re: [HACKERS] DBT-3 with SF=20 got failed

On 06/11/2015 09:53 AM, Kouhei Kaigai wrote: curious: what was work_mem set to? work_mem=48GB My machine mounts 256GB physical RAM. work_mem can be allocated several times per backend. Nodes like sort and hash_aggregate may each allocate that much. You should set work_mem to a fraction of

Re: [HACKERS] The purpose of the core team

On Tue, Jun 9, 2015 at 6:35 PM, Bruce Momjian wrote: > There has been some confusion by old and new community members about the > purpose of the core team, and this lack of understanding has caused some > avoidable problems. Therefore, the core team has written a core charter > and published it o

Re: [HACKERS] The Future of Aggregation

On Tue, Jun 9, 2015 at 11:00 AM, Alvaro Herrera wrote: > Uh, this also requires serialization and deserialization of non- > finalized transition state, no? A bunch of this stuff does, but I recently had a Brilliant Insight: we don't need to add a new method for serializing and deserializing trans

Re: [HACKERS] DBT-3 with SF=20 got failed

> curious: what was work_mem set to? > work_mem=48GB My machine mounts 256GB physical RAM. -- NEC Business Creation Division / PG-Strom Project KaiGai Kohei > -Original Message- > From: Merlin Moncure [mailto:mmonc...@gmail.com] > Sent: Thursday, June 11, 2015 10:52 PM > To: Kaigai Kouh

Re: [HACKERS] DBT-3 with SF=20 got failed

On Wed, Jun 10, 2015 at 9:57 PM, Kouhei Kaigai wrote: > Hello, > > I got the following error during DBT-3 benchmark with SF=20. > > psql:query21.sql:50: ERROR: invalid memory alloc request size 1073741824 > psql:query21.sql:50: ERROR: invalid memory alloc request size 1073741824 > > It looks

Re: [HACKERS] minor issues in pg_rewind

On Thu, Jun 11, 2015 at 10:21 AM, Michael Paquier wrote: > On Thu, Jun 11, 2015 at 2:38 AM, Fujii Masao wrote: >> * Remove invalid option character "N" from the third argument (valid option >> string) of getopt_long(). >> * Use pg_free() or pfree() to free the memory allocated by pg_malloc() or >

Re: [HACKERS] 9.5 release notes

Hi, On 06/11/15 06:15, Bruce Momjian wrote: I have committed the first draft of the 9.5 release notes. You can view the output here: http://momjian.us/pgsql_docs/release-9-5.html and it will eventually appear here: http://www.postgresql.org/docs/devel/static/release.h

Re: [HACKERS] Comfortably check BackendPID with psql

Hi, Andres, Marko > Seems easier to set this in .psqlrc: oops! I've never noticed.. Thank you for your comment. Regards, Naoya --- Naoya Anzai Engineering Department NEC Solution Inovetors, Ltd. E-Mail: nao-an...@xc.jp.nec.com --- -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgre

Re: [HACKERS] Comfortably check BackendPID with psql

Hi, On 2015-06-11 09:41:17 +, Naoya Anzai wrote: > This is a so tiny patch but I think it is very useful for hackers and DBAs. > When we debug with psql, we frequently use "SELECT pg_backend_pid();". > This can change the input of the 24 characters to the only 4 characters! Not a big fan of t

Re: [HACKERS] skipping pg_log in basebackup (was Re: pg_basebackup and pg_stat_tmp directory)

On Jun 11, 2015 7:38 AM, "Amit Langote" wrote: > > On 2015-06-11 PM 02:20, Abhijit Menon-Sen wrote: > > At 2015-06-10 13:22:27 -0400, robertmh...@gmail.com wrote: > >> > >> (1) include pg_log in pg_basebackup as we do currently > >> (2) exclude it > >> (3) add a switch controlling whether or not i

Re: [HACKERS] Comfortably check BackendPID with psql

On 6/11/15 11:41 AM, Naoya Anzai wrote: > This can change the input of the 24 characters to the only 4 characters! > > Image. > -- > naoya=# \bid > Backend Process ID > pid > -- > 1716 > (1 row) > --- > > How do you like it? Seems easier to set thi

[HACKERS] Comfortably check BackendPID with psql

Hi, hackers! This is a so tiny patch but I think it is very useful for hackers and DBAs. When we debug with psql, we frequently use "SELECT pg_backend_pid();". This can change the input of the 24 characters to the only 4 characters! Image. -- naoya=# \bid Backend Process ID p

Re: [HACKERS] Entities created in one query not available in another in extended protocol

On 11 June 2015 at 11:20, Shay Rojansky wrote: > In Npgsql, the .NET driver for PostgreSQL, we've switched from simple to > extended protocol and have received a user complaint. > > It appears that when we send two messages in an extended protocol (so two > Parse/Bind/Execute followed by a single

[HACKERS] Entities created in one query not available in another in extended protocol

In Npgsql, the .NET driver for PostgreSQL, we've switched from simple to extended protocol and have received a user complaint. It appears that when we send two messages in an extended protocol (so two Parse/Bind/Execute followed by a single Sync), where the first one creates some entity (function,

Re: [HACKERS] pg_rewind failure by file deletion in source server

On Thu, Jun 11, 2015 at 2:14 PM, Michael Paquier wrote: > On Thu, Jun 11, 2015 at 1:51 AM, Fujii Masao wrote: >> Shouldn't pg_rewind ignore that failure of operation? If the file is not >> found in source server, the file doesn't need to be copied to destination >> server obviously. So ISTM that

Re: [HACKERS] skipping pg_log in basebackup (was Re: pg_basebackup and pg_stat_tmp directory)

On Thu, Jun 11, 2015 at 2:39 PM, Abhijit Menon-Sen wrote: > At 2015-06-11 14:28:36 +0900, michael.paqu...@gmail.com wrote: >> >> After spending the night thinking about that, honestly, I think that >> we should go with (2) and keep the base backup as light-weight as >> possible and not bother abou

Re: [HACKERS] skipping pg_log in basebackup (was Re: pg_basebackup and pg_stat_tmp directory)

On 2015-06-11 PM 02:20, Abhijit Menon-Sen wrote: > At 2015-06-10 13:22:27 -0400, robertmh...@gmail.com wrote: >> >> (1) include pg_log in pg_basebackup as we do currently >> (2) exclude it >> (3) add a switch controlling whether or not it gets excluded >> >> I can live with (3), but I bet most peop

Re: [HACKERS] skipping pg_log in basebackup (was Re: pg_basebackup and pg_stat_tmp directory)

At 2015-06-11 14:28:36 +0900, michael.paqu...@gmail.com wrote: > > After spending the night thinking about that, honestly, I think that > we should go with (2) and keep the base backup as light-weight as > possible and not bother about a GUC. OK. Then the patch I posted earlier should be sufficien

Re: [HACKERS] skipping pg_log in basebackup (was Re: pg_basebackup and pg_stat_tmp directory)

On Thu, Jun 11, 2015 at 2:20 PM, Abhijit Menon-Sen wrote: > At 2015-06-10 13:22:27 -0400, robertmh...@gmail.com wrote: >> >> I'm not clear on which of these options you are voting for: >> >> (1) include pg_log in pg_basebackup as we do currently >> (2) exclude it >> (3) add a switch controlling wh

  1   2   >