On Wed, Jun 4, 2014 at 11:10 PM, Fujii Masao masao.fu...@gmail.com wrote:
On Wed, Jun 4, 2014 at 3:26 PM, Amit Langote amitlangot...@gmail.com wrote:
Hi,
Following (commit 2985e16) has not been backpatched, I guess.
ANALYZE hs1;
-ERROR: cannot execute VACUUM during recovery
+ERROR:
On Thu, Jun 5, 2014 at 3:11 PM, Amit Langote amitlangot...@gmail.com wrote:
On Wed, Jun 4, 2014 at 11:10 PM, Fujii Masao masao.fu...@gmail.com wrote:
On Wed, Jun 4, 2014 at 3:26 PM, Amit Langote amitlangot...@gmail.com wrote:
Hi,
Following (commit 2985e16) has not been backpatched, I guess.
On Thu, Jun 5, 2014 at 4:09 PM, Fujii Masao masao.fu...@gmail.com wrote:
On Thu, Jun 5, 2014 at 3:11 PM, Amit Langote amitlangot...@gmail.com wrote:
On Wed, Jun 4, 2014 at 11:10 PM, Fujii Masao masao.fu...@gmail.com wrote:
On Wed, Jun 4, 2014 at 3:26 PM, Amit Langote amitlangot...@gmail.com
On 06/05/2014 05:09 AM, Amit Langote wrote:
Hi,
On Thu, Jun 5, 2014 at 10:57 AM, Fujii Masao masao.fu...@gmail.com wrote:
I like using slot_name everywhere, i.e, even in recovery.conf.
primary_slot_name seems not so long name.
BTW, what about also renaming pg_llog directory? I'm afraid that
a
Hi,
This patch implements a pg_receivexlog add synchronous mode.
Now, synchronous(synchronous_commit = remote_write) is supported.
But synchronous(synchronous_commit = remote_write), if the server crashes then
WAL file may not to be flushed to disk , causing data loss.
On 05/06/14 10:11, Heikki Linnakangas wrote:
On 06/05/2014 05:09 AM, Amit Langote wrote:
Hi,
On Thu, Jun 5, 2014 at 10:57 AM, Fujii Masao masao.fu...@gmail.com
wrote:
I like using slot_name everywhere, i.e, even in recovery.conf.
primary_slot_name seems not so long name.
+1
BTW, what
Hi,
On Thu, 2014-06-05 at 10:57 +0900, Fujii Masao wrote:
BTW, what about also renaming pg_llog directory? I'm afraid that
a user can confuse pg_log with pg_llog.
+1. I hit this while testing 9.4 this week. Should be confusing for many
end-users.
Regards,
--
Devrim GÜNDÜZ
Principal Systems
On Jun 5, 2014 10:22 AM, Devrim Gündüz dev...@gunduz.org wrote:
Hi,
On Thu, 2014-06-05 at 10:57 +0900, Fujii Masao wrote:
BTW, what about also renaming pg_llog directory? I'm afraid that
a user can confuse pg_log with pg_llog.
+1. I hit this while testing 9.4 this week. Should be
On 2014-06-05 16:56:08 +0900, Amit Langote wrote:
On Thu, Jun 5, 2014 at 4:09 PM, Fujii Masao masao.fu...@gmail.com wrote:
Do we need to back-patch this to older versions (i,e. 9.2, 9.1, ..)?
Yes, this should be backpatched to 9.2, 9.1, 9.0, too.
I don't think it really needs to go to 9.0
Hi,
On 2014-06-05 17:09:44 +0900, furu...@pm.nttdata.co.jp wrote:
Synchronous(synchronous_commit = on) mode offers the ability to confirm WAL
have been streamed in the same way as synchronous replication.
If an output is used as a different disk from the directory where the
transaction log
On 2014-06-04 20:40:40 -0400, Peter Eisentraut wrote:
On Wed, 2014-05-07 at 03:08 +0200, Andres Freund wrote:
As an additional issue it currently doesn't seem to work in VPATH
builds. That's imo a must fix.
A cd $(srcdir) .. in prove_installcheck and prove_check seems to do
the
On Thu, Jun 5, 2014 at 5:27 PM, Magnus Hagander mag...@hagander.net wrote:
On Jun 5, 2014 10:22 AM, Devrim Gündüz dev...@gunduz.org wrote:
Hi,
On Thu, 2014-06-05 at 10:57 +0900, Fujii Masao wrote:
BTW, what about also renaming pg_llog directory? I'm afraid that
a user can confuse pg_log
On Thu, Jun 5, 2014 at 5:37 PM, Andres Freund and...@2ndquadrant.com wrote:
On 2014-06-05 16:56:08 +0900, Amit Langote wrote:
On Thu, Jun 5, 2014 at 4:09 PM, Fujii Masao masao.fu...@gmail.com wrote:
Do we need to back-patch this to older versions (i,e. 9.2, 9.1, ..)?
Yes, this should be
On 05/06/2014 07:36 PM, Andres Freund wrote:
On 2014-05-06 13:33:01 +0300, Heikki Linnakangas wrote:
On 03/31/2014 09:08 PM, Robert Haas wrote:
On Wed, Mar 26, 2014 at 9:45 PM, Peter Geoghegan p...@heroku.com wrote:
On Wed, Nov 27, 2013 at 9:10 AM, Noah Misch n...@leadboat.com wrote:
The
-Original Message-
Hi,
On 2014-06-05 17:09:44 +0900, furu...@pm.nttdata.co.jp wrote:
Synchronous(synchronous_commit = on) mode offers the ability to
confirm WAL have been streamed in the same way as synchronous
replication.
If an output is used as a different disk from the
-Original Message-
From: Ali Akbar [mailto:the.ap...@gmail.com]
Sent: Donnerstag, 5. Juni 2014 01:12
To: Marc Mamin
Cc: Michael Paquier; pgsql-hackers@postgresql.org
Subject: Re: [HACKERS] pivot aggregation with a patched intarray
2014-06-01 20:48 GMT+07:00 Marc Mamin
On 2014-06-05 10:57:58 +0900, Fujii Masao wrote:
On Thu, Jun 5, 2014 at 8:24 AM, Andres Freund and...@2ndquadrant.com wrote:
Hi,
Due to the opened window of the pg_control/catalog version bump a chance
has opened to fix a inconsistency I've recently been pointed
towards:
Namely that
On Thu, Jun 5, 2014 at 7:57 PM, Andres Freund and...@2ndquadrant.com wrote:
We have:
* pg_ldecoding (Heikki)
* pg_lcse or pg_lcset (Petr)
* pg_logical (Andres)
pg_decoding, simply?
--
Michael
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your
On 2014-06-05 20:02:38 +0900, Michael Paquier wrote:
On Thu, Jun 5, 2014 at 7:57 PM, Andres Freund and...@2ndquadrant.com wrote:
We have:
* pg_ldecoding (Heikki)
* pg_lcse or pg_lcset (Petr)
* pg_logical (Andres)
pg_decoding, simply?
I don't like it much, because it's pretty much
On Thu, Jun 5, 2014 at 12:57 PM, Andres Freund and...@2ndquadrant.com
wrote:
On 2014-06-05 10:57:58 +0900, Fujii Masao wrote:
On Thu, Jun 5, 2014 at 8:24 AM, Andres Freund and...@2ndquadrant.com
wrote:
Hi,
Due to the opened window of the pg_control/catalog version bump a
chance
On 06/05/2014 01:57 PM, Andres Freund wrote:
On 2014-06-05 10:57:58 +0900, Fujii Masao wrote:
On Thu, Jun 5, 2014 at 8:24 AM, Andres Freund and...@2ndquadrant.com wrote:
Hi,
Due to the opened window of the pg_control/catalog version bump a chance
has opened to fix a inconsistency I've
On 06/05/2014 02:10 PM, Magnus Hagander wrote:
On Thu, Jun 5, 2014 at 12:57 PM, Andres Freund and...@2ndquadrant.com
wrote:
We have:
* pg_ldecoding (Heikki)
* pg_lcse or pg_lcset (Petr)
* pg_logical (Andres)
I like, what a surprise, my own suggestion best. The name seems more
versatile
On 2014-06-05 14:12:31 +0300, Heikki Linnakangas wrote:
On 06/05/2014 01:57 PM, Andres Freund wrote:
On 2014-06-05 10:57:58 +0900, Fujii Masao wrote:
We have:
* pg_ldecoding (Heikki)
* pg_lcse or pg_lcset (Petr)
* pg_logical (Andres)
I like, what a surprise, my own suggestion best. The
Hello all,
This is a continuation of the thread found here:
http://www.postgresql.org/message-id/538f2578.9080...@linos.es
Considering this seems to be a problem with the planner I thought that maybe
would be a better idea to post this problem here.
To summarize the original thread I upgraded
On 2014-06-05 12:57:57 +0200, Andres Freund wrote:
On 2014-06-05 10:57:58 +0900, Fujii Masao wrote:
I like using slot_name everywhere, i.e, even in recovery.conf.
primary_slot_name seems not so long name.
It also has the advantage that we can add a couple more slot_* options
later. Will
On Wed, Jun 4, 2014 at 12:54 AM, Amit Kapila amit.kapil...@gmail.com wrote:
On Tue, Jun 3, 2014 at 5:43 PM, Gurjeet Singh gurj...@singh.im wrote:
For sizeable shared_buffers size, the restoration of the shared
buffers can take several seconds.
Incase of recovery, the shared buffers saved by
On Wed, Jun 4, 2014 at 2:52 PM, Andres Freund and...@2ndquadrant.com wrote:
On 2014-06-04 14:50:39 -0400, Robert Haas wrote:
The thing I was concerned about is that the system might have been in
recovery for months. What was hot at the time the base backup was
taken seems like a poor guide to
On Wed, Jun 4, 2014 at 2:50 PM, Robert Haas robertmh...@gmail.com wrote:
The thing I was concerned about is that the system might have been in
recovery for months. What was hot at the time the base backup was
taken seems like a poor guide to what will be hot at the time of
promotion. Consider
On 05/06/14 13:32, Linos wrote:
Hello all,
This is a continuation of the thread found here:
http://www.postgresql.org/message-id/538f2578.9080...@linos.es
Considering this seems to be a problem with the planner I thought that maybe
would be a better idea to post this problem here.
To
On 06/04/2014 12:45 AM, Jeff Janes wrote:
On Sun, May 25, 2014 at 8:40 AM, Heikki Linnakangas hlinnakan...@vmware.com
wrote:
While debugging the B-tree bug that Jeff Janes reported (
http://www.postgresql.org/message-id/CAMkU=1y=VwF07Ay+Cpqk_
7fpihrctmssv9y99sbghitkxpb...@mail.gmail.com), a
On Thu, Jun 5, 2014 at 6:32 AM, Linos i...@linos.es wrote:
Hello all,
This is a continuation of the thread found here:
http://www.postgresql.org/message-id/538f2578.9080...@linos.es
Considering this seems to be a problem with the planner I thought that maybe
would be a better idea to post
On 05/06/14 16:40, Merlin Moncure wrote:
On Thu, Jun 5, 2014 at 6:32 AM, Linos i...@linos.es wrote:
Hello all,
This is a continuation of the thread found here:
http://www.postgresql.org/message-id/538f2578.9080...@linos.es
Considering this seems to be a problem with the planner I thought
On 05/06/14 16:40, Merlin Moncure wrote:
On Thu, Jun 5, 2014 at 6:32 AM, Linos i...@linos.es wrote:
Hello all,
This is a continuation of the thread found here:
http://www.postgresql.org/message-id/538f2578.9080...@linos.es
Considering this seems to be a problem with the planner I thought
On Thu, Jun 5, 2014 at 9:54 AM, Linos i...@linos.es wrote:
What I don't understand is why the statistics have this bad information, all
my tests are done on a database just restored and analyzed. Can I do
something to improve the quality of my database statistics and let the
planner do
On Thu, Jun 5, 2014 at 7:12 AM, Heikki Linnakangas
hlinnakan...@vmware.com wrote:
BTW, what about also renaming pg_llog directory? I'm afraid that
a user can confuse pg_log with pg_llog.
We have:
* pg_ldecoding (Heikki)
* pg_lcse or pg_lcset (Petr)
* pg_logical (Andres)
I like, what a
On Thu, Jun 5, 2014 at 3:54 PM, Linos i...@linos.es wrote:
What I don't understand is why the statistics have this bad information, all
my tests are done on a database just restored and analyzed. Can I do
something to improve the quality of my database statistics and let the
planner do
Robert Haas wrote:
BTW, the stuff that we have in pg_llog are not really logs at all, so
pg_llog was always a misnomer.
Also true.
For my part, I'd strongly prefer a name based on the term logical
decoding. This feature has lots of names (change-set extraction,
logical replication,
On Wed, Jun 4, 2014 at 5:10 PM, Andres Freund and...@2ndquadrant.com
wrote:
Looks like you're hitting the issue described in
http://archives.postgresql.org/message-id/20140530121631.GE25431%40alap3.anarazel.de
Aha, so the problem looks like this:
- all multixact contents was purged (9.2 to
Merlin Moncure mmonc...@gmail.com writes:
On Thu, Jun 5, 2014 at 9:54 AM, Linos i...@linos.es wrote:
What I don't understand is why the statistics have this bad information, all
my tests are done on a database just restored and analyzed. Can I do
something to improve the quality of my
Alvaro Herrera alvhe...@2ndquadrant.com writes:
Robert Haas wrote:
For my part, I'd strongly prefer a name based on the term logical
decoding.
There is no reason not to use long names, so I think pg_logical_decoding
is fine.
+1
regards, tom lane
--
Sent via
On June 5, 2014 7:43:06 PM CEST, Tom Lane t...@sss.pgh.pa.us wrote:
Alvaro Herrera alvhe...@2ndquadrant.com writes:
Robert Haas wrote:
For my part, I'd strongly prefer a name based on the term logical
decoding.
There is no reason not to use long names, so I think
pg_logical_decoding
is fine.
On Fri, May 30, 2014 at 8:08 AM, Heikki Linnakangas hlinnakan...@vmware.com
wrote:
On 05/29/2014 07:39 PM, Jeff Janes wrote:
It also implicitly tested the xlog parallel write slots thing, as that is
common code to all recovery.
During development, I hit a lot of bugs in that patch by
On 05/06/14 19:56, Andres Freund wrote:
On June 5, 2014 7:43:06 PM CEST, Tom Lane t...@sss.pgh.pa.us wrote:
Alvaro Herrera alvhe...@2ndquadrant.com writes:
Robert Haas wrote:
For my part, I'd strongly prefer a name based on the term logical
decoding.
There is no reason not to use long
On 05/06/14 19:39, Tom Lane wrote:
Merlin Moncure mmonc...@gmail.com writes:
On Thu, Jun 5, 2014 at 9:54 AM, Linos i...@linos.es wrote:
What I don't understand is why the statistics have this bad information,
all my tests are done on a database just restored and analyzed. Can I do
something
I wrote:
I think what we have to do is use a different dummy value for the node
label of a pushed-down allTheSame tuple than we do for end-of-string.
This requires widening the node labels from uint8 to (at least) int16.
However, I think that's essentially free because pass-by-value node
On Fri, Jun 6, 2014 at 2:43 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Alvaro Herrera alvhe...@2ndquadrant.com writes:
Robert Haas wrote:
For my part, I'd strongly prefer a name based on the term logical
decoding.
There is no reason not to use long names, so I think pg_logical_decoding
is fine.
On Thu, Jun 05, 2014 at 02:12:33AM +0200, Andres Freund wrote:
On 2014-06-04 20:04:07 -0400, Noah Misch wrote:
On Wed, Jun 04, 2014 at 10:14:42AM -0400, Tom Lane wrote:
It's possible that we could apply the optimization only to queries that
have been issued directly by a client, but that
Noah Misch n...@leadboat.com writes:
On Thu, Jun 05, 2014 at 02:12:33AM +0200, Andres Freund wrote:
A bit more crazy, but how about trying trying to plan joins with a added
one-time qual that checks the size of the deferred trigger queue? Then
we wouldn't even need special case plans.
That,
Oleg, Teodor, and Hackers:
Love what you’re doing with JSQuery. I’m curious, though, whether you
considered adopting an existing syntax, such as JSONPath.
http://goessner.net/articles/JsonPath/
Might be easier for people to pick up and use. Thoughts?
Best,
David
signature.asc
On 06/05/2014 08:08 PM, David E. Wheeler wrote:
Oleg, Teodor, and Hackers:
Love what you’re doing with JSQuery. I’m curious, though, whether you
considered adopting an existing syntax, such as JSONPath.
http://goessner.net/articles/JsonPath/
Might be easier for people to pick up and use.
On Jun 5, 2014, at 5:25 PM, Andrew Dunstan and...@dunslane.net wrote:
My understanding is that it's meant to be analogous to tsquery.
At first glance, JsonPath doesn't seem to support AND and OR operators, which
would make it rather less expressive than I gather JSQuery is meant to be.
On Thu, Jun 05, 2014 at 07:44:31PM -0400, Tom Lane wrote:
Noah Misch n...@leadboat.com writes:
On Thu, Jun 05, 2014 at 02:12:33AM +0200, Andres Freund wrote:
A bit more crazy, but how about trying trying to plan joins with a added
one-time qual that checks the size of the deferred trigger
2014-06-05 17:18 GMT+07:00 Marc Mamin m.ma...@intershop.de:
I'm thinking about adding a final function to my aggregate that would replace
zero values will nulls,
hence transforming the intarray into a standard int[], possibly with
nullbitmap and a lowerbound that can be 1.
This will
On Thu, Jun 05, 2014 at 10:57:03AM +0200, Andres Freund wrote:
On 2014-06-04 20:40:40 -0400, Peter Eisentraut wrote:
On Wed, 2014-05-07 at 03:08 +0200, Andres Freund wrote:
As an additional issue it currently doesn't seem to work in VPATH
builds. That's imo a must fix.
A cd
A question in pgsql-general made me reflect about how the planner isn't
smart about unreferenced output columns of subqueries that it's not able
to flatten into the parent query. Here's an example:
regression=# create table t1 (f1 int);
CREATE TABLE
regression=# create table t2 (f2 int primary
On Thu, Jun 5, 2014 at 10:27 PM, Tom Lane t...@sss.pgh.pa.us wrote:
I'm not entirely convinced that it's worth the extra planning cycles,
though. Given the small number of complaints to date, it might not
be worth doing this. Thoughts?
Would this avoid execution of expensive functions in
Rod Taylor rod.tay...@gmail.com writes:
On Thu, Jun 5, 2014 at 10:27 PM, Tom Lane t...@sss.pgh.pa.us wrote:
I'm not entirely convinced that it's worth the extra planning cycles,
though. Given the small number of complaints to date, it might not
be worth doing this. Thoughts?
Would this
On Thu, Jun 5, 2014 at 5:37 PM, Peter Geoghegan p...@heroku.com wrote:
Even still, the fact that every
implementation doesn't meet my standard came as a big surprise to me,
and so I hope that the problem is limited to Mac OSX. I'm slightly
concerned that all BSD systems are affected by this
On Thu, Jun 5, 2014 at 5:39 PM, Gurjeet Singh gurj...@singh.im wrote:
On Wed, Jun 4, 2014 at 12:54 AM, Amit Kapila amit.kapil...@gmail.com
wrote:
On Tue, Jun 3, 2014 at 5:43 PM, Gurjeet Singh gurj...@singh.im wrote:
For sizeable shared_buffers size, the restoration of the shared
buffers
59 matches
Mail list logo
