Hello,
> > I'll look into the case after this, but I'd like to send a
> > revised patch at this point.
> Hm. Seems like this patch is not completely baked yet. Horiguchi-san,
> as you are obviously still working on it, would you agree to move it
> to the next CF?
Yes, that's fine with me. Thank y
On Mon, Dec 15, 2014 at 11:55 AM, Michael Paquier
wrote:
> On Wed, Dec 10, 2014 at 5:15 AM, Tomas Vondra wrote:
>> I agree with moving the patch to the next CF - I'm working on the patch,
>> but I will take a bit more time to submit a new version and I can do
>> that in the next CF.
> OK cool. I
On Sun, Jan 4, 2015 at 10:57 AM, Andres Freund wrote:
> On 2014-12-31 18:35:38 +0530, Amit Kapila wrote:
>> + -j > class="parameter">jobs
>> + --jobs=> class="parameter">njobs
>> +
>> +
>> +Number of concurrent connections to perform the operation.
>> +This o
On Thu, Jan 8, 2015 at 2:28 AM, Marko Tiikkaja wrote:
> Yeah. (The CF entry is also set to Waiting on Author, which seems
> appropriate.)
Seeing nothing happening here for quite some time, marked as returned
with feedback..
--
Michael
--
Sent via pgsql-hackers mailing list (pgsql-hackers@post
On Mon, Dec 22, 2014 at 7:31 PM, Heikki Linnakangas
wrote:
> Here's an updated version, rebased over the pairing heap code that I just
> committed, and fixing those bugs.
So, are we reaching an outcome for the match happening here?
--
Michael
--
Sent via pgsql-hackers mailing list (pgsql-hacke
On Wed, Jan 14, 2015 at 2:11 AM, Heikki Linnakangas wrote:
> On 01/13/2015 12:11 PM, Vladimir Borodin wrote:
>
>>
>> 05 янв. 2015 г., в 18:15, Vladimir Borodin написал(а):
>>
>> Hi all.
>>>
>>> I have a simple script for planned switchover of PostgreSQL (9.3 and
>>> 9.4) master to one of its re
On Wed, Jan 14, 2015 at 8:50 PM, Peter Geoghegan wrote:
> I am mistaken on one detail here - blocks 2 and 9 are actually fully
> identical. I still have no idea why, though.
So, I've looked at it in more detail and it appears that the page of
block 2 split at some point, thereby creating a new pa
On Thu, Jan 15, 2015 at 10:19 AM, Michael Paquier wrote:
> On Thu, Jan 8, 2015 at 2:03 PM, Michael Paquier
> wrote:
> > On Thu, Jan 8, 2015 at 6:31 AM, Alexander Korotkov
> wrote:
> >> On Wed, Jan 7, 2015 at 4:11 PM, Michael Paquier <
> michael.paqu...@gmail.com>
> >>> I am attaching an updated
Hi,
> On Wed, Jan 14, 2015 at 2:11 AM, Heikki Linnakangas > wrote:
>
> > On 01/13/2015 12:11 PM, Vladimir Borodin wrote:
> >
> >>
> >> 05 янв. 2015 г., в 18:15, Vladimir Borodin написал(а):
> >>
> >> Hi all.
> >>>
> >>> I have a simple script for planned switchover of PostgreSQL (9.3 and
> >>>
Hello,
There's a long pending issue with pg_dump and extensions that have table
members with foreign keys. This was previously reported in this thread
http://www.postgresql.org/message-id/ca+tgmoyvzkadmgh_8el7uvm472geru0b4pnnfjqye6ss1k9...@mail.gmail.com
and discuss by Robert. All PostgreSQL users
Hi,
On 2015-01-15 15:05:08 +0900, Kyotaro HORIGUCHI wrote:
> Hello, I'd synced up this at last.
>
> I think I should finilize my commitfest item for this issue, with
> .. "Rejected"?
Fine with me.
> > All the patches in the series up to 0008 hav ecommit messages providing
> > more detail. A sho
On Tue, Jan 13, 2015 at 1:33 AM, Robert Haas wrote:
>
> On Thu, Jan 8, 2015 at 6:52 AM, Amit Kapila
wrote:
> > + seg = dsm_attach(DatumGetInt32(main_arg));
> >
> > Here, I think DatumGetUInt32() needs to be used instead of
> > DatumGetInt32() as the segment handle is uint32.
>
> OK, I'll change t
On 01/15/2015 03:23 AM, Peter Geoghegan wrote:
So now the question is: how did that inconsistency arise? It didn't
necessarily arise at the time of the (presumed) split of block 2 to
create 9. It could be that the opaque area was changed by something
else, some time later. I'll investigate more.
Alexander Korotkov wrote:
> I'm not sure. On the one hand it's unclear why fillfactor should be
> different from 9.4.
> On the other hand it's unclear why it should be different from btree.
> I propose marking this "ready for committer". So, committer can make a final
> decision.
OK let's do so the
Hello all
I see your patch, Tom. It works on my postgres 9.4 (intel x86_64). I write a
letter if I can test it on others platform.
Thank you!
14.01.2015, 21:40, "Tom Lane" :
> Robert Haas writes:
>> On Mon, Jan 12, 2015 at 6:27 AM, Dmitry Voronin
>> wrote:
>>> I am attaching to this lette
Hi all,
We are getting following error message on doing any action on the table
like(Select or open from pgadmin).
Please suggest.
ERROR: missing chunk number 0 for toast value 54787 in pg_toast_2619
** Error **
ERROR: missing chunk number 0 for toast value 54787 in pg_toast_2
On 2015-01-14 19:31:18 -0500, Tom Lane wrote:
> Andres Freund writes:
> > Right now I think a #ifdef/undef S_UNLOCK in the relevant gcc section
> > sufficient and acceptable. It's after all the HPPA section that doesn't
> > really play by the rules.
>
> Works for me.
Pushed something like that.
On 2015-01-14 09:34:23 -0500, Tom Lane wrote:
> Andres Freund writes:
> > On 2015-01-13 22:19:30 -0500, Tom Lane wrote:
> >> A slightly more complicated change could be applied to make sure that
> >> *all* of the CFLAGS forcibly inserted by configure appear before any
> >> externally-sourced CFLAG
I must have missed this, how did you some the hint bit problem with
pg_rewind? Last I understood you ran the risk that the server has unlogged
hint bit updates that you wouldn't know to rewind.
On Thu, Jan 15, 2015 at 7:00 AM, Amit Kapila wrote:
> On Tue, Jan 13, 2015 at 1:33 AM, Robert Haas wrote:
>> On Thu, Jan 8, 2015 at 6:52 AM, Amit Kapila
>> wrote:
>> > + seg = dsm_attach(DatumGetInt32(main_arg));
>> >
>> > Here, I think DatumGetUInt32() needs to be used instead of
>> > DatumGetI
On 2015-01-15 13:21:56 +, Greg Stark wrote:
> I must have missed this, how did you some the hint bit problem with
> pg_rewind? Last I understood you ran the risk that the server has unlogged
> hint bit updates that you wouldn't know to rewind.
wal_log_hints = on
Greetings,
Andres Freund
--
On 01/15/2015 03:21 PM, Greg Stark wrote:
I must have missed this, how did you some the hint bit problem with
pg_rewind? Last I understood you ran the risk that the server has unlogged
hint bit updates that you wouldn't know to rewind.
There's a new GUC in 9.4, wal_log_hints, for that. It has t
On Mon, Jan 12, 2015 at 3:25 AM, Robert Haas wrote:
>
> On Sat, Jan 10, 2015 at 11:14 PM, Amit Kapila
wrote:
> >> I don't think you should be "switching" queues. The tuples should be
> >> sent to the tuple queue, and errors and notices to the error queue.
> > To achieve what you said (The tuples
On 2015-01-15 11:02:43 +0530, Abhijit Menon-Sen wrote:
> At 2015-01-14 11:59:08 +0100, and...@2ndquadrant.com wrote:
> >
> > > + if (ControlFile->state != DB_SHUTDOWNED &&
> > > + ControlFile->state != DB_SHUTDOWNED_IN_RECOVERY)
> > > + perform_fsync(data_directory);
> > > +
> >
>
On Wed, Jan 14, 2015 at 9:42 PM, Alvaro Herrera
wrote:
> Robert Haas wrote:
>> On Tue, Jan 13, 2015 at 10:10 AM, Tom Lane wrote:
>> > However, there is a larger practical problem with this whole concept,
>> > which is that experience should teach us to be very wary of the assumption
>> > that ask
On 2015-01-15 08:40:34 -0500, Robert Haas wrote:
> I do think that "safe" is the wrong suffix. Maybe palloc_soft_fail()
> or palloc_null() or palloc_no_oom() or palloc_unsafe().
palloc_or_null()?
Greetings,
Andres Freund
--
Andres Freund http://www.2ndQuadrant.com/
Postg
On Thu, Jan 15, 2015 at 6:04 AM, Heikki Linnakangas
wrote:
> On 01/15/2015 03:23 AM, Peter Geoghegan wrote:
>>
>> So now the question is: how did that inconsistency arise? It didn't
>> necessarily arise at the time of the (presumed) split of block 2 to
>> create 9. It could be that the opaque area
On Thu, Jan 15, 2015 at 6:52 PM, Robert Haas wrote:
>
> On Thu, Jan 15, 2015 at 7:00 AM, Amit Kapila
wrote:
> > +HandleParallelMessages(void)
> > +{
> > ..
> > ..
> > + for (i = 0; i < pcxt->nworkers; ++i)
> > + {
> > + /*
> > + * Read messages for as long as we have an error queue; if we
> > + *
and...@anarazel.de (Andres Freund) writes:
> On 2015-01-14 19:31:18 -0500, Tom Lane wrote:
>> Andres Freund writes:
>>> Right now I think a #ifdef/undef S_UNLOCK in the relevant gcc section
>>> sufficient and acceptable. It's after all the HPPA section that doesn't
>>> really play by the rules.
>
On Thu, Jan 15, 2015 at 1:04 AM, Noah Misch wrote:
> On Wed, Jan 14, 2015 at 04:48:53PM -0500, Peter Eisentraut wrote:
>> What I'm seeing now is that the unaccent regression tests when run under
>> make check-world abort with
>>
>> FATAL: postmaster became multithreaded during startup
>> HINT: S
Andres Freund writes:
> FWIW, if we moved the
> CFLAGS="$CFLAGS $user_CFLAGS"
> further down, it'd have advantage that compiling with -Werror would be
> more realistic. Right now doing so breaks about half of the feature
> checking configure checks because of warnings. E.g. on my platform it
> fai
On 2015-01-15 09:25:29 -0500, Tom Lane wrote:
> Andres Freund writes:
> > FWIW, if we moved the
> > CFLAGS="$CFLAGS $user_CFLAGS"
> > further down, it'd have advantage that compiling with -Werror would be
> > more realistic. Right now doing so breaks about half of the feature
> > checking configur
On Wed, Jan 14, 2015 at 9:27 PM, Michael Paquier
wrote:
> On Thu, Jan 15, 2015 at 7:13 AM, Robert Haas wrote:
>> Instead of doing this:
>>
>> if (len < sizeof(buf))
>> buf[len] = '\0';
>>
>> ...I would suggest making the size of the buffer one greater than the
>> size of the read(), a
On Thu, Jan 15, 2015 at 8:42 AM, Andres Freund wrote:
> On 2015-01-15 08:40:34 -0500, Robert Haas wrote:
>> I do think that "safe" is the wrong suffix. Maybe palloc_soft_fail()
>> or palloc_null() or palloc_no_oom() or palloc_unsafe().
>
> palloc_or_null()?
That'd work for me, too.
--
Robert H
On Thu, Jan 15, 2015 at 9:09 AM, Amit Kapila wrote:
> On Thu, Jan 15, 2015 at 6:52 PM, Robert Haas wrote:
>> On Thu, Jan 15, 2015 at 7:00 AM, Amit Kapila
>> wrote:
>> > +HandleParallelMessages(void)
>> > +{
>> > ..
>> > ..
>> > + for (i = 0; i < pcxt->nworkers; ++i)
>> > + {
>> > + /*
>> > + * R
I wrote:
> I've launched a run now, expect results from gcc HEAD in an hour and
> a half or so.
... and it's happy. Thanks!
BTW, the reason I went to the trouble of cranking up the buildfarm scripts
on that machine (and it was painful :-() is that I don't believe any other
buildfarm members are
On 2015-01-15 10:57:10 -0500, Tom Lane wrote:
> * I've got gaur configured so it will throw "array subscript of type char"
> complaints whenever somebody forgets to cast a function argument
> to unsigned char.
But, but. That would never happen to anyone (hides).
> While I'll not cry too hard whe
On Thu, Jan 15, 2015 at 2:02 PM, Amit Kapila wrote:
> On Wed, Jan 14, 2015 at 9:01 PM, Sawada Masahiko
> wrote:
>>
>> Hi all,
>>
>> The postgresql.auto.conf is loaded after loading of postgresql.conf
>> whenever configuration file is loaded or reloaded.
>> This means that parameter in postgresql.
Michael Paquier wrote:
> Andres, this patch needs more effort from the author, right? So
> marking it as returned with feedback.
I will give this patch a look in the current commitfest, if you can
please set as 'needs review' instead with me as reviewer, so that I
don't forget, I would appreciate
Robert Haas wrote:
> Hmm, I understood Tom to be opposing the idea of a palloc variant that
> returns NULL on failure, and I understand you to be supporting it.
> But maybe I'm confused.
Your understanding seems correct to me. I was just saying that your
description of Tom's argument to dislike
Etsuro Fujita wrote:
> ***
> *** 817,826 InitPlan(QueryDesc *queryDesc, int eflags)
> --- 818,833
> break;
> case ROW_MARK_COPY:
> /* there's no real table here ... */
> +
Hi,
attached is version 8, fixing remaining issues, adding docs and tests as
requested/agreed.
Marius & Arne
---
Marius Timmer
Zentrum für Informationsverarbeitung
Westfälische Wilhelms-Universität Münster
Einsteinstraße 60
mtimm...@uni-muenster.de
Am 14.01.2015 um 17:42 schrieb Arne Sche
>
>
> From: "Timmer, Marius"
>
> Hi,
>
> attached is version 8, fixing remaining issues, adding docs and tests as
> requested/agreed.
>
>
> Marius & Arne
>
>
This looks good to me. Test coverage seems complete. Doc updates are
included. Output format looks like it should be acceptable to Heik
Andres Freund writes:
> On 2015-01-15 10:57:10 -0500, Tom Lane wrote:
>> While I'll not cry too hard when we decide to break C89 compatibility,
>> I don't want it to happen accidentally; so having a pretty old-school
>> compiler in the farm seems important to me.
> I'd worked on setting up a mode
On 2015-01-15 11:56:24 -0500, Tom Lane wrote:
> Andres Freund writes:
> > On 2015-01-15 10:57:10 -0500, Tom Lane wrote:
> >> While I'll not cry too hard when we decide to break C89 compatibility,
> >> I don't want it to happen accidentally; so having a pretty old-school
> >> compiler in the farm s
On 6. Januar 2015 at 07:20:21, Michael Paquier (michael.paqu...@gmail.com)
wrote:
> On Tue, Jan 6, 2015 at 12:39 AM, Manuel Kniep wrote:
> > Hi,
> >
> > we are running postges 9.3.5 on gentoo linux kernel 3.16.5, compiled with
> > gcc 4.8.3
> > Any ideas ?
>
> > #17 0x0062bb9d in SPI_
"Timmer, Marius" writes:
> attached is version 8, fixing remaining issues, adding docs and tests as
> requested/agreed.
I'll pick this up --- I've been a bit lax about helping with this
commitfest.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hacker
On 01/15/2015 09:28 AM, Michael Paquier wrote:
Marking this patch as returned with feedback because it is waiting for
input from the author for now a couple of weeks. Heikki, the
refactoring patch has some value, are you planning to push it?
I think you're mixing up with the other thread, "btre
Robert Haas writes:
> On Tue, Jan 13, 2015 at 8:16 PM, Tom Lane wrote:
>> Not sure whether to just commit this to HEAD and call it a day, or to
>> risk back-patching.
> I think we need to back-patch something; that's a pretty nasty
> regression, and I have some EDB-internal reports that might be
On Thu, Jan 15, 2015 at 6:02 AM, Merlin Moncure wrote:
> Question: Coming in this morning I did an immediate restart and logged
> into the database and queried pg_class via index. Everything was
> fine, and the leftright verify returns nothing. How did it repair
> itself without a reindex?
May
On Thu, Jan 15, 2015 at 8:02 AM, Merlin Moncure wrote:
> On Thu, Jan 15, 2015 at 6:04 AM, Heikki Linnakangas
> wrote:
>> On 01/15/2015 03:23 AM, Peter Geoghegan wrote:
>>>
>>> So now the question is: how did that inconsistency arise? It didn't
>>> necessarily arise at the time of the (presumed) s
On 01/07/2015 11:53 AM, Petr Jelinek wrote:
On 07/01/15 00:59, Michael Paquier wrote:
On Wed, Jan 7, 2015 at 4:24 AM, Petr Jelinek wrote:
Hi,
when I was fixing how commit_ts handles the XLOG_PARAMETER_CHANGE I noticed
that for wal_log_hints we assign the value in ControFile to current value
i
Hi,
> The plot thickens! I looped the test, still stock 9.4 as of this time
> and went to lunch. When I came back, the database was in recovery
> mode. Here is the rough sequence of events.
>
Whoa. That looks scary. Did you see (some of) those errors before? Most
of them should have been emitte
On 2015-01-15 20:15:42 +0100, Andres Freund wrote:
> > WARNING: did not find subXID 14955 in MyProc
> > CONTEXT: PL/pgSQL function cdsreconcileruntable(bigint) line 35
> > during exception cleanup
> > WARNING: you don't own a lock of type RowExclusiveLock
> > CONTEXT: PL/pgSQL function cdsrecon
On Tue, Jan 13, 2015 at 10:56:48AM -0500, Peter Eisentraut wrote:
> On 11/30/14 11:45 AM, Tom Lane wrote:
> > The "API break" isn't a big issue imo. The net effect would be that eg
> > hstore 9.3.6 wouldn't work against a 9.3.5 server. We do that sort of
> > thing *all the time* --- at least twic
On Thu, Jan 15, 2015 at 1:15 PM, Andres Freund wrote:
> Hi,
>
>> The plot thickens! I looped the test, still stock 9.4 as of this time
>> and went to lunch. When I came back, the database was in recovery
>> mode. Here is the rough sequence of events.
>>
>
> Whoa. That looks scary. Did you see (s
On Thu, Jan 15, 2015 at 3:08 AM, Michael Paquier
wrote:
> On Mon, Dec 22, 2014 at 7:31 PM, Heikki Linnakangas
> wrote:
>> Here's an updated version, rebased over the pairing heap code that I just
>> committed, and fixing those bugs.
> So, are we reaching an outcome for the match happening here?
On Wed, Jan 14, 2015 at 5:54 PM, Andres Freund wrote:
> I think I'd for now simply not define pg_attribute_aligned() on
> platforms where it's not supported, instead of defining it empty. If we
> need a softer variant we can name it pg_attribute_aligned_if_possible or
> something.
>
> Sounds sane?
On 1/15/15 2:29 PM, Bruce Momjian wrote:
> On Tue, Jan 13, 2015 at 10:56:48AM -0500, Peter Eisentraut wrote:
>> On 11/30/14 11:45 AM, Tom Lane wrote:
>>> The "API break" isn't a big issue imo. The net effect would be that eg
>>> hstore 9.3.6 wouldn't work against a 9.3.5 server. We do that sort o
Manuel Kniep writes:
> ok after lotâs of testing I could create a test caseÂ
> which can be found here https://gist.github.com/rapimo/3c8c1b35270e5854c524Â
> itâs written in ruby an depends on the gem activerecord pg and parallelÂ
Hm. I don't see a segfault from this. I do see the CREATE
On Thu, Jan 15, 2015 at 1:32 PM, Merlin Moncure wrote:
> Since it's possible the database is a loss, do you see any value in
> bootstrappinng it again with checksums turned on? One point of note
> is that this is a brand spanking new SSD, maybe we nee to rule out
> hardware based corruption?
hm!
On Thu, Oct 30, 2014 at 10:46 AM, Robert Haas wrote:
> (9.3.5 problem report)
I think I saw a similar issue, by a 9.3.5 instance that was affected
by the "in pg_upgrade, remove pg_multixact files left behind by
initdb" issue (I ran the remediation recommended in the 9.3.5 release
notes). Multiple
On Thu, Jan 15, 2015 at 4:03 PM, Merlin Moncure wrote:
> On Thu, Jan 15, 2015 at 1:32 PM, Merlin Moncure wrote:
>> Since it's possible the database is a loss, do you see any value in
>> bootstrappinng it again with checksums turned on? One point of note
>> is that this is a brand spanking new SS
All,
Attached is a patch that proposes the following additional role attributes
for review:
* ONLINE_BACKUP - allows role to perform backup operations
- originally proposed as BACKUP - due to concern for the use of that term
in relation to other potential backup related permissions this form is
On Thu, Jan 15, 2015 at 3:00 PM, Merlin Moncure wrote:
> Running this test on another set of hardware to verify -- if this
> turns out to be a false alarm which it may very well be, I can only
> offer my apologies! I've never had a new drive fail like that, in
> that manner. I'll burn the other
On 01/14/2015 08:48 AM, Michael Paquier wrote:
All those things gathered give the patch attached. Andreas, if you are
fine with it I think that we could pass it to a committer.
Excellent changes. Thanks for the patch and the reviews.
--
Andreas Karlsson
--
Sent via pgsql-hackers mailing list
On Fri, Jan 16, 2015 at 12:57 AM, Alvaro Herrera
wrote:
>> I do think that "safe" is the wrong suffix. Maybe palloc_soft_fail()
>> or palloc_null() or palloc_no_oom() or palloc_unsafe().
>
> I liked palloc_noerror() better myself FWIW.
Voting for palloc_noerror() as well.
--
Michael
--
Sent v
I wrote:
> Manuel Kniep writes:
>> ok after lotâs of testing I could create a test caseÂ
>> which can be found here https://gist.github.com/rapimo/3c8c1b35270e5854c524Â
>> itâs written in ruby an depends on the gem activerecord pg and parallelÂ
> Hm. I don't see a segfault from this. I d
On 1/15/15 5:26 AM, Gilles Darold wrote:
Hello,
There's a long pending issue with pg_dump and extensions that have table
members with foreign keys. This was previously reported in this thread
http://www.postgresql.org/message-id/ca+tgmoyvzkadmgh_8el7uvm472geru0b4pnnfjqye6ss1k9...@mail.gmail.co
On 1/15/15 6:22 AM, M Tarkeshwar Rao wrote:
We are getting following error message on doing any action on the table
like(Select or open from pgadmin).
Error reports should go to pgsql-general. I'm moving the discussion there (and
BCC'ing -hackers).
Please suggest.
ERROR: missing chunk num
On Fri, Jan 16, 2015 at 12:53 AM, Alvaro Herrera
wrote:
> Michael Paquier wrote:
>
>> Andres, this patch needs more effort from the author, right? So
>> marking it as returned with feedback.
>
> I will give this patch a look in the current commitfest, if you can
> please set as 'needs review' inst
Here is a random bag of comments for the v5 patch:
pg_xlogdump fails to build:
CC xlogreader.o
CC rmgrdesc.o
../../src/include/access/rmgrlist.h:32:46: error: 'dbase_desc' undeclared here
(not in a function)
PG_RMGR(RM_DBASE_ID, "Database", dbase_redo, dbase_desc, dbase_identify, NULL,
Hi,
Here's a patch that does:
* For each new index tuple inserted, *numSummarized (if not NULL) is
- * incremented; for each existing tuple, numExisting (if not NULL) is
+ * incremented; for each existing tuple, *numExisting (if not NULL) is
* incremented.
*/
Thanks,
Amit
diff --git a/src/
Hello,
> > I think I should finilize my commitfest item for this issue, with
> > .. "Rejected"?
>
> Fine with me.
done.
> > > 0001: Replace walsender's latch with the general shared latch.
> > >
> > > New patch that removes ImmediateInteruptOK behaviour from
> > > walsender. I
> > >
On 04 January 2015 07:27, Andres Freund Wrote,
> On 2014-12-31 18:35:38 +0530, Amit Kapila wrote:
> > + -j class="parameter">jobs
> > + --jobs= class="parameter">njobs
> > +
> > +
> > +Number of concurrent connections to perform the operation.
> > +This optio
On Thu, Jan 15, 2015 at 9:48 PM, Sawada Masahiko
wrote:
> On Thu, Jan 15, 2015 at 2:02 PM, Amit Kapila
wrote:
> >
> > One thought I have in this line is that currently there doesn't seem to
be
> > a way to know if the setting has an entry both in postgresql.conf and
> > postgresql.auto.conf, if w
On Thu, Jan 15, 2015 at 6:19 PM, Kyotaro HORIGUCHI <
horiguchi.kyot...@lab.ntt.co.jp> wrote:
> > On Wed, Jan 14, 2015 at 2:11 AM, Heikki Linnakangas <
> hlinnakan...@vmware.com
> > > wrote:
> >
> > > On 01/13/2015 12:11 PM, Vladimir Borodin wrote:
> > >
> > >>
> > >> 05 янв. 2015 г., в 18:15, Vlad
On Thu, Jan 15, 2015 at 09:24:01AM -0500, Robert Haas wrote:
> On Thu, Jan 15, 2015 at 1:04 AM, Noah Misch wrote:
> > On Wed, Jan 14, 2015 at 04:48:53PM -0500, Peter Eisentraut wrote:
> >> What I'm seeing now is that the unaccent regression tests when run under
> >> make check-world abort with
> >
On Thu, Jan 08, 2015 at 04:37:37PM +0200, Heikki Linnakangas wrote:
> setlocale(LC_COLLATE, NULL) -> "Norwegian (Bokmål)_Norway"
>
> but:
>
> setlocale(LC_COLLATE, "norwegian-bokmal_Norway") -> "Norwegian_Norway")
> Apparently the behavior changed when I upgraded the toolchain. IIRC, I used
> to
79 matches
Mail list logo
