Hello everyone.
* Project name: Add recovery_timeout option to control timeout of
restore_command nonzero status code
* Uniquely identifiable file name, so we can tell difference between your v1
and v24: 0001-add-recovery_timeout-to-controll-timeout-between-res.patch
* What the patch does
On Mon, Nov 3, 2014 at 3:12 AM, Rushabh Lathia rushabh.lat...@gmail.com
wrote:
Patch looks good, assigning to committer.
Thanks for your review!
--
Fabrízio de Royes Mello
Consultoria/Coaching PostgreSQL
Timbira: http://www.timbira.com.br
Blog: http://fabriziomello.github.io
Linkedin:
Am Sonntag, den 02.11.2014, 12:41 -0500 schrieb Tom Lane:
BTW, after reflecting a bit more I'm less than convinced that this
datatype is completely useless. Even if you prefer to store currency
values in numeric columns, casting to or from money provides a way to
accept or emit values in
On 11/01/2014 10:04 PM, Mikko Tiihonen wrote:
Hi,
I created a proof of concecpt patch for postgresql JDBC driver that allows
the caller to do pipelining of requests within a transaction. The pipelining
here means same as for HTTP: the client can send the next execution already
before
On 11/02/2014 09:27 PM, Mikko Tiihonen wrote:
Is the following summary correct:
- the network protocol supports pipelinings
Yes.
All you have to do is *not* send a Sync message and be aware that the
server will discard all input until the next Sync, so pipelining +
autocommit doesn't make a
On Sat, Nov 1, 2014 at 9:09 PM, Robert Haas robertmh...@gmail.com wrote:
1. Any non-trivial piece of PostgreSQL code is likely to contain
syscache lookups.
2. Syscache lookups had better work in parallel workers, or they'll be
all but useless.
I've been using parallel sorts and index builds
Greg Stark st...@mit.edu writes:
On Sat, Nov 1, 2014 at 9:09 PM, Robert Haas robertmh...@gmail.com wrote:
2. Syscache lookups had better work in parallel workers, or they'll be
all but useless.
I've been using parallel sorts and index builds in my mental model of
how this will be used. I
On Mon, Nov 3, 2014 at 10:18 AM, Greg Stark st...@mit.edu wrote:
On Sat, Nov 1, 2014 at 9:09 PM, Robert Haas robertmh...@gmail.com wrote:
1. Any non-trivial piece of PostgreSQL code is likely to contain
syscache lookups.
2. Syscache lookups had better work in parallel workers, or they'll be
All,
That said, I don't feel very strongly about that position, so if you and
Robert (and others on the thread) agree that's the right approach then
I'll see about getting it done.
We haven't reached consensus on this one yet and I didn't want it to fall
too far off the radar.
Here is what
On Sun, Nov 2, 2014 at 7:31 AM, Simon Riggs si...@2ndquadrant.com wrote:
The main question is still why any of this is necessary? If we are
only acquiring fast path locks in workers, what need is there for any
of this? The leader and workers never conflict with each other, so why
would they
* Adam Brightwell (adam.brightw...@crunchydatasolutions.com) wrote:
That said, I don't feel very strongly about that position, so if you and
Robert (and others on the thread) agree that's the right approach then
I'll see about getting it done.
Thanks for trying to make progress on this.
Hi all,
we experienced what seems to be a bug in the COPY TO implementation. When a
table is being rewritten by an ALTER TABLE statement, a parallel COPY TO
results in an empty result.
Consider the following table data:
CREATE TABLE test (id INTEGER NOT NULL, PRIMARY KEY (id));
INSERT INTO
On 14 October 2014 20:33, Abhijit Menon-Sen a...@2ndquadrant.com wrote:
At 2014-10-14 20:09:50 +0100, si...@2ndquadrant.com wrote:
I think that's a good idea.
We could have pg_audit.roles = 'audit1, audit2'
Yes, it's a neat idea, and we could certainly do that. But why is it any
better
At 2014-11-03 17:31:37 +, si...@2ndquadrant.com wrote:
Stephen's suggestion allows auditing to be conducted without the
users/apps being aware it is taking place.
OK, that makes sense. I'm working on a revised patch that does things
this way, and will post it in a few days.
-- Abhijit
On 3 November 2014 17:00, Robert Haas robertmh...@gmail.com wrote:
On Sun, Nov 2, 2014 at 7:31 AM, Simon Riggs si...@2ndquadrant.com wrote:
The main question is still why any of this is necessary? If we are
only acquiring fast path locks in workers, what need is there for any
of this? The
On Mon, Nov 3, 2014 at 1:02 PM, Simon Riggs si...@2ndquadrant.com wrote:
OK, I think I'm happy with this as a general point.
Cool!
How will we automatically test this code?
Good question. I can see two possible approaches:
1. We write a test_group_locking harness along the lines of
On 11/1/14, 1:45 PM, Andrew Dunstan wrote:
On 11/01/2014 02:34 PM, Andres Freund wrote:
Yeah, if we were trying to duplicate the behavior of indisvalid, there'd
need to be a way to detect the invalid index at plan time and not use it.
But I'm not sure that that's actually an improvement from
Hi!
Given a transaction started with BEGIN (REPEATABLE READ |
SERIALIZABLE), if a concurrent session commits some data before *any*
query within the first transaction, that committed data is seen by the
transaction. This is not what I'd expect. Specifically, the
documentation
On Mon, Nov 03, 2014 at 01:54:09PM +0100, Michael Banck wrote:
Am Sonntag, den 02.11.2014, 12:41 -0500 schrieb Tom Lane:
BTW, after reflecting a bit more I'm less than convinced that this
datatype is completely useless. Even if you prefer to store currency
values in numeric columns,
David Fetter wrote:
On Mon, Nov 03, 2014 at 01:54:09PM +0100, Michael Banck wrote:
As an additional datapoint, Vitesse Data changed the DB schema from
NUMERIC to MONEY for their TPCH benchmark for performance reasons: The
modification to data types is easy to understand -- money and double
On 11/3/14 6:04 AM, Alexey Vasiliev wrote:
3. What the patch does in a short paragraph: This patch should add
option recovery_timeout, which help to control timeout of
restore_command nonzero status code. Right now default value is 5
seconds. This is useful, if I using for restore
On 11/2/14 11:36 AM, Tom Lane wrote:
Committed patch looks good, but should we also add the stanza we discussed
in Makefile.global.in concerning defining $(prove) in terms of missing
if we didn't find it? I think the behavior of HEAD when you ask for
--enable-tap-tests but don't have prove
On 11/1/14, 8:41 AM, Petr Jelinek wrote:
Well this is not BDR specific thing, the idea is that with logical replication,
commit timestamp is not enough for conflict handling, you also need to have
additional info in order to identify some types of conflicts conflicts (local
update vs remote
On Sat, Nov 1, 2014 at 10:26 AM, Andres Freund and...@2ndquadrant.com
wrote:
On 2014-11-01 10:18:03 -0700, Josh Berkus wrote:
On 10/31/2014 03:07 PM, Tom Lane wrote:
I don't care one way or the other about the money type, but I will
defend
hash indexes, especially seeing that we've
On 10/31/2014 03:46 PM, Andres Freund wrote:
On 2014-10-27 09:30:33 -0400, Tom Lane wrote:
Andres Freund and...@2ndquadrant.com writes:
On 2014-10-27 12:51:44 +0200, Heikki Linnakangas wrote:
replication/slot.c and replication/logical/snapbuild.c use a CRC on the
physical slot and snapshot
Peter Eisentraut pete...@gmx.net writes:
On 11/2/14 11:36 AM, Tom Lane wrote:
Committed patch looks good, but should we also add the stanza we discussed
in Makefile.global.in concerning defining $(prove) in terms of missing
if we didn't find it? I think the behavior of HEAD when you ask for
On 11/3/14, 1:34 PM, Alvaro Herrera wrote:
David Fetter wrote:
On Mon, Nov 03, 2014 at 01:54:09PM +0100, Michael Banck wrote:
As an additional datapoint, Vitesse Data changed the DB schema from
NUMERIC to MONEY for their TPCH benchmark for performance reasons: The
modification to data types is
Mon, 03 Nov 2014 14:36:33 -0500 от Peter Eisentraut pete...@gmx.net:
On 11/3/14 6:04 AM, Alexey Vasiliev wrote:
3. What the patch does in a short paragraph: This patch should add
option recovery_timeout, which help to control timeout of
restore_command nonzero status code. Right
Jim Nasby wrote:
On 11/1/14, 8:41 AM, Petr Jelinek wrote:
Well this is not BDR specific thing, the idea is that with logical
replication, commit timestamp is not enough for conflict handling, you also
need to have additional info in order to identify some types of conflicts
conflicts
On Wed, Oct 15, 2014 at 1:11 PM, Jeff Janes jeff.ja...@gmail.com wrote:
On Fri, Aug 8, 2014 at 12:08 AM, Guillaume Lelarge guilla...@lelarge.info
wrote:
Hi,
As part of our monitoring work for our customers, we stumbled upon an
issue with our customers' servers who have a wal_keep_segments
Hi.
I could actually use some comments on the approach. I've attached
a prototype I've been working on (which is a cut down version of
my earlier code; but it's not terribly interesting and you don't
need to read it to comment on my questions below). The attached
patch does the following:
1.
Abhijit Menon-Sen a...@2ndquadrant.com writes:
Earlier, I was using a combination of check and assign hooks to convert
names to OIDs, but (as Andres pointed out) that would have problems with
cache invalidations. I was even playing with caching membership lookups,
but I ripped out all that
On 11/3/14 3:11 PM, Tom Lane wrote:
Peter Eisentraut pete...@gmx.net writes:
On 11/2/14 11:36 AM, Tom Lane wrote:
Committed patch looks good, but should we also add the stanza we discussed
in Makefile.global.in concerning defining $(prove) in terms of missing
if we didn't find it? I think
Peter Eisentraut pete...@gmx.net writes:
On 11/3/14 3:11 PM, Tom Lane wrote:
If there's a commit that goes with this statement, you neglected to push
it...
Are you not seeing this in configure.in:
AC_CHECK_PROGS(PROVE, prove)
if test -z $PROVE; then
AC_MSG_ERROR([prove not
Should I change my patch and send it by email? And also as I understand I
should change message ID for
https://commitfest.postgresql.org/action/patch_view?id=1636, isn't it?
You should just send another version of your patch by email and add a new
comment to commit-fest using the Patch comment
=?ISO-8859-1?Q?=C1lvaro_Hern=E1ndez_Tortosa?= a...@8kdata.com writes:
IMHO, from a user perspective the transaction begins when the BEGIN
command is issued. If I really want to see a frozen view of the
database before any real SELECT, I have to issue another query like
SELECT 1. This
Mon, 3 Nov 2014 19:18:51 -0200 от Fabrízio de Royes Mello
fabriziome...@gmail.com:
Should I change my patch and send it by email? And also as I understand I
should change message ID for
https://commitfest.postgresql.org/action/patch_view?id=1636 , isn't it?
You should just
On 11/1/14 8:04 AM, Petr Jelinek wrote:
On second thought, maybe those should be pg_get_transaction_committs,
pg_get_transaction_committs_data, etc.
Please don't name anything committs. That looks like a misspelling of
something.
There is nothing wrong with
On 11/2/14 2:00 PM, Noah Misch wrote:
Ick; I concur with your judgment on those aspects of the IPC::Cmd design.
Thanks for investigating. So, surviving options include:
1. Require IPC::Run.
2. Write our own run() that reports the raw exit code.
3. Distill the raw exit code from the
Peter Eisentraut pete...@gmx.net writes:
I thank you for this research, but I suggest that we ship 9.4 as is,
that is with requiring IPC::Run and --enable-* option. All the possible
alternatives will clearly need more rounds of portability testing. We
can then evaluate these changes for 9.5
On 10/29/14 8:42 AM, Robert Haas wrote:
I'm sympathetic to that line of reasoning, but I really think that if
you want to keep this infrastructure, it needs to be made portable.
Let me clarify that this was my intention. I have looked at many test
frameworks, many of which are much nicer than
Alvaro Herrera alvhe...@2ndquadrant.com wrote:
There is a real advantage of money over numeric in the performance
front. I haven't measured it, but suffice to say that money uses
integer operations which map almost directly to CPU instructions,
whereas numeric needs to decode from our
On 03/11/14 22:19, Tom Lane wrote:
=?ISO-8859-1?Q?=C1lvaro_Hern=E1ndez_Tortosa?= a...@8kdata.com writes:
IMHO, from a user perspective the transaction begins when the BEGIN
command is issued. If I really want to see a frozen view of the
database before any real SELECT, I have to issue
Craig Ringer wrote:
On 11/02/2014 09:27 PM, Mikko Tiihonen wrote:
Is the following summary correct:
- the network protocol supports pipelinings
Yes.
All you have to do is *not* send a Sync message and be aware that the
server will discard all input until the next Sync, so pipelining +
On Mon, Nov 3, 2014 at 2:18 PM, Alvaro Herrera alvhe...@2ndquadrant.com
wrote:
Robert Haas wrote:
[lots]
I have fixed all these items in the attached, thanks -- most
user-visible change was the pageinspect 1.3 thingy. pg_upgrade from 1.2
works fine now. I also fixed some things Heikki
Hackers,
I'm looking at a couple of high-transaction-rate and high-FK-conflict
rate servers where pg_multixact has grown to be more than 1GB in size.
One such server doesn't appear to be having any notable issues with
vacuuming, and the oldest mxid on the system is about 47m old. VACUUM
FREEZEing
On Mon, Nov 3, 2014 at 7:25 PM, Alexey Vasiliev leopard...@inbox.ru wrote:
Mon, 3 Nov 2014 19:18:51 -0200 от Fabrízio de Royes Mello
fabriziome...@gmail.com:
Should I change my patch and send it by email? And also as I
understand I should change message ID for
Jeff Janes wrote:
On Mon, Nov 3, 2014 at 2:18 PM, Alvaro Herrera alvhe...@2ndquadrant.com
wrote:
I get a couple compiler warnings with this:
brin.c: In function 'brininsert':
brin.c:97: warning: 'tupcxt' may be used uninitialized in this function
brin.c:98: warning: 'oldcxt' may be used
Josh Berkus wrote:
Hackers,
I'm looking at a couple of high-transaction-rate and high-FK-conflict
rate servers where pg_multixact has grown to be more than 1GB in size.
One such server doesn't appear to be having any notable issues with
vacuuming, and the oldest mxid on the system is about
Mikko Tiihonen mikko.tiiho...@nitorcreations.com writes:
I do not quite grasp why not sending Sync is so important. My proof of
concept setup was for queries with autocommit enabled.
The point is that that will be very, very much harder to use than doing
it the other way. It's fairly easy to
On 11/03/2014 05:06 PM, Alvaro Herrera wrote:
Josh Berkus wrote:
Hackers,
I'm looking at a couple of high-transaction-rate and high-FK-conflict
rate servers where pg_multixact has grown to be more than 1GB in size.
One such server doesn't appear to be having any notable issues with
On Tue, Nov 04, 2014 at 07:51:06AM +0900, Tatsuo Ishii wrote:
The performance of our numeric vs Oracle's was a common complaint when
I was at EnterpriseDB (in 2007).
Perhaps numeric's performance could be greatly improved in cases where
the precision is low enough to map to an
On 11/04/2014 09:10 AM, Tom Lane wrote:
Mikko Tiihonen mikko.tiiho...@nitorcreations.com writes:
I do not quite grasp why not sending Sync is so important. My proof of
concept setup was for queries with autocommit enabled.
[snip] It'll be very much like
sending a fixed (predetermined) SQL
On Tue, Nov 4, 2014 at 10:40 AM, Demai Ni nid...@gmail.com wrote:
hi, hackers,
I am looking for a simple way to pass a value(ideally a hashtable, and use
a string for easy implementation for now), that is generated by coordinator
node, and pass it to all data nodes. Plans may be one
On 11/02/2014 11:41 AM, Tom Lane wrote:
Nothing that I recall at the moment, but there is certainly plenty of
stuff of dubious quality in there. I'd argue that chkpass, intagg,
intarray, isn, spi, and xml2 are all in worse shape than the money type.
Why are we holding on to xml2 again?
FWIW,
On Sun, Nov 2, 2014 at 2:30 AM, Tom Lane t...@sss.pgh.pa.us wrote:
In the case of hash indexes, because we still have to have the hash
opclasses in core, there's no way that it could be pushed out as an
extension module even if we otherwise had full support for AMs as
extensions. So what I
(2014/10/30 21:30), Fujii Masao wrote:
On Thu, Oct 30, 2014 at 7:30 PM, Etsuro Fujita
fujita.ets...@lab.ntt.co.jp wrote:
Here are my review comments.
* The patch applies cleanly and make and make check run successfully. I
think that the patch is mostly good.
Thanks! Attached is the
m...@bloodnok.com writes:
I have a script (below) that sets and resets the tablespace for a database
and drops and recreates a composite type. The script fails when trying to
re-create the previously dropped composite type because the type has
apparently been magically resuscitated by
Josh Berkus j...@agliodbs.com writes:
On 11/02/2014 11:41 AM, Tom Lane wrote:
Nothing that I recall at the moment, but there is certainly plenty of
stuff of dubious quality in there. I'd argue that chkpass, intagg,
intarray, isn, spi, and xml2 are all in worse shape than the money type.
Why
Michael Paquier michael.paqu...@gmail.com writes:
There is as well another way: finally support WAL-logging for hash indexes.
Sure, but that's a bit easier said than done. I think Robert looked into
that a year or two back and found some stumbling blocks that it wasn't
obvious how to surmount.
On Mon, Nov 03, 2014 at 04:40:39PM -0500, Tom Lane wrote:
Peter Eisentraut pete...@gmx.net writes:
I thank you for this research, but I suggest that we ship 9.4 as is,
that is with requiring IPC::Run and --enable-* option. All the possible
alternatives will clearly need more rounds of
Hello ,
Please find updated patch with the review comments given above implemented.
The compressed data now includes all backup blocks and their headers except
the header of first backup block in WAL record. The first backup block
header in WAL record is used to store the compression information.
Hi,
This is Feng from Vitesse. Performance different between Money and
Numeric is *HUGE*. For TPCH Q1, the performance difference is 5x for
stock postgres, and ~20x for vitesse.
Stock postgres, for my laptop, TPCH 1G, Q1, use money type ~ 9s, use
Numeric (15, 2) is ~53s.
Kevin,
test=# do
On 11/03/2014 03:41 AM, Tom Lane wrote:
Nothing that I recall at the moment, but there is certainly plenty of
stuff of dubious quality in there. I'd argue that chkpass, intagg,
intarray, isn, spi, and xml2 are all in worse shape than the money type.
What's wrong with intarray?
I'm aware of
Josh,
Do you have a list of what needs to be done to keep the MONEY type?
What is wrong with it?
Thanks,
-cktan
On Mon, Nov 3, 2014 at 10:30 PM, Feng Tian ft...@vitessedata.com wrote:
Hi,
This is Feng from Vitesse. Performance different between Money and Numeric
is *HUGE*. For TPCH Q1,
On 11/03/2014 07:05 AM, Scott Harrington wrote:
I looked over your patch. Your list of ResultHandlerHolders seems to be
the right direction, but as Tom Lane mentioned there may need to be some
way to ensure the statements are all in the same transaction.
Why go down this track, when we
On 11/04/2014 07:56 AM, Mikko Tiihonen wrote:
I do not quite grasp why not sending Sync is so important.
Well, at the moment the PgJDBC driver relies on the following flow to
manage its buffers and avoid a logjam where both server and client are
waiting for the other to consume input:
* Send
On 11/03/2014 07:05 AM, Scott Harrington wrote:
This avoids the need for a Future, and avoids the client having to
loop/sleep until done.
A Future is the logical way to represent an asynchronous operation in
Java. Why implement something else that doesn't fit into existing
libraries and tools
On 11/04/2014 07:56 AM, Mikko Tiihonen wrote:
I also think the async I/O is the way to go. Luckily that has already been
done
in the pgjdbc-ng (https://github.com/impossibl/pgjdbc-ng), built on top
of netty java NIO library. It has quite good feature parity with the original
pgjdbc driver.
69 matches
Mail list logo
