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
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 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 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 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
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
> > >
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/
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,
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
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 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
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 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
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 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
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 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
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 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!
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 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
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 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 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 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 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
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 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
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 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
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 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
"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 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_
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
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
>
>
> 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
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
Etsuro Fujita wrote:
> ***
> *** 817,826 InitPlan(QueryDesc *queryDesc, int eflags)
> --- 818,833
> break;
> case ROW_MARK_COPY:
> /* there's no real table here ... */
> +
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
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
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.
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
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 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
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 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 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
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 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
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 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
> > + *
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 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 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 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 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 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 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
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 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
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.
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
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
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
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.
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
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
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 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
> >>>
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
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 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 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 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 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 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
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
79 matches
Mail list logo
