On 10 January 2014 00:36, Marko Tiikkaja ma...@joh.to wrote:
On 1/10/14, 1:20 AM, Merlin Moncure wrote:
I'm piling on: it's not clear at all to me why you've special cased
this to lower_bound=1. First of all, there are other reasons to check
length than iteration.
Yes, I agree. A length
On Fri, Jan 10, 2014 at 4:09 AM, Dean Rasheed dean.a.rash...@gmail.comwrote:
Hi,
Reading over this, I realised that there is a problem with NaN
handling --- once the state becomes NaN, it can never recover. So the
results using the inverse transition function don't match HEAD in
cases like
On Fri, Jan 10, 2014 at 5:15 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Dean Rasheed dean.a.rash...@gmail.com writes:
Reading over this, I realised that there is a problem with NaN
handling --- once the state becomes NaN, it can never recover. So the
results using the inverse transition
bool_or()
FALSE can be removed, removing TRUE requires a rescan. Could be made
fully invertible by counting the number of TRUE and FALSE values,
similar to my suggestion for how to handle NaN for sum(numeric).
Same works for bool_and().
bit_or()
Like boo_or(), 0 can be removed,
On 1/10/14, 9:04 AM, Dean Rasheed wrote:
On 10 January 2014 00:36, Marko Tiikkaja ma...@joh.to wrote:
Can you point me to some examples?
The example I see all the time is code like
if array_length(nodes, 1) 5 then
... do something ...
then you realise (or not as the case may be)
On Fri, Jan 10, 2014 at 2:04 AM, Dean Rasheed dean.a.rash...@gmail.com wrote:
On 10 January 2014 00:36, Marko Tiikkaja ma...@joh.to wrote:
On 1/10/14, 1:20 AM, Merlin Moncure wrote:
I'm piling on: it's not clear at all to me why you've special cased
this to lower_bound=1. First of all, there
On 10 January 2014 08:12, David Rowley dgrowle...@gmail.com wrote:
On Fri, Jan 10, 2014 at 4:09 AM, Dean Rasheed dean.a.rash...@gmail.com
wrote:
Hi,
Reading over this, I realised that there is a problem with NaN
handling --- once the state becomes NaN, it can never recover. So the
results
On 1/10/14, 10:41 AM, Merlin Moncure wrote:
What's needed for better iteration support (IMO)
is a function that does what unnest does but returns an array on
indexes (one per dimsension) -- a generalization of the
_pg_expandarray function. Lets' say 'unnest_dims'.
So
On Fri, Jan 10, 2014 at 3:52 AM, Marko Tiikkaja ma...@joh.to wrote:
On 1/10/14, 10:41 AM, Merlin Moncure wrote:
What's needed for better iteration support (IMO)
is a function that does what unnest does but returns an array on
indexes (one per dimsension) -- a generalization of the
Hi Steeve,
Il 09/01/14 22:38, Steeve Lennmark ha scritto:
I'm a barman user myself so that was actually my initial thought.
Ah! Very good!
If there aren't some kind of hidden internal that I've missed I don't see
a way to convert an OID (only have OID and path at this stage) to a
tablespace
On Fri, Jan 10, 2014 at 12:25 PM, Gabriele Bartolini
gabriele.bartol...@2ndquadrant.it wrote:
Hi Steeve,
Il 09/01/14 22:38, Steeve Lennmark ha scritto:
I'm a barman user myself so that was actually my initial thought.
Ah! Very good!
If there aren't some kind of hidden internal that I've
On 2014-01-10 12:27:23 +0100, Magnus Hagander wrote:
On Fri, Jan 10, 2014 at 12:25 PM, Gabriele Bartolini
gabriele.bartol...@2ndquadrant.it wrote:
Hi Steeve,
Il 09/01/14 22:38, Steeve Lennmark ha scritto:
I'm a barman user myself so that was actually my initial thought.
Ah! Very
On Jan10, 2014, at 11:00 , Merlin Moncure mmonc...@gmail.com wrote:
On Fri, Jan 10, 2014 at 3:52 AM, Marko Tiikkaja ma...@joh.to wrote:
On 1/10/14, 10:41 AM, Merlin Moncure wrote:
What's needed for better iteration support (IMO)
is a function that does what unnest does but returns an array
On Jan10, 2014, at 09:34 , David Rowley dgrowle...@gmail.com wrote:
I just don't quite know yet the base way for the inverse transition function
to communicate this to the caller yet. If you have any ideas on the best way
to do this then I'd really like to hear them.
Could they maybe just
On Fri, Jan 10, 2014 at 6:00 AM, Florian Pflug f...@phlo.org wrote:
On Jan10, 2014, at 11:00 , Merlin Moncure mmonc...@gmail.com wrote:
On Fri, Jan 10, 2014 at 3:52 AM, Marko Tiikkaja ma...@joh.to wrote:
On 1/10/14, 10:41 AM, Merlin Moncure wrote:
What's needed for better iteration support
Florian Pflug f...@phlo.org writes:
On Jan10, 2014, at 09:34 , David Rowley dgrowle...@gmail.com wrote:
I just don't quite know yet the base way for the inverse transition function
to communicate this to the caller yet. If you have any ideas on the best way
to do this then I'd really like to
On 01/10/2014 05:36 AM, Peter Geoghegan wrote:
While I realize that everyone is busy, I'm concerned about the lack of
discussing here. It's been 6 full days since I posted my benchmark,
which I expected to quickly clear some things up, or at least garner
interest, and yet no one has commented
On 01/08/2014 06:46 AM, Peter Geoghegan wrote:
A new revision of my patch is attached.
I'm getting deadlocks with this patch, using the test script you posted
earlier in
http://www.postgresql.org/message-id/CAM3SWZQh=8xnvgbbzyhjexujbhwznjutjez9t-dbo9t_mx_...@mail.gmail.com.
Am doing
Hello, Pgsql-hackers.
As you probably know dealing with Windows MSVCRT is some kind of hell.
That's why we have src/port/win32env.c particulalry, because there may
be several CRT's loaded at the same time.
libpq unfortunately is using standard getenv function call to
fill connection parameters
On 8 January 2014 20:42, Alvaro Herrera alvhe...@2ndquadrant.com wrote:
CREATE SCHEMA IF NOT EXISTS some schema AUTHORIZATION some guy;
Hmm, given in 9.3 it was OK to have only DROP event triggers, I think
it should be equally acceptable to have just CREATE, but without every
option on CREATE.
2. Provide a new reloption to specify Wal compression
for update operation on table
Create table tbl(c1 char(100)) With (compress_wal = true);
Alternative options:
a. compress_wal can take input as operation, e.g. 'insert', 'update',
b. use alternate syntax:
On Thu, Jan 9, 2014 at 5:17 PM, Jim Nasby j...@nasby.net wrote:
On 1/9/14, 11:58 AM, Alvaro Herrera wrote:
Robert Haas escribió:
On Wed, Jan 8, 2014 at 10:27 PM, Alvaro Herrera
alvhe...@2ndquadrant.com wrote:
Hmm. This seems like a reasonable thing to do, except that I would like
the
On Fri, Jan 10, 2014 at 10:21:42AM +0530, Amit Kapila wrote:
On Thu, Jan 9, 2014 at 10:45 PM, Bruce Momjian br...@momjian.us wrote:
I think RAID-1 is a very good comparison because it is successful
technology and has similar issues.
RAID-1 is like Postgres synchronous_standby_names mode
On Fri, Jan 10, 2014 at 10:36 AM, Simon Riggs si...@2ndquadrant.com wrote:
On 8 January 2014 20:42, Alvaro Herrera alvhe...@2ndquadrant.com wrote:
CREATE SCHEMA IF NOT EXISTS some schema AUTHORIZATION some guy;
Hmm, given in 9.3 it was OK to have only DROP event triggers, I think
it should
On 10 January 2014 15:48, Robert Haas robertmh...@gmail.com wrote:
On Fri, Jan 10, 2014 at 10:36 AM, Simon Riggs si...@2ndquadrant.com wrote:
On 8 January 2014 20:42, Alvaro Herrera alvhe...@2ndquadrant.com wrote:
CREATE SCHEMA IF NOT EXISTS some schema AUTHORIZATION some guy;
Hmm, given in
On 10 January 2014 15:47, Bruce Momjian br...@momjian.us wrote:
I know there was a desire to remove this TODO item, but I think we have
brought up enough new issues that we can keep it to see if we can come
up with a solution.
Can you summarise what you think the new issues are? All I see is
Kadri Raudsepp kadri.rauds...@nordicgaming.com writes:
I have set up a cron-job that sends me daily reports on bloat amount in
tables and indices, which I calculate using pg_stats, not pgstattuple, for
performance and I/O reasons. If the bloat amount or percentage are big
enough, I use
On Thu, Jan 2, 2014 at 03:34:04PM +0100, Bernd Helmle wrote:
--On 1. Januar 2014 23:53:46 +0100 Dimitri Fontaine
dimi...@2ndquadrant.fr wrote:
Hi,
As much as I've seen people frown upon $subject, it still happens in the
wild, and Magnus seems to agree that the current failure mode of
On Jan10, 2014, at 15:49 , Tom Lane t...@sss.pgh.pa.us wrote:
Florian Pflug f...@phlo.org writes:
Looking at the code it seems that for quite a few existing aggregates,
the state remains NULL until the first non-NULL input is processed. But
that doesn't hurt much - those aggregates can remain
Florian Pflug f...@phlo.org writes:
On Jan10, 2014, at 15:49 , Tom Lane t...@sss.pgh.pa.us wrote:
Also, it might be reasonable for both the regular and the inverse
transition functions to be strict. If a null entering the window
does not matter, then a null exiting the window doesn't either,
On Fri, Jan 10, 2014 at 10:55 AM, Simon Riggs si...@2ndquadrant.com wrote:
On 10 January 2014 15:48, Robert Haas robertmh...@gmail.com wrote:
On Fri, Jan 10, 2014 at 10:36 AM, Simon Riggs si...@2ndquadrant.com wrote:
On 8 January 2014 20:42, Alvaro Herrera alvhe...@2ndquadrant.com wrote:
Florian Pflug f...@phlo.org wrote:
Tom Lane t...@sss.pgh.pa.us wrote:
Florian Pflug f...@phlo.org writes:
For float 4 and float8, wasn't the consensus that the potential
lossy-ness of addition makes this impossible anyway, even
without the NaN issue? But...
Well, that was my opinion, I'm
On 01/10/2014 05:09 PM, Simon Riggs wrote:
On 10 January 2014 15:47, Bruce Momjian br...@momjian.us wrote:
I know there was a desire to remove this TODO item, but I think we have
brought up enough new issues that we can keep it to see if we can come
up with a solution.
Can you summarise what
Kevin Grittner kgri...@ymail.com writes:
Aggregates on approximate (floating-point) numbers are not nearly
as consistent as many people probably assume. Picture for a minute
a table where a column contains positive floating point numbers
happen to be located in the heap in increasing order,
Is it just me, or is the json_array_element(json, int) function not
documented?
(Not a bug in this patch, I think ...)
--
Álvaro Herrerahttp://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training Services
--
Sent via pgsql-hackers mailing list
On 10 January 2014 17:07, Robert Haas robertmh...@gmail.com wrote:
On Fri, Jan 10, 2014 at 10:55 AM, Simon Riggs si...@2ndquadrant.com wrote:
On 10 January 2014 15:48, Robert Haas robertmh...@gmail.com wrote:
On Fri, Jan 10, 2014 at 10:36 AM, Simon Riggs si...@2ndquadrant.com wrote:
On 8
On 01/10/2014 12:42 PM, Alvaro Herrera wrote:
Is it just me, or is the json_array_element(json, int) function not
documented?
(Not a bug in this patch, I think ...)
As discussed at the time, we didn't document the functions underlying
the json operators, just the operators themselves.
On Jan10, 2014, at 18:14 , Kevin Grittner kgri...@ymail.com wrote:
Given that this is already the case with aggregates on floating
point approximate numbers, why should we rule out an optimization
which only makes rounding errors more likely to be visible? The
real issue here is that if you
I wrote:
Kevin Grittner kgri...@ymail.com writes:
The real issue here is that if you are using an approximate data type
and expecting exact answers, you will have problems.
That's a canard. People who know what they're doing (admittedly a
minority) do not expect exact answers, but they do
On Fri, Jan 10, 2014 at 12:59 PM, Simon Riggs si...@2ndquadrant.com wrote:
That's project policy
and always has been. When somebody implements 50% of a feature, or
worse yet 95% of a feature, it violates the POLA for users and doesn't
always subsequently get completed, leaving us with
On Thu, Jan 9, 2014 at 12:46 PM, Claudio Freire klaussfre...@gmail.com wrote:
On Thu, Jan 9, 2014 at 2:22 PM, Robert Haas robertmh...@gmail.com wrote:
It would be nice to have better operating system support for this.
For example, IIUC, 64-bit Linux has 128TB of address space available
for
On Thu, Jan 9, 2014 at 2:09 PM, Amit Kapila amit.kapil...@gmail.com wrote:
On Thu, Jan 9, 2014 at 12:21 AM, Robert Haas robertmh...@gmail.com wrote:
On Tue, Jan 7, 2014 at 10:20 PM, Amit Kapila amit.kapil...@gmail.com wrote:
On Tue, Jan 7, 2014 at 2:46 AM, Robert Haas robertmh...@gmail.com
Andrew Dunstan and...@dunslane.net writes:
On 01/10/2014 12:42 PM, Alvaro Herrera wrote:
Is it just me, or is the json_array_element(json, int) function not
documented?
As discussed at the time, we didn't document the functions underlying
the json operators, just the operators themselves.
On Thu, Jan 9, 2014 at 5:08 PM, Andrew Dunstan and...@dunslane.net wrote:
* I have replicated all the json processing functions for jsonb
(although not the json generating functions, such as to_json). Most
of these currently work by turning the jsonb back into json and then
On Fri, Jan 10, 2014 at 3:23 PM, Robert Haas robertmh...@gmail.com wrote:
On Thu, Jan 9, 2014 at 12:46 PM, Claudio Freire klaussfre...@gmail.com
wrote:
On Thu, Jan 9, 2014 at 2:22 PM, Robert Haas robertmh...@gmail.com wrote:
It would be nice to have better operating system support for this.
On 01/10/2014 01:29 PM, Robert Haas wrote:
On Thu, Jan 9, 2014 at 5:08 PM, Andrew Dunstan and...@dunslane.net wrote:
* The jsonb regression test currently contains U+ABCD - I guess we'd
better use some hex encoding or whatever for that - unlike json, the
jsonb de-serializer dissolves
On Fri, Jan 10, 2014 at 7:12 AM, Heikki Linnakangas
hlinnakan...@vmware.com wrote:
I'm getting deadlocks with this patch, using the test script you posted
earlier in
http://www.postgresql.org/message-id/CAM3SWZQh=8xnvgbbzyhjexujbhwznjutjez9t-dbo9t_mx_...@mail.gmail.com.
Am doing something
On 01/10/2014 01:27 PM, Tom Lane wrote:
Andrew Dunstan and...@dunslane.net writes:
On 01/10/2014 12:42 PM, Alvaro Herrera wrote:
Is it just me, or is the json_array_element(json, int) function not
documented?
As discussed at the time, we didn't document the functions underlying
the json
On Fri, Jan 10, 2014 at 1:35 PM, Claudio Freire klaussfre...@gmail.com wrote:
You can map a segment at fork time, and unmap it after forking. That
doesn't really use RAM, since it's supposed to be lazily allocated (it
can be forced to be so, I believe, with PROT_NONE and MAP_NORESERVE,
but I
On Jan10, 2014, at 19:08 , Tom Lane t...@sss.pgh.pa.us wrote:
I wrote:
Kevin Grittner kgri...@ymail.com writes:
The real issue here is that if you are using an approximate data type
and expecting exact answers, you will have problems.
That's a canard. People who know what they're doing
Andrew Dunstan and...@dunslane.net writes:
On 01/10/2014 01:27 PM, Tom Lane wrote:
See commits 94133a935414407920a47d06a6e22734c974c3b8 and
908ab80286401bb20a519fa7dc7a837631f20369.
OK, I can fix that I guess.
Sure, just remove the DESCR comments for the functions that aren't meant
to be
On 01/10/2014 07:47 AM, Bruce Momjian wrote:
I know there was a desire to remove this TODO item, but I think we have
brought up enough new issues that we can keep it to see if we can come
up with a solution. I have added a link to this discussion on the TODO
item.
I think we will need at
Tom Lane wrote:
I wonder whether we should add an opr_sanity test verifying that operator
implementation functions don't have their own comments? The trouble is
that there are a few that are supposed to, but maybe that list is stable
enough that it'd be okay to memorialize in the expected
Andrew Dunstan wrote:
On 01/10/2014 12:42 PM, Alvaro Herrera wrote:
Is it just me, or is the json_array_element(json, int) function not
documented?
As discussed at the time, we didn't document the functions
underlying the json operators, just the operators themselves.
Oh, I see. That's
Robert Haas robertmh...@gmail.com writes:
I've often thought that 64-bit machines are so capable that there's no
reason to go any higher. But lately I've started to wonder. There
are already machines out there with 2^40 bytes of physical memory,
and the number just keeps creeping up. When
Florian Pflug f...@phlo.org writes:
On Jan10, 2014, at 19:08 , Tom Lane t...@sss.pgh.pa.us wrote:
Although, having said that ... maybe build your own aggregate would
be a reasonable suggestion for people who need this? I grant that
it's going to be a minority requirement, maybe even a small
On 01/10/2014 01:58 PM, Tom Lane wrote:
Andrew Dunstan and...@dunslane.net writes:
On 01/10/2014 01:27 PM, Tom Lane wrote:
See commits 94133a935414407920a47d06a6e22734c974c3b8 and
908ab80286401bb20a519fa7dc7a837631f20369.
OK, I can fix that I guess.
Sure, just remove the DESCR comments for
On 01/10/2014 08:37 PM, Peter Geoghegan wrote:
On Fri, Jan 10, 2014 at 7:12 AM, Heikki Linnakangas
hlinnakan...@vmware.com wrote:
I'm getting deadlocks with this patch, using the test script you posted
earlier in
All,
To make this easier for everyone to participate in, I've created a wiki
page:
https://wiki.postgresql.org/wiki/9.4CF4Triage
Please add the patches you know well to the appropriate list, thanks!
--
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com
--
Sent via pgsql-hackers
Alvaro Herrera alvhe...@2ndquadrant.com writes:
Oh, I see. That's fine with me. From the source code it's hard to see
when a SQL-callable function is only there to implement an operator,
though (and it seems a bit far-fetched to suppose that the developer
will think, upon seeing an
Andrew Dunstan and...@dunslane.net writes:
The history here is that originally I was intending to have these
functions documented, and so the descriptions were made to match the
operator descriptions, so that we didn't get a failure on this test.
Later we decided not to document them as
On Fri, Jan 10, 2014 at 02:39:12PM -0500, Tom Lane wrote:
Andrew Dunstan and...@dunslane.net writes:
The history here is that originally I was intending to have these
functions documented, and so the descriptions were made to match the
operator descriptions, so that we didn't get a
On Fri, Jan 10, 2014 at 11:28 AM, Heikki Linnakangas
hlinnakan...@vmware.com wrote:
Why does it deadlock with the btreelock patch? I don't see why it should. If
you have two backends inserting a single tuple, and they conflict, one of
them should succeed to insert, and the other one should
FYI, I'm using the verb rewind to talk about using the negative transition
aggregation function to get a prior value. I don't know if this is the right
verb.
Conceptually, when aggregating over floating point numbers, there is some
infinitely precise theoretical value, and the computation is
On Tue, Jan 7, 2014 at 08:19:49AM -0500, Peter Eisentraut wrote:
That was probably me. I'll look into it.
On Jan 6, 2014, at 11:40 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Bruce Momjian br...@momjian.us writes:
On Sun, Dec 29, 2013 at 02:48:21AM -0500, Tom Lane wrote:
3.
Bruce Momjian br...@momjian.us writes:
On Tue, Jan 7, 2014 at 08:19:49AM -0500, Peter Eisentraut wrote:
That was probably me. I'll look into it.
and in pg_log_v() I see:
switch (type)
...
case PG_FATAL:
printf(\n%s, _(message));
Bruce Momjian wrote:
I know Peter is looking at this, but I looked at and I can't see the
problem. Every call of exec_prog() that uses pg_resetxlog has
throw_error = true, and the test there is:
result = system(cmd);
if (result != 0)
...
pg_log(FATAL, ...)
and
On Fri, Jan 10, 2014 at 04:06:11PM -0500, Tom Lane wrote:
Bruce Momjian br...@momjian.us writes:
On Tue, Jan 7, 2014 at 08:19:49AM -0500, Peter Eisentraut wrote:
That was probably me. I'll look into it.
and in pg_log_v() I see:
switch (type)
...
case
On 01/10/2014 10:00 PM, Peter Geoghegan wrote:
On Fri, Jan 10, 2014 at 11:28 AM, Heikki Linnakangas
hlinnakan...@vmware.com wrote:
Why does it deadlock with the btreelock patch? I don't see why it should. If
you have two backends inserting a single tuple, and they conflict, one of
them should
On 1/9/14, 10:58 PM, Tom Lane wrote:
Jim Nasby j...@nasby.net writes:
ISTM that allowing users to pick arbitrary lower array bounds was a huge
mistake. I've never seen anyone make use of it, can't think of any legitimate
use cases for it, and hate the stupendous amount of extra code needed to
On Sat, Jan 11, 2014 at 7:08 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Although, having said that ... maybe build your own aggregate would
be a reasonable suggestion for people who need this? I grant that
it's going to be a minority requirement, maybe even a small minority
requirement. People
On Sat, Jan 11, 2014 at 8:28 AM, Josh Berkus j...@agliodbs.com wrote:
All,
To make this easier for everyone to participate in, I've created a wiki
page:
https://wiki.postgresql.org/wiki/9.4CF4Triage
Please add the patches you know well to the appropriate list, thanks!
I know my own
On 1/10/14, 12:59 PM, Joshua D. Drake wrote:
I know I am the one that instigated all of this so I want to be very clear on
what I and what I am confident that my customers would expect.
If a synchronous slave goes down, the master continues to operate. That is all.
I don't care if it is
On 10 January 2014 18:17, Robert Haas robertmh...@gmail.com wrote:
On Fri, Jan 10, 2014 at 12:59 PM, Simon Riggs si...@2ndquadrant.com wrote:
That's project policy
and always has been. When somebody implements 50% of a feature, or
worse yet 95% of a feature, it violates the POLA for users and
On 01/10/2014 04:26 PM, Jim Nasby wrote:
On 1/9/14, 10:58 PM, Tom Lane wrote:
Jim Nasby j...@nasby.net writes:
ISTM that allowing users to pick arbitrary lower array bounds was a
huge mistake. I've never seen anyone make use of it, can't think of
any legitimate use cases for it, and hate the
On 2014-01-10 10:59:23 -0800, Joshua D. Drake wrote:
On 01/10/2014 07:47 AM, Bruce Momjian wrote:
I know there was a desire to remove this TODO item, but I think we have
brought up enough new issues that we can keep it to see if we can come
up with a solution. I have added a link to this
* Andres Freund (and...@2ndquadrant.com) wrote:
On 2014-01-10 10:59:23 -0800, Joshua D. Drake wrote:
If a synchronous slave goes down, the master continues to operate. That is
all. I don't care if it is configurable (I would be fine with that). I don't
care if it is not automatic (e.g;
On Fri, Jan 10, 2014 at 03:26:04PM -0600, Jim Nasby wrote:
On 1/9/14, 10:58 PM, Tom Lane wrote:
Jim Nasby j...@nasby.net writes:
ISTM that allowing users to pick arbitrary lower array bounds was
a huge mistake. I've never seen anyone make use of it, can't think
of any legitimate use cases for
Gavin Flower gavinflo...@archidevsys.co.nz wrote:
Starting arrays at zero makes the most sense, as then you can
calculate the displacement simply as (index) * (size of entry),
and not have subtract one from the index first. This would be my
preference.
The SQL standard explicitly specifies
On Fri, Jan 10, 2014 at 1:26 PM, Jim Nasby j...@nasby.net wrote:
On 1/9/14, 10:58 PM, Tom Lane wrote:
Jim Nasby j...@nasby.net writes:
ISTM that allowing users to pick arbitrary lower array bounds was a huge
mistake. I've never seen anyone make use of it, can't think of any
legitimate use
On Fri, Jan 10, 2014 at 4:10 PM, Jeff Janes jeff.ja...@gmail.com wrote:
On Fri, Jan 10, 2014 at 1:26 PM, Jim Nasby j...@nasby.net wrote:
On 1/9/14, 10:58 PM, Tom Lane wrote:
Jim Nasby j...@nasby.net writes:
ISTM that allowing users to pick arbitrary lower array bounds was a huge
mistake.
On 2014-01-10 17:02:08 -0500, Stephen Frost wrote:
* Andres Freund (and...@2ndquadrant.com) wrote:
On 2014-01-10 10:59:23 -0800, Joshua D. Drake wrote:
If a synchronous slave goes down, the master continues to operate. That is
all. I don't care if it is configurable (I would be fine with
Andres,
On Friday, January 10, 2014, Andres Freund wrote:
On 2014-01-10 17:02:08 -0500, Stephen Frost wrote:
* Andres Freund (and...@2ndquadrant.com javascript:;) wrote:
On 2014-01-10 10:59:23 -0800, Joshua D. Drake wrote:
If a synchronous slave goes down, the master continues to
On 01/10/2014 01:49 PM, Andres Freund wrote:
I know I am the one that instigated all of this so I want to be very clear
on what I and what I am confident that my customers would expect.
If a synchronous slave goes down, the master continues to operate. That is
all. I don't care if it is
On 2014-01-10 14:29:58 -0800, Joshua D. Drake wrote:
db02 goes down. It doesn't matter why. It is down. db01 continues to accept
orders, allow people to log into the website and we can still service
accounts. The continuity of service continues.
Why is that configuration advantageous over a
On Fri, Jan 10, 2014 at 1:25 PM, Heikki Linnakangas
hlinnakan...@vmware.com wrote:
This is pretty much the same issue we discussed wrt. exclusion contraints.
If the tuple being inserted conflicts with several existing tuples, what to
do? I think the best answer would be to return and lock them
On 01/10/2014 02:33 PM, Andres Freund wrote:
On 2014-01-10 14:29:58 -0800, Joshua D. Drake wrote:
db02 goes down. It doesn't matter why. It is down. db01 continues to accept
orders, allow people to log into the website and we can still service
accounts. The continuity of service continues.
On 01/10/2014 02:33 PM, Andres Freund wrote:
On 2014-01-10 14:29:58 -0800, Joshua D. Drake wrote:
db02 goes down. It doesn't matter why. It is down. db01 continues to accept
orders, allow people to log into the website and we can still service
accounts. The continuity of service continues.
Hi,
On 2014-01-10 17:28:55 -0500, Stephen Frost wrote:
Why do you know that you didn't loose any transactions? Trivial network
hiccups, a restart of a standby, IO overload on the standby all can
cause a very short interruptions in the walsender connection - leading
to degradation.
You
On Fri, Jan 10, 2014 at 2:33 PM, Andres Freund and...@2ndquadrant.comwrote:
On 2014-01-10 14:29:58 -0800, Joshua D. Drake wrote:
db02 goes down. It doesn't matter why. It is down. db01 continues to
accept
orders, allow people to log into the website and we can still service
accounts. The
On 2014-01-10 14:44:28 -0800, Joshua D. Drake wrote:
On 01/10/2014 02:33 PM, Andres Freund wrote:
On 2014-01-10 14:29:58 -0800, Joshua D. Drake wrote:
db02 goes down. It doesn't matter why. It is down. db01 continues to accept
orders, allow people to log into the website and we can still
Greetings,
On Friday, January 10, 2014, Andres Freund wrote:
Hi,
On 2014-01-10 17:28:55 -0500, Stephen Frost wrote:
Why do you know that you didn't loose any transactions? Trivial network
hiccups, a restart of a standby, IO overload on the standby all can
cause a very short
On 01/10/2014 02:47 PM, Andres Freund wrote:
Really, the commits themselves are sent to the server at exactly the
same speed independent of sync/async. The only thing that's delayed is
the *notificiation* of the client that sent the commit. Not the commit
itself.
Which is irrelevant to the
On 01/10/2014 02:57 PM, Stephen Frost wrote:
Yes, if you have a BBU that memory is authoritative in most cases. But
in that case the argument of having two disks is pretty much pointless,
the SPOF suddenly became the battery + ram.
If that is a concern then use multiple
On 01/10/2014 11:59 PM, Joshua D. Drake wrote:
On 01/10/2014 02:57 PM, Stephen Frost wrote:
Yes, if you have a BBU that memory is authoritative in most
cases. But
in that case the argument of having two disks is pretty much
pointless,
the SPOF suddenly became the battery + ram.
On 01/10/2014 02:59 PM, Joshua D. Drake wrote:
On 01/10/2014 02:47 PM, Andres Freund wrote:
Really, the commits themselves are sent to the server at exactly the
same speed independent of sync/async. The only thing that's delayed is
the *notificiation* of the client that sent the commit.
Can we please stop arguing over a problem I don't have? I started with
CREATE SCHEMA because it is one of the easy cases, not because it was
the most difficult case: we only need to deparse the bits of it that
don't involve the objects within, because those are reported by the
event trigger as
On 01/10/2014 01:49 PM, Andres Freund wrote:
On 2014-01-10 10:59:23 -0800, Joshua D. Drake wrote:
On 01/10/2014 07:47 AM, Bruce Momjian wrote:
I know there was a desire to remove this TODO item, but I think we have
brought up enough new issues that we can keep it to see if we can come
up
On 01/10/2014 01:34 PM, David Rowley wrote:
On Sat, Jan 11, 2014 at 8:28 AM, Josh Berkus j...@agliodbs.com wrote:
All,
To make this easier for everyone to participate in, I've created a wiki
page:
https://wiki.postgresql.org/wiki/9.4CF4Triage
Please add the patches you know well to the
On 01/10/2014 03:17 PM, Josh Berkus wrote:
Any continuous replication should not be a SPOF. The current behavior
guarantees that a two node sync cluster is a SPOF. The proposed behavior
removes that.
Again, if that's your goal, then use async replication.
I think I have gone about this the
1 - 100 of 143 matches
Mail list logo
