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
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 this in
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
On Thu, Jun 11, 2015 at 2:14 PM, Michael Paquier
michael.paqu...@gmail.com wrote:
On Thu, Jun 11, 2015 at 1:51 AM, Fujii Masao masao.fu...@gmail.com 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
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
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 that
On 11 June 2015 at 11:20, Shay Rojansky r...@roji.org 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
On Jun 11, 2015 7:38 AM, Amit Langote langote_amit...@lab.ntt.co.jp
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
Robert Haas robertmh...@gmail.com writes:
On Tue, Jun 9, 2015 at 11:00 AM, Alvaro Herrera
alvhe...@2ndquadrant.com 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
Simon Riggs si...@2ndquadrant.com writes:
On 11 June 2015 at 11:20, Shay Rojansky r...@roji.org 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
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
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
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
Andres Freund and...@anarazel.de 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
On Wed, Jun 10, 2015 at 10:57 PM, Kouhei Kaigai kai...@ak.jp.nec.com 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
2015-06-11 23:20 GMT+09:00 Jan Wieck j...@wi3ck.info:
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
On Thu, Jun 11, 2015 at 5:38 AM, Simon Riggs si...@2ndquadrant.com wrote:
On 11 June 2015 at 11:20, Shay Rojansky r...@roji.org 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
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
for
Tomas Vondra tomas.von...@2ndquadrant.com 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
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.
2015-06-11 23:33 GMT+09:00 Tomas Vondra tomas.von...@2ndquadrant.com:
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
On Thu, Jun 11, 2015 at 10:20:13AM +0530, Amit Kapila wrote:
On Thu, Jun 11, 2015 at 9:45 AM, Bruce Momjian br...@momjian.us 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
On Tue, Jun 9, 2015 at 6:35 PM, Bruce Momjian br...@momjian.us 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
2015-06-11 23:28 GMT+09:00 Robert Haas robertmh...@gmail.com:
On Wed, Jun 10, 2015 at 10:57 PM, Kouhei Kaigai kai...@ak.jp.nec.com wrote:
The attached patch replaces this palloc0() by MemoryContextAllocHuge() +
memset().
Indeed, this hash table is constructed towards the relation with
On Tue, Jun 9, 2015 at 11:00 AM, Alvaro Herrera
alvhe...@2ndquadrant.com 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
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:
On Thu, Jun 11, 2015 at 10:21 AM, Michael Paquier
michael.paqu...@gmail.com wrote:
On Thu, Jun 11, 2015 at 2:38 AM, Fujii Masao masao.fu...@gmail.com wrote:
* Remove invalid option character N from the third argument (valid option
string) of getopt_long().
* Use pg_free() or pfree() to free
On Wed, Jun 10, 2015 at 9:57 PM, Kouhei Kaigai kai...@ak.jp.nec.com 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
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 kai...@ak.jp.nec.com
-Original Message-
From: Merlin Moncure [mailto:mmonc...@gmail.com]
Sent: Thursday, June 11, 2015 10:52 PM
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
On Thu, Jun 11, 2015 at 4:23 PM, Peter Geoghegan p...@heroku.com 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
On Thu, Jun 11, 2015 at 2:17 PM, Robert Haas robertmh...@gmail.com wrote:
On Thu, Jun 11, 2015 at 4:23 PM, Peter Geoghegan p...@heroku.com wrote:
Secondly, Robert didn't credit himself as an author in his commit
message for the abbreviated keys infrastructure + text opclass support
*at all*.
On Thu, Jun 11, 2015 at 3:12 PM, Tom Lane t...@sss.pgh.pa.us 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:
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
Robert Haas robertmh...@gmail.com 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.
[
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
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,
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
On Wed, Jun 10, 2015 at 9:15 PM, Bruce Momjian br...@momjian.us wrote:
I have committed the first draft of the 9.5 release notes. You can view
the output here:
+ listitem
+ para
+Improve the speed of sorting character and numeric fields (Robert
+Haas, Peter
On Thu, Jun 11, 2015 at 1:23 PM, Peter Geoghegan p...@heroku.com 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
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
On Thu, Jun 11, 2015 at 3:22 PM, Alvaro Herrera
alvhe...@2ndquadrant.com 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
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:
*
On 12 June 2015 at 06:48, Noah Misch n...@leadboat.com 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
On 5 June 2015 at 18:07, deavid deavidsed...@gmail.com 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
On Fri, Jun 12, 2015 at 4:33 AM, Alvaro Herrera alvhe...@2ndquadrant.com
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
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 completely
On Thu, Jun 11, 2015 at 2:20 PM, Abhijit Menon-Sen a...@2ndquadrant.com 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
On Tue, Jun 09, 2015 at 04:31:43PM -0700, Josh Berkus wrote:
First draft of the release announcement.
2015-06-12 Update Release
=
The PostgreSQL Global Development Group has released an update to all
supported versions of our database system, including 9.4.4,
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 people want (2).
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 sufficient.
On Thu, Jun 11, 2015 at 2:39 PM, Abhijit Menon-Sen a...@2ndquadrant.com 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
On Fri, Jun 5, 2015 at 10:59 AM, Tom Lane t...@sss.pgh.pa.us 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
On Tue, Jun 9, 2015 at 1:39 PM, Michael Paquier
michael.paqu...@gmail.com 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
On Thu, Jun 11, 2015 at 8:24 PM, Bruce Momjian br...@momjian.us 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 br...@momjian.us wrote:
I have committed the first draft of the 9.5 release notes. You can
view
the
On Thu, Jun 11, 2015 at 1:15 PM, Bruce Momjian br...@momjian.us 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:
On 06/11/2015 05:08 PM, Peter Geoghegan wrote:
On Thu, Jun 11, 2015 at 9:49 AM, Andrew Dunstan and...@dunslane.net 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
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:
On Thu, Jun 11, 2015 at 9:49 AM, Andrew Dunstan and...@dunslane.net 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.
--
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:
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 eventually appear
On 11 June 2015 at 16:56, Shay Rojansky r...@roji.org 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/
http://www.2ndquadrant.com/
PostgreSQL
On Thu, Jun 11, 2015 at 4:26 PM, Robert Haas robertmh...@gmail.com 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
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
On Thu, Jun 11, 2015 at 12:13:26PM -0400, Robert Haas wrote:
On Thu, Jun 11, 2015 at 11:32 AM, Bruce Momjian br...@momjian.us wrote:
Improve hash creation and lookup performance (Tomas Vondra,
Teodor Sigaev, Tom Lane, Robert Haas)
I suggest haveing two separate items. One
On Thu, Jun 11, 2015 at 11:32 AM, Bruce Momjian br...@momjian.us 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
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
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
On Thu, Jun 11, 2015 at 12:13 PM, Joshua D. Drake j...@commandprompt.com
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
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
On Thu, Jun 11, 2015 at 6:29 PM, Joshua D. Drake j...@commandprompt.com
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.
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
On Thu, Jun 11, 2015 at 12:29 PM, Joshua D. Drake j...@commandprompt.com
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
Bruce Momjian br...@momjian.us 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
Robert Haas robertmh...@gmail.com writes:
On Thu, Jun 11, 2015 at 11:32 AM, Bruce Momjian br...@momjian.us 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
On Thu, Jun 11, 2015 at 12:14 PM, Bruce Momjian br...@momjian.us 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 br...@momjian.us wrote:
Improve hash creation and lookup performance (Tomas Vondra,
Teodor
On Wed, Jun 10, 2015 at 7:16 PM, Noah Misch n...@leadboat.com 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
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
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
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:
On Tue, Jun 9, 2015 at 4:42 AM, Shay Rojansky r...@roji.org 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
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 for
On Thu, Jun 11, 2015 at 2:50 PM, Josh Berkus j...@agliodbs.com 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.
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
On Thu, Jun 11, 2015 at 8:56 PM, Josh Berkus j...@agliodbs.com 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
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 stamping
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
On 06/11/15 16:54, Tom Lane wrote:
Tomas Vondra tomas.von...@2ndquadrant.com 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
On Thu, Jun 11, 2015 at 11:13 AM, Dave Page dp...@pgadmin.org 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.
On Thu, Jun 11, 2015 at 05:16:07PM +1200, David Rowley wrote:
On 11 June 2015 at 16:15, Bruce Momjian br...@momjian.us 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
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 eventually appear
91 matches
Mail list logo
