On 10 January 2014 00:36, Marko Tiikkaja 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 funct
On Fri, Jan 10, 2014 at 4:09 AM, Dean Rasheed 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 using the inverse transition function don't match HEAD in
> cases like this:
>
> create ta
On Fri, Jan 10, 2014 at 5:15 AM, Tom Lane wrote:
> Dean Rasheed 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 function don't match HEAD in
> > cases lik
>
>
> 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
On 1/10/14, 9:04 AM, Dean Rasheed wrote:
On 10 January 2014 00:36, Marko Tiikkaja 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) that this doesn
On Fri, Jan 10, 2014 at 2:04 AM, Dean Rasheed wrote:
> On 10 January 2014 00:36, Marko Tiikkaja 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 che
On 10 January 2014 08:12, David Rowley wrote:
> On Fri, Jan 10, 2014 at 4:09 AM, Dean Rasheed
> 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 using the inverse transition fu
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 unnest_dims('{{1,2},{3,4}
On Fri, Jan 10, 2014 at 3:52 AM, Marko Tiikkaja 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
>> _pg_expandar
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
> tablespa
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
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.
On Jan10, 2014, at 11:00 , Merlin Moncure wrote:
> On Fri, Jan 10, 2014 at 3:52 AM, Marko Tiikkaja 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
On Jan10, 2014, at 09:34 , David Rowley 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 return NULL as the n
On Fri, Jan 10, 2014 at 6:00 AM, Florian Pflug wrote:
> On Jan10, 2014, at 11:00 , Merlin Moncure wrote:
>> On Fri, Jan 10, 2014 at 3:52 AM, Marko Tiikkaja wrote:
>>> On 1/10/14, 10:41 AM, Merlin Moncure wrote:
What's needed for better iteration support (IMO)
is a function that do
Florian Pflug writes:
> On Jan10, 2014, at 09:34 , David Rowley 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 m
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 her
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 somethin
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 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. CREATE SCHEMA is ea
> 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 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
>>> wrote:
>>
>>
Hmm. This seems like a reasonable thing to do, except that I would like
the "output" to always
On Fri, Jan 10, 2014 at 10:21:42AM +0530, Amit Kapila wrote:
> On Thu, Jan 9, 2014 at 10:45 PM, Bruce Momjian 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 in th
On Fri, Jan 10, 2014 at 10:36 AM, Simon Riggs wrote:
> On 8 January 2014 20:42, Alvaro Herrera 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 C
On 10 January 2014 15:48, Robert Haas wrote:
> On Fri, Jan 10, 2014 at 10:36 AM, Simon Riggs wrote:
>> On 8 January 2014 20:42, Alvaro Herrera 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 t
On 10 January 2014 15:47, 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.
Can you summarise what you think the new issues are? All I see is some
further r
Kadri Raudsepp 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 pg_repack to get rid of it. At some
On Thu, Jan 2, 2014 at 03:34:04PM +0100, Bernd Helmle wrote:
>
>
> --On 1. Januar 2014 23:53:46 +0100 Dimitri Fontaine
> 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 our
> >pg
On Jan10, 2014, at 15:49 , Tom Lane wrote:
> Florian Pflug 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 as they are until
>> some
Florian Pflug writes:
> On Jan10, 2014, at 15:49 , Tom Lane 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, no?
> That's not true, I
On Fri, Jan 10, 2014 at 10:55 AM, Simon Riggs wrote:
> On 10 January 2014 15:48, Robert Haas wrote:
>> On Fri, Jan 10, 2014 at 10:36 AM, Simon Riggs wrote:
>>> On 8 January 2014 20:42, Alvaro Herrera wrote:
>>>
CREATE SCHEMA IF NOT EXISTS "some schema" AUTHORIZATION "some guy";
>>>
>>> Hmm
Florian Pflug wrote:
> Tom Lane wrote:
>> Florian Pflug 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 not sure if it was consensus ;-
On 01/10/2014 05:09 PM, Simon Riggs wrote:
> On 10 January 2014 15:47, 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.
> Can you summarise what you thi
Kevin Grittner 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, perhaps as
> th
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 (pgsql-hackers@p
On 10 January 2014 17:07, Robert Haas wrote:
> On Fri, Jan 10, 2014 at 10:55 AM, Simon Riggs wrote:
>> On 10 January 2014 15:48, Robert Haas wrote:
>>> On Fri, Jan 10, 2014 at 10:36 AM, Simon Riggs wrote:
On 8 January 2014 20:42, Alvaro Herrera wrote:
> CREATE SCHEMA IF NOT EXIST
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.
ch
On Jan10, 2014, at 18:14 , Kevin Grittner 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 are using an ap
I wrote:
> Kevin Grittner 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 expect to be
On Fri, Jan 10, 2014 at 12:59 PM, Simon Riggs 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 long-term warts
>> th
On Thu, Jan 9, 2014 at 12:46 PM, Claudio Freire wrote:
> On Thu, Jan 9, 2014 at 2:22 PM, Robert Haas 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 user processes. When you clone(), it ca
On Thu, Jan 9, 2014 at 2:09 PM, Amit Kapila wrote:
> On Thu, Jan 9, 2014 at 12:21 AM, Robert Haas wrote:
>> On Tue, Jan 7, 2014 at 10:20 PM, Amit Kapila wrote:
>>> On Tue, Jan 7, 2014 at 2:46 AM, Robert Haas wrote:
Well, right now we just reopen the same object from all of the
pr
Andrew Dunstan 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.
I see though
On Thu, Jan 9, 2014 at 5:08 PM, Andrew Dunstan 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
>processing as before. I a
On Fri, Jan 10, 2014 at 3:23 PM, Robert Haas wrote:
> On Thu, Jan 9, 2014 at 12:46 PM, Claudio Freire
> wrote:
>> On Thu, Jan 9, 2014 at 2:22 PM, Robert Haas wrote:
>>> It would be nice to have better operating system support for this.
>>> For example, IIUC, 64-bit Linux has 128TB of address sp
On 01/10/2014 01:29 PM, Robert Haas wrote:
On Thu, Jan 9, 2014 at 5:08 PM, Andrew Dunstan 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 unicode escapes.
H
On Fri, Jan 10, 2014 at 7:12 AM, Heikki Linnakangas
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 wrong, or is that a regr
On 01/10/2014 01:27 PM, Tom Lane wrote:
Andrew Dunstan 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 oper
On Fri, Jan 10, 2014 at 1:35 PM, Claudio Freire 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 don't think
On Jan10, 2014, at 19:08 , Tom Lane wrote:
> I wrote:
>> Kevin Grittner 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)
Andrew Dunstan 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 used directly.
I
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 leas
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.
Robert Haas 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 you reserve a coup
Florian Pflug writes:
> On Jan10, 2014, at 19:08 , Tom Lane 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.
On 01/10/2014 01:58 PM, Tom Lane wrote:
Andrew Dunstan 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 a
On 01/10/2014 08:37 PM, Peter Geoghegan wrote:
On Fri, Jan 10, 2014 at 7:12 AM, Heikki Linnakangas
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.
A
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 mailin
Alvaro Herrera 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 undocumented function, "oh thi
Andrew Dunstan 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 part of last releas
On Fri, Jan 10, 2014 at 02:39:12PM -0500, Tom Lane wrote:
> Andrew Dunstan 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 tes
On Fri, Jan 10, 2014 at 11:28 AM, Heikki Linnakangas
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 update.
Are you sure tha
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 wrote:
> >
> > Bruce Momjian writes:
> >>> On Sun, Dec 29, 2013 at 02:48:21AM -0500, Tom Lane wrote:
> >>> 3. pg_upgrade ignores the fac
Bruce Momjian 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));
> printf("Failure,
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, ...)
On Fri, Jan 10, 2014 at 04:06:11PM -0500, Tom Lane wrote:
> Bruce Momjian 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_FAT
On 01/10/2014 10:00 PM, Peter Geoghegan wrote:
On Fri, Jan 10, 2014 at 11:28 AM, Heikki Linnakangas
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 th
On 1/9/14, 10:58 PM, Tom Lane wrote:
Jim Nasby 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 deal
with it.
On Sat, Jan 11, 2014 at 7:08 AM, Tom Lane 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 who have the
On Sat, Jan 11, 2014 at 8:28 AM, Josh Berkus 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 patch pretty
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 config
On 10 January 2014 18:17, Robert Haas wrote:
> On Fri, Jan 10, 2014 at 12:59 PM, Simon Riggs 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
On 01/10/2014 04:26 PM, Jim Nasby wrote:
On 1/9/14, 10:58 PM, Tom Lane wrote:
Jim Nasby 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 amo
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
* 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 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
Gavin Flower 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 that arrays positions rang
On Fri, Jan 10, 2014 at 1:26 PM, Jim Nasby wrote:
> On 1/9/14, 10:58 PM, Tom Lane wrote:
>
>> Jim Nasby 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,
On Fri, Jan 10, 2014 at 4:10 PM, Jeff Janes wrote:
> On Fri, Jan 10, 2014 at 1:26 PM, Jim Nasby wrote:
>>
>> On 1/9/14, 10:58 PM, Tom Lane wrote:
>>>
>>> Jim Nasby writes:
ISTM that allowing users to pick arbitrary lower array bounds was a huge
mistake. I've never seen anyone make
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 fi
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 ) wrote:
> > > On 2014-01-10 10:59:23 -0800, Joshua D. Drake wrote:
> > > > If a synchronous slave goes down, the master continues to operate.
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 config
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
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 all. It could
> still
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.
Why
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.
W
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.
On Fri, Jan 10, 2014 at 2: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 s
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
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 shor
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 po
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 controller
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 ba
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 co
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 se
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
On 01/10/2014 01:34 PM, David Rowley wrote:
> On Sat, Jan 11, 2014 at 8:28 AM, Josh Berkus 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
