Hello
With this patch it works perfect
Thank you
Regards
Pavel
2014-05-13 21:33 GMT+02:00 Sergey Muraviov :
> Please check this patch.
>
>
> 2014-05-12 22:56 GMT+04:00 Sergey Muraviov :
>
> Hi.
>>
>> I'll try to fix it tomorrow.
>>
>>
>> 2014-05-12 18:42 GMT+04:00 Tom Lane :
>>
>> Greg Stark
Jeff Davis writes:
> In master, 4 tests fail due to plan changes with blocksize 32K. The
> failures started creeping in around 9.0.
AFAIR, that's been true since the dark ages, not since 9.0.
> I don't see a clean way to make the plans consistent with 8K and 32K
> pages, so I was about to write
In master, 4 tests fail due to plan changes with blocksize 32K. The
failures started creeping in around 9.0.
I don't see a clean way to make the plans consistent with 8K and 32K
pages, so I was about to write this off as "we don't care much".
Then I ran with block size 1KB, and I got what appears
On Tuesday, May 13, 2014, Tom Lane wrote:
> A recent question from Tim Kane prompted me to measure the overhead
> costs of EXPLAIN ANALYZE, which I'd not checked in awhile. Things
> are far worse than I thought. On my current server (by no means
> lavish hardware: Xeon E5-2609 @2.40GHz) a simpl
On Tue, May 13, 2014 at 8:04 PM, Tom Lane wrote:
> Amit Kapila writes:
>> How about sorting step, are you thinking to have MergeAppend
>> node for it beneath ModifyTable?
>
> Well yeah, that's pretty much the point.
IIUC, the way new design will work is that for new tuple we will now
get tableoi
Hi.
Some regression tests for sepgsql still not work on Fedora 20:
== running regression test queries==
test label... FAILED
test dml ... ok
test ddl ... FAILED
test alter... FAILED
t
On 13 May 2014 14:06, Heikki Linnakangas
> >> >The core of the design is to store the LSN of the commit record in
> >> >pg_clog. Currently, we only store 2 bits per transaction there,
> >> >indicating if the transaction committed or not, but the patch will
> >> >expand it to 64 bits, to store the
Greg Stark writes:
> I actually think it would be more interesting if we could measure the
> overhead and adjust for it.
Actually, that's quite a good thought. The overhead should be a pretty
stable number on any given machine, so in theory we could do this to
high precision. And the numbers I
On Tue, May 13, 2014 at 1:59 PM, Heikki Linnakangas
wrote:
> On 05/13/2014 09:44 AM, Amit Kapila wrote:
>>
>> To accomplish this won't XID-CSN map table be required and how will
>> it be maintained (means when to clear and add a entry to that map table)?
>
>
> Not sure I understand. The clog is a
Hi.
Here's a patch that fixes it.
--
Best regards,
Sergey Muraviov
diff --git a/doc/src/sgml/release-9.4.sgml b/doc/src/sgml/release-9.4.sgml
index cabfbdd..0b6f383 100644
--- a/doc/src/sgml/release-9.4.sgml
+++ b/doc/src/sgml/release-9.4.sgml
@@ -1587,7 +1587,7 @@
Add variable
On Tue, May 13, 2014 at 11:58 PM, Tom Lane wrote:
> I also tried a loop around a bare "rdtsc" assembly instruction, finding
> that that instruction takes about 10nsec. That would be a nice
> improvement over gettimeofday, except that using that directly would
> involve dealing with cross-CPU skew
Christoph Berg writes:
> Building 9.4 beta1 on Debian sid/i386 fails during the regression
> tests. amd64 works fine, as does i386 on the released distributions.
It would appear that something is wrong with check_stack_depth(),
and/or getrlimit(RLIMIT_STACK) is lying to us about the available sta
Peter Geoghegan writes:
> On Tue, May 13, 2014 at 3:58 PM, Tom Lane wrote:
>> There's also a CLOCK_REALTIME_COARSE selector, which is noticeably faster
>> --- about 10nsec for me --- but the output appears to only advance once
>> every millisecond, so it's probably useless for our purposes. The
On Tue, May 13, 2014 at 3:58 PM, Tom Lane wrote:
> There's also a CLOCK_REALTIME_COARSE selector, which is noticeably faster
> --- about 10nsec for me --- but the output appears to only advance once
> every millisecond, so it's probably useless for our purposes. The other
> selectors mentioned in
On 05/14/2014 07:06 AM, Thomas Munro wrote:
> Hi
>
> A couple of years ago I posted an outline of a plan [1] and an
> initial patch [2] for implementing SKIP LOCKED DATA. I have
> recently come back to this idea, rebased the patch and added a
> simple isolation test -- please see attached.
Simon
A recent question from Tim Kane prompted me to measure the overhead
costs of EXPLAIN ANALYZE, which I'd not checked in awhile. Things
are far worse than I thought. On my current server (by no means
lavish hardware: Xeon E5-2609 @2.40GHz) a simple seqscan can run
at something like 110 nsec per row
On Tue, May 13, 2014 at 2:51 PM, David G Johnston
wrote:
> The error is more typical of someone creating a database with UTF-8 encoding
> but then tries storing Latin-1 (or some other) encoded data.
I didn't say that it was the only problem. Just that I had noticed
that other people were using st
Rohit Goyal wrote
> Hi Peter,
>
> On Tue, May 13, 2014 at 9:44 PM, Peter Geoghegan <
> pg@
> > wrote:
>
>>
>> On Tue, May 13, 2014 at 12:36 PM, Rohit Goyal <
> rhtgyl.87@
> > wrote:
>>
>>> This pattern the above found many times. Please guide me through!!!
>>>
>>
>> IIRC, people have been wor
Andrew Dunstan writes:
> On 05/13/2014 04:14 PM, Tom Lane wrote:
>> But independently of whether it's a fatal error or not: when there's
>> no relevant command-line argument then we print the
>>
>> invalid locale name ""
>>
>> message which is surely pretty unhelpful. It'd be better if we could
Building 9.4 beta1 on Debian sid/i386 fails during the regression
tests. amd64 works fine, as does i386 on the released distributions.
parallel group (11 tests): create_cast create_aggregate drop_if_exists
typed_table create_function_3 vacuum constraints create_table_like triggers
inherit updat
On 05/13/2014 04:14 PM, Tom Lane wrote:
Heikki Linnakangas writes:
On 05/13/2014 09:58 PM, Tom Lane wrote:
... If so the issue is presumably
that the environment variable(s) were set to incorrect values. While
we *could* abort in that situation, I've never heard of any program
that did; the
Re: Tom Lane 2014-05-13 <27525.1400012...@sss.pgh.pa.us>
> Heikki Linnakangas writes:
> > On 05/13/2014 09:58 PM, Tom Lane wrote:
> >> ... If so the issue is presumably
> >> that the environment variable(s) were set to incorrect values. While
> >> we *could* abort in that situation, I've never he
Hi Peter,
On Tue, May 13, 2014 at 9:44 PM, Peter Geoghegan wrote:
>
> On Tue, May 13, 2014 at 12:36 PM, Rohit Goyal wrote:
>
>> This pattern the above found many times. Please guide me through!!!
>>
>
> IIRC, people have been working around this by setting
> standard_conforming_strings to "off"
On 05/13/2014 03:40 PM, Tom Lane wrote:
Tomas Vondra writes:
On 13.5.2014 21:03, Andrew Dunstan wrote:
On 05/13/2014 02:39 PM, Tomas Vondra wrote:
However in the lastrun-logs I see 81 files, and upon closer inspection
it seems that pretty much logs for all custom locales (cs_CZ.*, sk_SK.*)
a
Heikki Linnakangas writes:
> On 05/13/2014 09:58 PM, Tom Lane wrote:
>> ... If so the issue is presumably
>> that the environment variable(s) were set to incorrect values. While
>> we *could* abort in that situation, I've never heard of any program
>> that did; the normal response is to silently
On 13.5.2014 20:58, Tom Lane wrote:
> Tomas Vondra writes:
>> a few days ago I switched magpie into an LXC container, and while
>> fixinig unrelated issue there, I noticed that although the tests seemed
>> to run, some of the results are actually rubbish because of missing locales.
>
>> So for ex
On 05/13/2014 09:58 PM, Tom Lane wrote:
Tomas Vondra writes:
a few days ago I switched magpie into an LXC container, and while
fixinig unrelated issue there, I noticed that although the tests seemed
to run, some of the results are actually rubbish because of missing locales.
So for example w
On Sun, May 11, 2014 at 4:47 PM, Tom Lane wrote:
> The $64 question is whether we'd accept an implementation that fails
> if the target table has children (ie, is partitioned). That seems
> to me to not be up to the project's usual quality expectations, but
> maybe if there's enough demand for a
On Tue, May 13, 2014 at 12:36 PM, Rohit Goyal wrote:
> This pattern the above found many times. Please guide me through!!!
>
IIRC, people have been working around this by setting
standard_conforming_strings to "off". It really ought to be fixed in a
principled way, though -- the real issue here
Tomas Vondra writes:
> On 13.5.2014 21:03, Andrew Dunstan wrote:
>> On 05/13/2014 02:39 PM, Tomas Vondra wrote:
>>> However in the lastrun-logs I see 81 files, and upon closer inspection
>>> it seems that pretty much logs for all custom locales (cs_CZ.*, sk_SK.*)
>>> are missing:
>> Clearly this
Hi All,
I run the the *dbt2-pgsql-build-db -w 1 *
but, after some time, I faced this error
*/home/abhi/dbt2_install/bin/dbt2-pgsql-load-stored-procs: 45: [: c:
unexpected operator*
*/home/abhi/dbt2_install/bin/dbt2-pgsql-load-stored-procs: 53: [: c:
unexpected operator*
*unknown stored function
Please check this patch.
2014-05-12 22:56 GMT+04:00 Sergey Muraviov :
> Hi.
>
> I'll try to fix it tomorrow.
>
>
> 2014-05-12 18:42 GMT+04:00 Tom Lane :
>
> Greg Stark writes:
>> > On Mon, May 12, 2014 at 2:12 PM, Greg Stark wrote:
>> >> Hm, there was an off by one error earlier in some cases,
On 13.5.2014 21:03, Andrew Dunstan wrote:
>
> On 05/13/2014 02:39 PM, Tomas Vondra wrote:
>> On 13.5.2014 20:27, Tomas Vondra wrote:
>>> Hi all,
>>>
>>> a few days ago I switched magpie into an LXC container, and while
>>> fixinig unrelated issue there, I noticed that although the tests seemed
>>>
On Fri, May 9, 2014 at 04:53:18PM +0200, Andres Freund wrote:
> Hi,
>
> I've attached a fair number of fixes for the current state of the
> release notes. Many of them are fixing factual errors, others are more
> minors.
> I think the whole 'logical decoding' section will need an entire
> rewrite
On 05/13/2014 02:39 PM, Tomas Vondra wrote:
On 13.5.2014 20:27, Tomas Vondra wrote:
Hi all,
a few days ago I switched magpie into an LXC container, and while
fixinig unrelated issue there, I noticed that although the tests seemed
to run, some of the results are actually rubbish because of miss
Tomas Vondra writes:
> a few days ago I switched magpie into an LXC container, and while
> fixinig unrelated issue there, I noticed that although the tests seemed
> to run, some of the results are actually rubbish because of missing locales.
> So for example when the system misses cs_CZ.WIN-1250
On 10.5.2014 20:21, Tomas Vondra wrote:
> On 9.5.2014 00:47, Tomas Vondra wrote:
>
>> So, if I get this right, the proposal is to have 7 animals:
>>
>>
>> 1) all branches/locales, frequent builds (every few hours)
>> magpie - gcc
>> fulmar - icc
>> treepie - clang
>>
>> 2) single branch/loc
On 13.5.2014 20:27, Tomas Vondra wrote:
> Hi all,
>
> a few days ago I switched magpie into an LXC container, and while
> fixinig unrelated issue there, I noticed that although the tests seemed
> to run, some of the results are actually rubbish because of missing locales.
I forgot to mention that
Hi all,
a few days ago I switched magpie into an LXC container, and while
fixinig unrelated issue there, I noticed that although the tests seemed
to run, some of the results are actually rubbish because of missing locales.
So for example when the system misses cs_CZ.WIN-1250 (i.e. czech locale
wi
On Tue, May 13, 2014 at 10:12 AM, Zhe-Wei Jiang wrote:
> Hi everyone,
>
> I'm new to the open source community, and wanna help in some
> implementation work.
> However, when I looked into the TODO list, I found most of the items are
> very old.
>
So that is one thing you can do to help, try to im
* Zhe-Wei Jiang (jrreinha...@gmail.com) wrote:
> Therefore, I'd like to know if there is any entry-level implementation
> needed by PostgreSQL now?
> Any advise is appreciated.
You might take a look at the GSoC ideas page instead:
https://wiki.postgresql.org/wiki/GSoC_2014
Thanks,
Hi everyone,
I'm new to the open source community, and wanna help in some implementation
work.
However, when I looked into the TODO list, I found most of the items are
very old.
Therefore, I'd like to know if there is any entry-level implementation
needed by PostgreSQL now?
Any advise is appreciat
On 05/08/2014 07:33 PM, and...@2ndquadrant.com wrote:
When cache invalidations arrive while ri_LoadConstraintInfo() is busy
filling a new cache entry, InvalidateConstraintCacheCallBack()
compares the - not yet initialized - oidHashValue field with the
to-be-invalidated hash value. To fix check wh
Re: Alvaro Herrera 2014-05-13 <20140513135526.gr6...@eldon.alvh.no-ip.org>
> > I especially like MTC, Mars Time Coordinated. But whatever scheme gets
> > chosen, it won't be a standard 24h day, so PostgreSQL has a whole lot
> > of different problems to solve than to "fix" that little
> > Mars/Mons_
On 05/13/2014 04:35 PM, Andres Freund wrote:
On 2014-05-13 16:31:25 +0300, Heikki Linnakangas wrote:
Another thing I noticed is that if when the output goes to a file, the file
isn't re-opened immediately on SIGHUP. Only after receiving some data from
the server. I believe that's also not intent
Amit Kapila writes:
> How about sorting step, are you thinking to have MergeAppend
> node for it beneath ModifyTable?
Well yeah, that's pretty much the point.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to you
On 2014-05-13 15:33:08 +0300, Heikki Linnakangas wrote:
> On 05/06/2014 10:03 PM, Andres Freund wrote:
> >Hi,
> >
> >I am not sure whether these are new for 9.4 but they're worth looking at
> >anyway:
> >Valgrind was run with:
> > --trace-children=yes --quiet \
> > --track-origins=yes --leak-chec
Christoph Berg writes:
> Re: Tom Lane 2014-05-10 <27476.1399729...@sss.pgh.pa.us>
>> Our normal procedure is
>> o update config.guess and config.sub at the start of beta
>> (from http://savannah.gnu.org/projects/config)
> Fwiw, shouldn't that also happen in back branches?
No, we are not in the h
Christoph Berg wrote:
> Of course, Wikipedia has something to say about this:
> http://en.wikipedia.org/wiki/Timekeeping_on_Mars
Nice.
> I especially like MTC, Mars Time Coordinated. But whatever scheme gets
> chosen, it won't be a standard 24h day, so PostgreSQL has a whole lot
> of different p
Tom Lane wrote:
> Christoph Berg writes:
> > 84df54b22e8035addc7108abd9ff6995e8c49264 introduced timestamp
> > constructors. In the regression tests, various time zones are tested,
> > including America/Metlakatla. Now, if you configure using
> > --with-system-tzdata, you'll get an error if that z
On 2014-05-13 16:31:25 +0300, Heikki Linnakangas wrote:
> pg_recvlogical re-opens the output file on SIGHUP. If the output goes to
> stdout, it will close stdout on SIGHUP. That's a bug, isn't it?
Yes. An annoying one at that because it'll mean a a new connection will
use that fd and we'll start w
pg_recvlogical re-opens the output file on SIGHUP. If the output goes to
stdout, it will close stdout on SIGHUP. That's a bug, isn't it?
Another thing I noticed is that if when the output goes to a file, the
file isn't re-opened immediately on SIGHUP. Only after receiving some
data from the se
On 05/06/2014 10:03 PM, Andres Freund wrote:
Hi,
I am not sure whether these are new for 9.4 but they're worth looking at
anyway:
Valgrind was run with:
--trace-children=yes --quiet \
--track-origins=yes --leak-check=no \
--read-var-info=yes \
--suppressions=/home/andres/src/postgresql/s
On 05/13/2014 08:08 AM, Rajeev rastogi wrote:
>The core of the design is to store the LSN of the commit record in
>pg_clog. Currently, we only store 2 bits per transaction there,
>indicating if the transaction committed or not, but the patch will
>expand it to 64 bits, to store the LSN. To check
On 05/13/2014 09:44 AM, Amit Kapila wrote:
On Mon, May 12, 2014 at 7:26 PM, Heikki Linnakangas
wrote:
In theory, we could use a snapshot LSN as the cutoff-point for
HeapTupleSatisfiesVisibility(). Maybe it's just because this is new, but
that makes me feel uneasy.
To accomplish this won't XID
Re: Tom Lane 2014-05-10 <27476.1399729...@sss.pgh.pa.us>
> Christoph Berg writes:
> > to support ppc64le, config.guess needs to be updated. The attached
> > patch is what was reported to work for Ubuntu.
>
> Our normal procedure is
>
> o update config.guess and config.sub at the start of b
Re: Robert Haas 2014-05-13
> On Mon, May 12, 2014 at 7:16 PM, Tom Lane wrote:
> > I'm quite unimpressed by the dependency on Mars/Mons_Olympus, too ... that
> > might not fail *today*, but considering it's a real location, assuming it
> > is not in the IANA database seems like a recipe for futur
57 matches
Mail list logo
