On Sun, Oct 13, 2013 at 2:08 PM, Gibheer wrote:
> On Sun, 13 Oct 2013 11:38:17 +0530
> Amit Kapila wrote:
>
>> On Thu, Oct 10, 2013 at 3:17 AM, Gibheer
>> wrote:
>> > On Mon, 7 Oct 2013 11:39:55 +0530
>> > Amit Kapila wrote:
>> >> Robert Haas wrote:
>> >> On Mon, Aug 5, 2013 at 2:04 AM, Andres
Hi
I developed a new character string type, named myvarchar.
Also an operator class for btree is added.
I created a table with two columns, first have myvarchar(100) and other is
varchar(100).
CREATE TABLE test_myvarchar (mine myvarchar(100), plain varchar(100));
CREATE INDEX test_myvarchar_i_
On Wed, Oct 9, 2013 at 1:11 PM, Peter Geoghegan wrote:
> Unfortunately, I have a very busy schedule in the month ahead,
> including travelling to Ireland and Japan, so I don't think I'm going
> to get the opportunity to work on this too much. I'll try and produce
> a V4 that formally proposes some
On 2013-10-12 09:04:55 +0200, Magnus Hagander wrote:
> Frankly, I think we'd help 1000 times more users of we enabled a few wal
> writers by default and jumped the wal level. Mainly so they could run one
> off base backup. That's used by orders of magnitude more users than XA.
Yes, I've thought ab
Magnus Hagander writes:
> Frankly, I think we'd help 1000 times more users of we enabled a few wal
> writers by default and jumped the wal level. Mainly so they could run one
> off base backup. That's used by orders of magnitude more users than XA.
+1, or += default max_wal_senders actually ;-)
"MauMau" writes:
> I understand this problem occurs only when the user configured the
> application server to use distributed transactions, the application server
> crashed between prepare and commit/rollback, and the user doesn't recover
> the application server. So only improper operation produ
On 2013-10-13 20:39:21 +0200, Tom Lane wrote:
> Andres Freund writes:
> > The question about platforms that simply cannot provide such atomics
> > like PA-RISC, which afaics is the only one, remains tho. I am not sure
> > we really want to provide codepaths that are only going to be tested
> > the
Andres Freund writes:
> The question about platforms that simply cannot provide such atomics
> like PA-RISC, which afaics is the only one, remains tho. I am not sure
> we really want to provide codepaths that are only going to be tested
> there.
PA-RISC is a dead architecture. According to wikip
On 2013-10-13 16:56:12 +0200, Tom Lane wrote:
> Andres Freund writes:
> > That's a fair point. But all of them will use gcc, right? I've
> > previously thought we'd need 4.4 because there's an incompatibility
> > between 4.3 and 4.4 but I think it won't touch us, so 4.2 which added
> > atomics for
Le samedi 12 octobre 2013 07:30:35 Kohei KaiGai a écrit :
> 2013/10/10 Ronan Dunklau :
> Sorry, I'm uncertain the point above.
> Are you saying FDW driver may be able to handle well a case when
> a remote tuple to be updated is different from a remote tuple being
> fetched on the first stage? Or,
Andres Freund writes:
> That's a fair point. But all of them will use gcc, right? I've
> previously thought we'd need 4.4 because there's an incompatibility
> between 4.3 and 4.4 but I think it won't touch us, so 4.2 which added
> atomics for mips seems fine. Given there's no buildfarm animal and
On 2013-10-13 14:08:59 +0200, Andres Freund wrote:
> On 2013-10-13 11:34:42 +0200, Tom Lane wrote:
> > Andres Freund writes:
> > > I think we should remove support for the following architectures:
> > > - superH
> >
> > This one was contributed just a year or two ago, if memory serves,
> > which
On 2013-10-13 11:34:42 +0200, Tom Lane wrote:
> Andres Freund writes:
> > I think we should remove support for the following architectures:
> > - superH
>
> This one was contributed just a year or two ago, if memory serves,
> which suggests that somebody out there cares about it. OTOH, if
> they
On 2013-10-12 18:35:00 -0700, Peter Geoghegan wrote:
> Not so sure about these.
> > - M32R (no userspace CAS afaics)
I don't think M32R will hurt us/anybody much.
> > - 32bit/ > - mips for anything but gcc > 4.4, using gcc's atomics support
The reason I'd like to de-support mips for older GCCs i
2013-10-11 00:16 keltezéssel, Alvaro Herrera írta:
Boszormenyi Zoltan escribió:
2013-09-10 03:04 keltezéssel, Peter Eisentraut írta:
You need to update the dblink regression tests.
Done.
Dude, this is an humongous patch.
You *know* that the patch is available in pieces at
https://github.co
On 11/10/13 19:06, Andres Freund wrote:
On 2013-10-11 09:22:50 +0530, Amit Kapila wrote:
I think it will be difficult to prove by using any compression
algorithm, that it compresses in most of the scenario's.
In many cases it can so happen that the WAL will also not be reduced
and tps can also c
Andres Freund writes:
> I think we should remove support for the following architectures:
> - superH
This one was contributed just a year or two ago, if memory serves,
which suggests that somebody out there cares about it. OTOH, if
they still care, we could insist they provide whatever atomic op
On Sun, 13 Oct 2013 11:38:17 +0530
Amit Kapila wrote:
> On Thu, Oct 10, 2013 at 3:17 AM, Gibheer
> wrote:
> > On Mon, 7 Oct 2013 11:39:55 +0530
> > Amit Kapila wrote:
> >> Robert Haas wrote:
> >> On Mon, Aug 5, 2013 at 2:04 AM, Andres Freund
> >> wrote:
> >> >>> Hmm. It seems like this match
On Wed, Oct 9, 2013 at 1:10 AM, Robert Haas wrote:
> On Thu, Sep 26, 2013 at 9:27 AM, Noah Misch wrote:
>>> > "There's no data corruption problem if we proceed" - but there likely
>>> > has been one leading to the current state.
>>
>> +1 for making this one a PANIC, though. With startup behind u
19 matches
Mail list logo
