On Sat, Aug 2, 2014 at 1:47 AM, Fujii Masao wrote:
> On Fri, Aug 1, 2014 at 8:35 PM, Fujii Masao wrote:
>> Hi,
>>
>> In 9.2, pg_receivexlog -v has emitted the messages as follows at the
>> end of each WAL file.
>>
>> pg_receivexlog: finished segment at 0/200 (timeline 1)
>> pg_receivexlog: fi
On Fri, Aug 1, 2014 at 8:35 PM, Fujii Masao wrote:
> Hi,
>
> In 9.2, pg_receivexlog -v has emitted the messages as follows at the
> end of each WAL file.
>
> pg_receivexlog: finished segment at 0/200 (timeline 1)
> pg_receivexlog: finished segment at 0/300 (timeline 1)
> pg_receivexlog: fi
On Sat, 2014-08-02 at 15:15 +1200, Gavin Flower wrote:
> Since there was no year zero: then it follows that the first decade
> comprises years 1 to 10, and the current Millennium started in 2001 - or
> am I being too logical??? :-)
This is pretty much the reason I'm sending this patch, because
On Fri, Aug 1, 2014 at 8:57 PM, Noah Misch wrote:
> Robert, Heikki and maybe Alvaro requested and/or explained this split back in
> April. The fact that the would-be first patch was discussed and rejected in
> the past does not counter that request. (I voted against Robert's 2012 patch.
> My opp
On Fri, Aug 01, 2014 at 04:00:11PM -0700, Peter Geoghegan wrote:
> Since Robert did not give a
> reason for discussing the basic fmgr-elision patch despite having
> already discussed it a couple of years ago, I have not split the patch
> into two (if I did, the first patch would be virtually identi
On Fri, Aug 1, 2014 at 8:15 PM, Gavin Flower
wrote:
> On 02/08/14 12:32, David G Johnston wrote:
>
>>
>> Any supporting arguments for 1-10 = 1st decade other than technical
>> perfection? I guess if you use data around and before 1AD you care about
>> this more, and rightly so, but given sound a
On 02/08/14 12:32, David G Johnston wrote:
Mike Swanson wrote
For a long time (since version 8.0), PostgreSQL has adopted the logical
barriers for centuries and millenniums in these functions. The calendar
starts millennium and century 1 on year 1, directly after 1 BC.
Unfortunately decades are
On 08/01/2014 05:32 PM, David G Johnston wrote:
> Any supporting arguments for 1-10 = 1st decade other than technical
> perfection? I guess if you use data around and before 1AD you care about
> this more, and rightly so, but given sound arguments for both methods the
> one more useful to more use
On Sat, Aug 2, 2014 at 3:55 AM, Thomas Munro wrote:
> On 1 August 2014 10:37, David Rowley wrote:
> > Apart from this I can't see any other problems with the patch and I'd be
> > very inclined, once the above are fixed up to mark the patch ready for
> > commiter.
> >
> > Good work
>
> Thanks for
Mike Swanson wrote
> For a long time (since version 8.0), PostgreSQL has adopted the logical
> barriers for centuries and millenniums in these functions. The calendar
> starts millennium and century 1 on year 1, directly after 1 BC.
> Unfortunately decades are still reported rather simplistically
ed802e7 seems to have broken the windows builds.
.\contrib\pgbench\pgbench.c(530): error C2065: 'M_PI' : undeclared
identifier
The attached fixes the problem. It seems all other uses of M_PI have
added the same code to the .c file rather than any header file,
perhaps a better patch would fix up a
For a long time (since version 8.0), PostgreSQL has adopted the logical
barriers for centuries and millenniums in these functions. The calendar
starts millennium and century 1 on year 1, directly after 1 BC.
Unfortunately decades are still reported rather simplistically by
dividing the year by 10.
On Thu, Jul 31, 2014 at 1:12 PM, Peter Geoghegan wrote:
> Abbreviated it is.
Attached revision uses new terminology. I have abandoned configure
tests entirely, preferring to explicitly discriminate against Mac OS X
(Darwin) as a platform with a known odd locale implementation, just
like pg_get_en
Hackers,
Since Gabrielle has improved archiving with pg_stat_archiver in 9.4, I'd
like to go further and improve the usability of pg_stop_backup().
However, based on my IRC discussion with Vik, there might not be
consensus on what the right behavior *should* be. This is for 9.5, of
course.
Curre
Tom Lane wrote:
> Kevin Grittner writes:
>> It would be more consistent, ISTM, to cast
>> float8 to float4 when those are compared, and to cast numeric to
>> whichever type is on the other side of the comparison operator.
>
> I would vote against that on the grounds of greatly increased risk
> of
Kevin Grittner writes:
> It would be more consistent, ISTM, to cast
> float8 to float4 when those are compared, and to cast numeric to
> whichever type is on the other side of the comparison operator.
I would vote against that on the grounds of greatly increased risk
of overflow failure. Admit
Tom Lane wrote:
> Kevin Grittner writes:
>> Jeff Davis wrote:
>>> I saw some strange results:
>
>> The part I find strange is that the first one evaluates to true,
>> since numeric can exactly represent 1.1 and float8 cannot.
>
> The reason is that the numeric input is converted to float8 for
>
This patch is pretty trivial.
Add modulo operator to pgbench.
This is useful to compute a permutation for tests with non uniform
accesses (exponential or gaussian), so as to avoid trivial correlations
between neighbour keys.
--
Fabien.diff --git a/contrib/pgbench/pgbench.c b/contrib/pgbench
On 07/08/2014 08:11 PM, Jeff Janes wrote:
Is there some recipe for testing the 0002 patch? Can it be tested on an
MinGW environment, or does it need to use the MicroSoft supplied compilers?
I used MSVC. It ought to work with MinGW, I think, although you might
need to tweak the Makefiles to ma
On 07/11/2014 08:39 PM, Alvaro Herrera wrote:
Heikki Linnakangas wrote:
I did again the refactoring you did back in 2006, patch attached.
One thing I did differently: I moved the raw, non-encrypted,
read/write functions to separate functions: pqsecure_raw_read and
pqsecure_raw_write. Those func
On Fri, Aug 1, 2014 at 1:43 PM, desmodemone wrote:
>
>
>
> 2014-08-01 18:20 GMT+02:00 Claudio Freire :
>
>> On Fri, Aug 1, 2014 at 12:35 AM, Amit Kapila
>> wrote:
>> >> c) the map is not crash safe by design, because it needs only for
>> >> incremental backup to track what blocks needs to be back
On Fri, Aug 1, 2014 at 8:35 PM, Fujii Masao wrote:
> Hi,
>
> In 9.2, pg_receivexlog -v has emitted the messages as follows at the
> end of each WAL file.
>
> pg_receivexlog: finished segment at 0/200 (timeline 1)
> pg_receivexlog: finished segment at 0/300 (timeline 1)
> pg_receivexlog: fi
Thank you for comment
Patch is already added in Performance topic.
2014-08-01 20:25 GMT+04:00 FabrÃzio de Royes Mello
:
>
> On Fri, Aug 1, 2014 at 4:58 AM, Anastasia Lubennikova <
> lubennikov...@gmail.com> wrote:
> >
> > Hi, hackers!
> > I work on a GSoC project "Index-only scans for GIST"
> >
2014-08-01 18:20 GMT+02:00 Claudio Freire :
> On Fri, Aug 1, 2014 at 12:35 AM, Amit Kapila
> wrote:
> >> c) the map is not crash safe by design, because it needs only for
> >> incremental backup to track what blocks needs to be backuped, not for
> >> consistency or recovery of the whole cluster,
Here's a new version of this patch, please review.
I've cleaned up a lot of stuff, fixed all the bugs reported so far, and
a bunch of others I found myself while testing.
I'm not going to explain again what the patch does; the README and
comments should now be complete enough to explain how i
On Fri, Aug 1, 2014 at 4:58 AM, Anastasia Lubennikova <
lubennikov...@gmail.com> wrote:
>
> Hi, hackers!
> I work on a GSoC project "Index-only scans for GIST"
>
https://wiki.postgresql.org/wiki/Support_for_Index-only_scans_for_GIST_GSoC_2014
>
> Repository is
> https://github.com/lubennikovaav/pos
On Fri, Aug 1, 2014 at 12:35 AM, Amit Kapila wrote:
>> c) the map is not crash safe by design, because it needs only for
>> incremental backup to track what blocks needs to be backuped, not for
>> consistency or recovery of the whole cluster, so it's not an heavy cost for
>> the whole cluster to m
On 1 August 2014 10:37, David Rowley wrote:
> * skip-locked-2.spec
>
> # s2 againt skips because it can't acquired a multi-xact lock
>
> "againt" should be "again"
Fixed.
> also mixed use of multixact and multi-xact, probably would be better to
> stick to just 1.
Changed to multixact as seen in
Kevin Grittner writes:
> Jeff Davis wrote:
>> I saw some strange results:
> The part I find strange is that the first one evaluates to true,
> since numeric can exactly represent 1.1 and float8 cannot.
The reason is that the numeric input is converted to float8 for
comparison:
regression=# cre
Jeff Davis wrote:
> I saw some strange results:
>
> postgres=# select '1.1'::numeric = '1.1'::float8;
> ?column?
> --
> t
> (1 row)
>
> postgres=# select '1.1'::numeric = '1.1'::float4;
> ?column?
> --
> f
> (1 row)
The part I find strange is that the first one evaluates to true,
Hi,
In 9.2, pg_receivexlog -v has emitted the messages as follows at the
end of each WAL file.
pg_receivexlog: finished segment at 0/200 (timeline 1)
pg_receivexlog: finished segment at 0/300 (timeline 1)
pg_receivexlog: finished segment at 0/400 (timeline 1)
But, while reviewing the
On 07/30/2014 07:46 PM, Tom Lane wrote:
> Bruce Momjian writes:
>> On Wed, Jul 30, 2014 at 01:29:31PM -0400, Tom Lane wrote:
>>> I don't find it all that odd. We should not be encouraging routine
>>> database-wide reindexes.
>
>> Uh, do we encourage database-wide VACUUM FULL or CLUSTER, as we us
On Tue, Jul 29, 2014 at 9:48 AM, Thomas Munro wrote:
> On 27 July 2014 23:19, Thomas Munro wrote:
> > On the subject of isolation tests, I think skip-locked.spec is only
> > producing schedules that reach third of the three 'return
> > HeapTupleWouldBlock' statements in heap_lock_tuple. I will
On Tue, Jul 29, 2014 at 1:35 PM, Alvaro Herrera
wrote:
> David Rowley wrote:
>
> > I've also been looking at the isolation tests and I see that you've
> added a
> > series of tests for NOWAIT. I was wondering why you did that as that's
> > really existing code, probably if you thought the tests w
Hello,
> Hello, this is the new version which is complete to some extent
> of parallelism based on postgres_fdw.
>
> This compares the costs for parallel and non-parallel execution
> and choose parallel one if it is faster by some extent specified
> by GUCs. The attached files are,
>
> 0001_par
Hello, this is the new version which is complete to some extent
of parallelism based on postgres_fdw.
This compares the costs for parallel and non-parallel execution
and choose parallel one if it is faster by some extent specified
by GUCs. The attached files are,
0001_parallel_exec_planning_v0.p
Hi, hackers!
I work on a GSoC project "Index-only scans for GIST"
https://wiki.postgresql.org/wiki/Support_for_Index-only_scans_for_GIST_GSoC_2014
Repository is
https://github.com/lubennikovaav/postgres/tree/indexonlygist2
Patch is in attachments.
It includes index-only scans for multicolumn GIST
Hi,
2014-08-01 16:26 GMT+09:00 Fabien COELHO
>
> Maybe somebody who knows more math than I do (like you, probably!) can
>> come up with something more clever.
>>
>
> I can certainly suggest other formula, but that does not mean beautiful
> code, thus would probably be rejected. I'll see.
>
> An
Hello,
Version one is "k' = 1 + (a * k + b) modulo n" with "a" prime with
respect to "n", "n" being the number of keys. This is nearly possible,
but for the modulo operator which is currently missing, and that I'm
planning to submit for this very reason, but probably another time.
That's pr
39 matches
Mail list logo
