On 2015-02-22 21:24:56 -0500, Robert Haas wrote:
On Sat, Feb 21, 2015 at 11:29 PM, Petr Jelinek p...@2ndquadrant.com wrote:
I am wondering a bit about interaction with wal_keep_segments.
One thing is that wal_keep_segments is still specified in number of segments
and not size units, maybe
Tomas == Tomas Vondra tomas.von...@2ndquadrant.com writes:
Tomas Interesting, but I think Gavin was asking about how much
Tomas variation was there for each tested case (e.g. query executed on
Tomas the same code / dataset). And in those cases the padding /
Tomas alignment won't change, and
Amit and I had a long discussion about this on Friday while in Boston
together. I previously argued that the master and the slave should be
executing the same node, ParallelSeqScan. However, Amit argued
persuasively that what the master is doing is really pretty different
from what the
On 02/22/2015 02:05 PM, Andres Freund wrote:
On 2015-02-22 01:27:54 +0100, Emil Lenngren wrote:
I honestly wonder why postgres uses renegotiation at all. The motivation
that cryptoanalysis is easier as more data is sent seems quite
far-fetched.
I don't think so. There's a fair number of
On Mon, Feb 23, 2015 at 5:57 PM, Rushabh Lathia rushabh.lat...@gmail.com
wrote:
Thanks to the easy handy testcase, was able to replicate the test scenario
on my local environment. And yes tbinfo-dobj.ext_member check into
getTableAttrs() do fix the issue.
Looking more into pg_dump code what I
On Fri, Feb 20, 2015 at 9:33 PM, Michael Paquier
michael.paqu...@gmail.com wrote:
On Fri, Feb 20, 2015 at 9:12 PM, Fujii Masao masao.fu...@gmail.com wrote:
On Tue, Feb 10, 2015 at 10:32 PM, Michael Paquier
michael.paqu...@gmail.com wrote:
On Mon, Feb 9, 2015 at 8:29 PM, Fujii Masao
Hi,
Andres asked me on IRC to report this here. Since we upgraded our
standby servers to 9.1.15 (though the master is still running 9.1.14),
we've seen the error in $SUBJECT a number of times. I managed to
reproduce it today by running the same query over and over again, and
attached is
On Feb 22, 2015, at 5:41 AM, Michael Paquier michael.paqu...@gmail.com
wrote:
This is up to the maintainer of each extension to manage their code
tree. However I can imagine that some people would be grateful if we
allow them to not need sql/ and expected/ containing only one single
Hi,
On 2015-02-23 15:00:35 +0100, Marko Tiikkaja wrote:
Andres asked me on IRC to report this here. Since we upgraded our standby
servers to 9.1.15 (though the master is still running 9.1.14), we've seen
the error in $SUBJECT a number of times.
FWIW, I think this is just as borked in 9.1.14
On Mon, Feb 23, 2015 at 5:28 PM, Rahila Syed rahilasye...@gmail.com wrote:
Hello,
Attached is a patch which has following changes,
As suggested above block ID in xlog structs has been replaced by chunk ID.
Chunk ID is used to distinguish between different types of xlog record
fragments.
Hi,
On 2015-02-23 15:25:57 +, Thom Brown wrote:
I've noticed that if the primary is started and then a base backup is
immediately taken from it and started as as a synchronous standby, it
doesn't replicate and the primary hangs indefinitely when trying to run any
WAL-generating
Hi,
I've noticed that if the primary is started and then a base backup is
immediately taken from it and started as as a synchronous standby, it
doesn't replicate and the primary hangs indefinitely when trying to run any
WAL-generating statements. It only recovers when either the primary is
On 2015-02-23 16:38:44 +0100, Andres Freund wrote:
I unfortunately don't remember enough of the thread to reference it
here.
Found the right keywords. The threads below
http://archives.postgresql.org/message-id/369698E947874884A77849D8FE3680C2%40maumau
and
On 23 February 2015 at 15:38, Andres Freund and...@2ndquadrant.com wrote:
Hi,
On 2015-02-23 15:25:57 +, Thom Brown wrote:
I've noticed that if the primary is started and then a base backup is
immediately taken from it and started as as a synchronous standby, it
doesn't replicate and
Florian Weimer wrote:
On 02/22/2015 02:05 PM, Andres Freund wrote:
On 2015-02-22 01:27:54 +0100, Emil Lenngren wrote:
I honestly wonder why postgres uses renegotiation at all. The motivation
that cryptoanalysis is easier as more data is sent seems quite
far-fetched.
I don't think so.
Hi,
On 2014-07-26 18:16:01 +0200, Andres Freund wrote:
On 2014-07-26 11:32:24 -0400, Tom Lane wrote:
MauMau maumau...@gmail.com writes:
[ sinval catchup signal - ProcessCatchupEvent - WaitLatch - deadlock ]
Ugh.
One line of thought is that it's pretty unsafe to be doing anything
On 23 February 2015 at 15:42, Andres Freund and...@2ndquadrant.com wrote:
On 2015-02-23 16:38:44 +0100, Andres Freund wrote:
I unfortunately don't remember enough of the thread to reference it
here.
Found the right keywords. The threads below
On 2015-02-17 13:14:00 -0500, Tom Lane wrote:
Hm, good point. On the other hand, should we worry about the possibility
of a lost signal? Moving the flag-clearing would guard against that,
which the current code does not. But we've not seen field reports of such
issues AFAIR, so this might
Thank you for your answers.
I am very eager to contribute to Postgres, especially in the materialized
views area.
I have created a thread
http://www.postgresql.org/message-id/cak7uwezzxjjsxp9uoxwhpnjjutjajvpkja9skzalsnnrdjs...@mail.gmail.com
proposing
to work on it as my Google Summer of Code
On 02/23/2015 01:01 PM, Andres Freund wrote:
On 2015-02-22 21:24:56 -0500, Robert Haas wrote:
On Sat, Feb 21, 2015 at 11:29 PM, Petr Jelinek p...@2ndquadrant.com wrote:
I am wondering a bit about interaction with wal_keep_segments.
One thing is that wal_keep_segments is still specified in
Hi, Petr, thanks for the review.
I think it would be better if the ident printing didn't put the start
of array ([) and start of dictionary ({) on separate line
Did you mean this?
[
{
a: 1,
b: 2
}
]
I tried to verify this in several ways
Le 17/02/2015 14:44, Michael Paquier a écrit :
On Tue, Jan 20, 2015 at 8:06 PM, Gilles Darold gilles.dar...@dalibo.com
wrote:
Le 19/01/2015 14:41, Robert Haas a écrit :
On Thu, Jan 15, 2015 at 6:26 AM, Gilles Darold gilles.dar...@dalibo.com
wrote:
I attach a patch that solves the issue in
Hi
When I tested json_populate_function in test
http://stackoverflow.com/questions/7711432/how-to-set-value-of-composite-variable-field-using-dynamic-sql/28673097#28673097
I found a small issue
create type pt as (a int, b int);
postgres=# select json_populate_record('(10,20)'::pt, '{}');
On 2015-02-23 15:48:25 +, Thom Brown wrote:
On 23 February 2015 at 15:42, Andres Freund and...@2ndquadrant.com wrote:
On 2015-02-23 16:38:44 +0100, Andres Freund wrote:
I unfortunately don't remember enough of the thread to reference it
here.
Found the right keywords. The
On 2/18/15 10:25 AM, David Steele wrote:
On 2/18/15 6:11 AM, Fujii Masao wrote:
The pg_audit doesn't log BIND parameter values when prepared statement is
used.
Seems this is an oversight of the patch. Or is this intentional?
It's actually intentional - following the model I talked about in
Hi,
On 22.2.2015 22:30, Peter Geoghegan wrote:
On Sun, Feb 22, 2015 at 1:19 PM, Tomas Vondra
tomas.von...@2ndquadrant.com wrote:
In short, this fixes all the cases except for the ASC sorted data. I
haven't done any code review, but I think we want this.
I'll use data from the i5-2500k, but
Hi,
On 23.2.2015 11:59, Andrew Gierth wrote:
Tomas == Tomas Vondra tomas.von...@2ndquadrant.com writes:
Tomas Interesting, but I think Gavin was asking about how much
Tomas variation was there for each tested case (e.g. query executed on
Tomas the same code / dataset). And in those cases
On 23 February 2015 at 16:53, Andres Freund and...@2ndquadrant.com wrote:
On 2015-02-23 15:48:25 +, Thom Brown wrote:
On 23 February 2015 at 15:42, Andres Freund and...@2ndquadrant.com
wrote:
On 2015-02-23 16:38:44 +0100, Andres Freund wrote:
I unfortunately don't remember enough
On 2015-02-23 15:15:31 +0100, Florian Weimer wrote:
On 02/22/2015 02:05 PM, Andres Freund wrote:
On 2015-02-22 01:27:54 +0100, Emil Lenngren wrote:
I honestly wonder why postgres uses renegotiation at all. The motivation
that cryptoanalysis is easier as more data is sent seems quite
Renegotiation should be a best practice. Trouble is it's been broken (at the
protocol level) three times in the last few years so it's a massive hole in
practice.
Ideally we should leave the renegotiate in, and only remove it if configure
detects a broken version of TLS.
Personal email.
Hi Stephen,
Thanks for your review. All fixed except for comments below:
On 2/17/15 10:34 AM, Stephen Frost wrote:
+/*
+ * Check privileges granted indirectly via role memberships. We do this
in
+ * a separate pass to minimize expensive indirect membership tests. In
+ *
On Sun, Feb 22, 2015 at 10:18 PM, Kevin Grittner kgri...@ymail.com wrote:
Amit Kapila amit.kapil...@gmail.com wrote:
It seems to me that SQL Server also uses similar mechanism to
avoid the bloat in version store (place to store previous
versions or record).
I think if other leading
David Fetter wrote:
My thinking behind this was that the patch is a bug fix and intended
to be back-patched, so I wanted to mess with as little infrastructure
as possible. A new version of libpq seems like a very big ask for
such a case. You'll recall that the original problem was that
On Mon, Feb 23, 2015 at 11:17 AM, Tomas Vondra
tomas.von...@2ndquadrant.com wrote:
So while it's true that for the 3rd query we get much worse results
compared to the other queries (i.e. we don't get 400% speedup but ~3%
slowdown compared to master), it's true that master performs
Here's the real attachment. Previous one was a misguided shell
redirection. Meh.
--
Álvaro Herrerahttp://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training Services
From 830d41b9d23716af29491cbab59808c35e25ec12 Mon Sep 17 00:00:00 2001
From: Alvaro
On 01/13/2015 01:22 PM, Marco Nenciarini wrote:
Il 08/01/15 20:18, Jim Nasby ha scritto:
On 1/7/15, 3:50 AM, Marco Nenciarini wrote:
The current implementation tracks only heap LSN. It currently does not
track any kind of indexes, but this can be easily added later.
Would it make sense to do
by the way - this feature is undocumented - I though so only value used as
type holder is not used.
Should be documented better, - if I understand - it is base stone for
implementation #= hstore operator
some nice example
postgres=# select json_populate_record('(10,20)'::pt, '{a:30}');
On Mon, Feb 23, 2015 at 8:40 AM, Tomas Vondra
tomas.von...@2ndquadrant.com wrote:
The durations are much higher than without the single unsorted row added
at the end. Queries often take 20x longer to finish (on the same code),
depending on the scale.
I knew this would happen. :-)
What's
On 15 February 2015 at 03:06, Andrew Dunstan and...@dunslane.net wrote:
Attached is a patch to provide a number of very useful facilities to jsonb
that people have asked for. These are based on work by Dmitry Dolgov in his
jsonbx extension, but I take responsibility for any bugs.
The
On 23.2.2015 19:22, Peter Geoghegan wrote:
On Mon, Feb 23, 2015 at 8:40 AM, Tomas Vondra
tomas.von...@2ndquadrant.com wrote:
The durations are much higher than without the single unsorted row added
at the end. Queries often take 20x longer to finish (on the same code),
depending on the scale.
I found that the OBJECT_ATTRIBUTE symbol is useless. I can just remove
it and replace it with OBJECT_COLUMN, and everything continues to work;
no test fails that I can find.
I thought we had a prohibition against ALTER TABLE when used on
composites, but it's not as severe as I thought. The
While fooling around with testing operator precedence warnings,
I discovered that there's some existing precedence behavior that's
not at all what I expected. Consider these examples (all done in
9.4; this is longstanding behavior):
regression=# SELECT 1 '(3,4)'::point LIKE 42.0;
ERROR:
On 02/15/2015 02:19 AM, Kevin Grittner wrote:
Interestingly, the btree README points out that using the old TID
with a new tuple poses no hazard for a scan using an MVCC snapshot,
because the new tuple would not be visible to a snapshot created
that long ago.
The first question is: Do we
I wrote:
I'm not seeing any terribly pleasing ways to fix this. Aside from
the option of doing nothing, it seems like these are the choices:
1. We could hack base_yylex() to reduce NOT LIKE to a single token
which could be given the same precedence as LIKE. Ditto for the other
four cases.
Hello,
Attached is a patch which has following changes,
As suggested above block ID in xlog structs has been replaced by chunk ID.
Chunk ID is used to distinguish between different types of xlog record
fragments.
Like,
XLR_CHUNK_ID_DATA_SHORT
XLR_CHUNK_ID_DATA_LONG
XLR_CHUNK_BKP_COMPRESSED
Thanks to the easy handy testcase, was able to replicate the test scenario
on my local environment. And yes tbinfo-dobj.ext_member check into
getTableAttrs() do fix the issue.
Looking more into pg_dump code what I found that, generally PG don't have
tbinfo-dobj.ext_member check to ignore the
23.02.2015, 04:31, Robert Haas kirjoitti:
On Tue, Feb 17, 2015 at 8:41 AM, Oskari Saarenmaa o...@ohmu.fi wrote:
15.01.2015, 21:58, Robert Haas kirjoitti:
On Wed, Jan 14, 2015 at 5:54 PM, Andres Freund and...@2ndquadrant.com
wrote:
I think I'd for now simply not define pg_attribute_aligned()
Andres,
* Andres Freund (and...@2ndquadrant.com) wrote:
On 2015-02-21 14:51:32 -0500, Stephen Frost wrote:
It'd be *really* nice to be able to pass an object identifier to some
function and get back the CREATE (in particular, though perhaps DROP, or
whatever) command for it. This gets us
On Mon, Feb 23, 2015 at 8:57 PM, Fujii Masao masao.fu...@gmail.com wrote:
So I pushed the patch.
Thank you.
--
Michael
On Tue, Feb 24, 2015 at 2:17 AM, Gilles Darold gilles.dar...@dalibo.com
wrote:
Looks great to me, I have tested with the postgis_topology extension
everything works fine.
Actually, after looking more in depth at the internals of pg_dump I think
that both patches are wrong (did that yesterday
Please see check_object_ownership(). It checks relation's ownership
if OBJECT_COLUMN, however, type's ownership is the correct check if
OBJECT_ATTRIBUTE.
--
NEC OSS Promotion Center / PG-Strom Project
KaiGai Kohei kai...@ak.jp.nec.com
-Original Message-
From:
On Sun, Feb 22, 2015 at 07:57:41PM -0500, Tom Lane wrote:
Robert Haas robertmh...@gmail.com writes:
On Fri, Feb 20, 2015 at 12:59 AM, Noah Misch n...@leadboat.com wrote:
On Mon, Feb 02, 2015 at 03:48:33PM -0500, Robert Haas wrote:
If readir() fails and closedir() succeeds, the return will
Hi,
On 2015-02-23 19:48:43 -0500, Stephen Frost wrote:
Yes, it might be possible to use the same code for a bunch of minor
commands, but not for the interesting/complex stuff.
We can clearly rebuild at least CREATE commands for all objects without
access to the parse tree, obviously
On 24.2.2015 01:44, Peter Geoghegan wrote:
On Mon, Feb 23, 2015 at 4:41 PM, Tomas Vondra
tomas.von...@2ndquadrant.com wrote:
Are you going to add this into the CF? Would be nice to get this into
9.5. Strictly speaking it should go to 2015-06 I guess, but I'd consider
it part of one of the
Hello,
At Thu, 19 Feb 2015 15:30:53 -0500, Peter Eisentraut pete...@gmx.net wrote in
54e647fd.5000...@gmx.net
On 2/18/15 3:44 AM, Kyotaro HORIGUCHI wrote:
Hello, this is the patchset v2 of this feature.
0001-Add-regrole.patch
0002-Add-regnamespace.patch
Kouhei Kaigai wrote:
Please see check_object_ownership(). It checks relation's ownership
if OBJECT_COLUMN, however, type's ownership is the correct check if
OBJECT_ATTRIBUTE.
Hmm. Is there any case where the two are different?
AlterObjectTypeCommandTag()?
OBJECT_ATTRIBUTE makes ALTER
On Mon, Feb 23, 2015 at 4:41 PM, Tomas Vondra
tomas.von...@2ndquadrant.com wrote:
Are you going to add this into the CF? Would be nice to get this into
9.5. Strictly speaking it should go to 2015-06 I guess, but I'd consider
it part of one of the existing sortsupport patches.
It's a bugfix,
On Tue, Feb 24, 2015 at 11:35 AM, Kyotaro HORIGUCHI
horiguchi.kyot...@lab.ntt.co.jp wrote:
Hello,
At Thu, 19 Feb 2015 15:30:53 -0500, Peter Eisentraut pete...@gmx.net
wrote in 54e647fd.5000...@gmx.net
On 2/18/15 3:44 AM, Kyotaro HORIGUCHI wrote:
Hello, this is the patchset v2 of this
On 2/23/15 6:55 PM, Michael Paquier wrote:
Hi all,
This is a purely informational email...
I have put my hands on a Raspberry PI 2, and I have found that it takes
6 minutes to compile the backend code using the 4 cores of the ARMv7
processor, and close to 20 minutes on a single core
On Mon, Feb 23, 2015 at 7:45 PM, Michael Paquier michael.paqu...@gmail.com
wrote:
On Mon, Feb 23, 2015 at 5:57 PM, Rushabh Lathia rushabh.lat...@gmail.com
wrote:
Thanks to the easy handy testcase, was able to replicate the test
scenario
on my local environment. And yes
Hi all,
This is a purely informational email...
I have put my hands on a Raspberry PI 2, and I have found that it takes 6
minutes to compile the backend code using the 4 cores of the ARMv7
processor, and close to 20 minutes on a single core (without ccache). The
test has been done using ArchLinux
Michael,
This is a purely informational email...
I have put my hands on a Raspberry PI 2, and I have found that it takes 6
minutes to compile the backend code using the 4 cores of the ARMv7
processor, and close to 20 minutes on a single core (without ccache). The
test has been done using
On 23.2.2015 21:52, Peter Geoghegan wrote:
On Mon, Feb 23, 2015 at 11:17 AM, Tomas Vondra
tomas.von...@2ndquadrant.com wrote:
So while it's true that for the 3rd query we get much worse results
compared to the other queries (i.e. we don't get 400% speedup but ~3%
slowdown compared to master),
On Fri, Feb 20, 2015 at 3:44 PM, Peter Geoghegan p...@heroku.com wrote:
they'd only see a
REORDER_BUFFER_CHANGE_INSERT when that was the definitive outcome of
an UPSERT, or alternatively a REORDER_BUFFER_CHANGE_UPDATE when that
was the definitive outcome. No need for output plugins to consider
On Mon, Feb 23, 2015 at 2:48 PM, Heikki Linnakangas
hlinnakan...@vmware.com wrote:
Robert pointed out that the visibility information
for an index-only scan wasn't checked while the index page READ
lock was held, so those scans also still hold the pins.
Why does an index-only scan need to
Tomas == Tomas Vondra tomas.von...@2ndquadrant.com writes:
Tomas I believe the small regressions (1-10%) for small data sets,
Tomas might be caused by this 'random padding' effect, because that's
Tomas probably where L1/L2 cache is most important. For large datasets
Tomas the caches are
On Mon, Feb 23, 2015 at 12:52 PM, Heikki Linnakangas
hlinnakan...@vmware.com wrote:
Dunno, but Jim's got a point. This is a maintenance burden to all indexams,
if they all have to remember to update the LSN map separately. It needs to
be done in some common code, like in PageSetLSN or
Kouhei Kaigai wrote:
Please see check_object_ownership(). It checks relation's ownership
if OBJECT_COLUMN, however, type's ownership is the correct check if
OBJECT_ATTRIBUTE.
Hmm. Is there any case where the two are different?
--
Álvaro Herrerahttp://www.2ndQuadrant.com/
Hi,
attached is the result of my first attempt to make the logical column
ordering patch work. This touches a lot of code in the executor that is
mostly new to me, so if you see something that looks like an obvious
bug, it probably is (so let me know).
improvements
The main
69 matches
Mail list logo
