On Tue, Dec 27, 2011 at 1:39 PM, Jeff Davis wrote:
> On Mon, 2011-12-19 at 07:50 -0500, Robert Haas wrote:
>> I
>> think it would be regrettable if everyone had to give up 4 bytes per
>> page because some people want checksums.
>
> I can understand that some people might not want the CPU expense o
On Wed, Dec 28, 2011 at 7:42 AM, Heikki Linnakangas
wrote:
>> How would you know when to look in the double write buffer?
>
>
> You scan the double-write buffer, and every page in the double write buffer
> that has a valid checksum, you copy to the main storage. There's no need to
> check validit
On Wed, Dec 28, 2011 at 9:00 AM, Robert Haas wrote:
> What I'm not too clear
> about is whether a 16-bit checksum meets the needs of people who want
> checksums.
We need this now, hence the gymnastics to get it into this release.
16-bits of checksum is way better than zero bits of checksum, pro
On Thu, Dec 22, 2011 at 6:16 AM, Simon Riggs wrote:
> I can see a reason to do this now. I've written patch and will commit
> on Friday. Nudge me if I don't.
It's hard to write this so it works in all cases and doesn't work in
the right cases also.
Basically, we can't get in the way of crash re
HEL6.1 kernel 2.6.32-131.0.15.el6.ppc64
gcc version 4.4.5 20110214 (Red Hat 4.4.5-6)
PostgreSQL Git head (0510b62d91151b9d8c1fe1aa15c9cf3ffe9bf25b)
--
Tatsuo Ishii
SRA OSS, Inc. Japan
English: http://www.sraoss.co.jp/index_en.php
Japanese: http://www.sraoss.co.jp
<>
ppc-TAS_SPIN-2011122
Excerpts from Steve Crawford's message of mar dic 27 22:51:06 -0300 2011:
> I have a system (9.0.4 on Ubuntu Server 10.04 LTS x86_64) that is
> currently in test/dev mode. I'm currently seeing the following messages
> occurring every few seconds:
>
> ...
> Dec 27 17:43:22 foo postgres[23693]: [
hi,
does it make sense to teach the planner (and the executor?) use an ordering op
to optimize queries like the following?
select * from t where a <-> 1000 < 10
YAMAMOTO Takashi
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
On 12/27/2011 11:09 PM, Brar Piening wrote:
Brar Piening wrote:
I have to admit that it's currently broken (it builds but fails
during regression tests becuse it can't connect) when building with
Visual Studio 2010 or Windows SDK 7.1 because of commit
1a0c76c32fe470142d3663dd84ac960d75a4e8db
On Wed, Dec 28, 2011 at 14:38, Andrew Dunstan wrote:
>
>
> On 12/27/2011 11:09 PM, Brar Piening wrote:
>>
>> Brar Piening wrote:
>>>
>>> I have to admit that it's currently broken (it builds but fails during
>>> regression tests becuse it can't connect) when building with Visual Studio
>>> 2010 or
On 12/28/2011 08:43 AM, Magnus Hagander wrote:
On Wed, Dec 28, 2011 at 14:38, Andrew Dunstan wrote:
On 12/27/2011 11:09 PM, Brar Piening wrote:
Brar Piening wrote:
I have to admit that it's currently broken (it builds but fails during
regression tests becuse it can't connect) when building
On Wed, Dec 28, 2011 at 15:08, Andrew Dunstan wrote:
>
>
> On 12/28/2011 08:43 AM, Magnus Hagander wrote:
>>
>> On Wed, Dec 28, 2011 at 14:38, Andrew Dunstan wrote:
>>>
>>>
>>> On 12/27/2011 11:09 PM, Brar Piening wrote:
Brar Piening wrote:
>
> I have to admit that it's currentl
On Tue, Dec 27, 2011 at 10:43 PM, Merlin Moncure wrote:
> I bet if you kept a judicious number of
> clog pages in each local process with some smart invalidation you
> could cover enough cases that scribbling the bits down would become
> unnecessary.
I don't understand how any cache can complete
On Wed, Dec 28, 2011 at 8:45 AM, Greg Stark wrote:
> On Tue, Dec 27, 2011 at 10:43 PM, Merlin Moncure wrote:
>> I bet if you kept a judicious number of
>> clog pages in each local process with some smart invalidation you
>> could cover enough cases that scribbling the bits down would become
>> u
On 12/28/2011 05:05 AM, Alvaro Herrera wrote:
Excerpts from Steve Crawford's message of mar dic 27 22:51:06 -0300 2011:
I have a system (9.0.4 on Ubuntu Server 10.04 LTS x86_64) that is
currently in test/dev mode. I'm currently seeing the following messages
occurring every few seconds:
...
Dec
On 28.12.2011 11:00, Robert Haas wrote:
Admittedly, most of the fat is probably in the tuple header rather
than the page header, but at any rate I don't consider burning up 1%
of our available storage space to be a negligible overhead.
8 / 8192 = 0.1%.
--
Heikki Linnakangas
EnterpriseDB
Excerpts from Steve Crawford's message of mié dic 28 13:24:37 -0300 2011:
> On 12/28/2011 05:05 AM, Alvaro Herrera wrote:
> > Excerpts from Steve Crawford's message of mar dic 27 22:51:06 -0300 2011:
> >> I have a system (9.0.4 on Ubuntu Server 10.04 LTS x86_64) that is
> >> currently in test/dev
On 28.12.2011 11:22, Simon Riggs wrote:
On Wed, Dec 28, 2011 at 7:42 AM, Heikki Linnakangas
wrote:
How would you know when to look in the double write buffer?
You scan the double-write buffer, and every page in the double write buffer
that has a valid checksum, you copy to the main storage
The check_postgres txn_wraparound action[0] runs this query:
SELECT datname, age(datfrozenxid) AS age FROM pg_database WHERE datallowconn
ORDER BY 1, 2
On a hot standby, this fails with:
ERROR: cannot assign TransactionIds during recovery
So, a couple of things to wonder about:
Is it u
On 12/28/2011 09:34 AM, Alvaro Herrera wrote:
Excerpts from Steve Crawford's message of mié dic 28 13:24:37 -0300 2011:
On 12/28/2011 05:05 AM, Alvaro Herrera wrote:
Excerpts from Steve Crawford's message of mar dic 27 22:51:06 -0300 2011:
I have a system (9.0.4 on Ubuntu Server 10.04 LTS x86_
Tom Lane writes:
> I wonder whether it's time to drop that file altogether ... it served a
> purpose back before we integrated contrib into the SGML docs, but now
> I'm not quite sure why we should bother with it.
I wonder if we shouldn't keep the file and have it just point to the
relevant docum
Excerpts from Peter Eisentraut's message of mié dic 28 15:04:09 -0300 2011:
> The check_postgres txn_wraparound action[0] runs this query:
>
>SELECT datname, age(datfrozenxid) AS age FROM pg_database WHERE
> datallowconn ORDER BY 1, 2
>
> On a hot standby, this fails with:
>
>ERROR: c
Alvaro Herrera writes:
> Excerpts from Peter Eisentraut's message of mié dic 28 15:04:09 -0300 2011:
>> On a hot standby, this fails with:
>> ERROR: cannot assign TransactionIds during recovery
> I think we could just have the xid_age call
> GetCurrentTransactionIdIfAny, and if that returns Inv
On 28.12.2011 14:03, Tatsuo Ishii wrote:
With help from IBM Japan Ltd. we did some tests on a larger IBM
machine than Tom Lane has used for his
test(http://archives.postgresql.org/message-id/8292.1314641...@sss.pgh.pa.us).
In his case it was IBM 8406-71Y, which has 8 physical cores and
4SMT(32 th
> On 28.12.2011 14:03, Tatsuo Ishii wrote:
With help from IBM Japan Ltd. we did some tests on a larger IBM
machine than Tom Lane has used for his
test(http://archives.postgresql.org/message-id/8292.1314641...@sss.pgh.pa.us).
In his case it was IBM 8406-71Y, which has 8 physical
Andrew Dunstan wrote:
Can you narrow down exactly what in that commit broke VS 2010? Are
there any compiler warnings?
I was able to nail down the problem.
Running the regression tests (vcregress check) gives the following messages:
== creating temporary installation===
Heikki Linnakangas writes:
> config/c-compiler.m4 doesn't seem like the right place for the configure
> test. Would there be any harm in setting the lwarx hint always; what
> would happen on older ppc processors that don't support it?
More to the point, a configure test only proves whether the
Tom Lane wrote:
> a configure test only proves whether the build machine can deal
> with the flag, not whether the machine the executables will
> ultimately run on knows what the flag means. We cannot assume that
> the build and execution boxes are the same. (In general,
> AC_TRY_RUN tests are
OT:
Please use mail address "manabu@gmail.com", not
"manabu@gmailc.com" when following this thread. I accidently made
a mistake when I posted the first mail in this thread.
--
Tatsuo Ishii
SRA OSS, Inc. Japan
English: http://www.sraoss.co.jp/index_en.php
Japanese: http://www.sraoss.co.jp
2011/12/29 Tatsuo Ishii
> > Impressive results.
> >
> > config/c-compiler.m4 doesn't seem like the right place for the
> > configure test. Would there be any harm in setting the lwarx hint
> > always; what would happen on older ppc processors that don't support
> > it?
>
> I think the load module
> > a configure test only proves whether the build machine can deal
> > with the flag, not whether the machine the executables will
> > ultimately run on knows what the flag means. We cannot assume that
> > the build and execution boxes are the same. (In general,
> > AC_TRY_RUN tests are best avo
30 matches
Mail list logo
