On Wed, Aug 22, 2012 at 10:24 PM, Tom Lane wrote:
> It looks sane to me in a quick once-over (bearing in mind I can't test
> it).
Well, bad news. Dave built an installer off the 9.1 tip, we provided
it to the customer, and they can still reproduce the problem. It's
not clear whether we've narro
On Mon, Aug 27, 2012 at 9:58 AM, Bruce Momjian wrote:
> On Tue, Jan 17, 2012 at 04:46:50PM -0500, David Schnur wrote:
>> I finally had time to test this further on a variety of systems, and was
>> unable
>> to reproduce on any non-Windows platform. The dump even works fine on
>> Windows
>> XP;
On Mon, Aug 27, 2012 at 12:33 PM, Alvaro Herrera
wrote:
> Excerpts from Bruce Momjian's message of lun ago 27 12:12:25 -0400 2012:
>>
>> Did we want this patch applied? Not enough demand?
>
> I think it should be in the next commitfest for discussion. I don't see
> any reason to reject it. I t
On Tue, Aug 28, 2012 at 6:40 AM, Amit Kapila wrote:
> AFAICT during Update also, it doesn't contain useful. The only chance it
> would have contain something useful is when it goes for EvalPlanQual and
> then again comes to check for constraints. However these attributes get
> filled in heap_upd
On Wed, Sep 5, 2012 at 8:55 PM, Tom Lane wrote:
> Peter Eisentraut writes:
>> Maybe it would be easier if multiple -k options accumulated.
>
> After further thought I'm not very enamored of that concept. We've made
> considerable compromises to ensure that every postmaster command-line
> option
On Wed, Sep 5, 2012 at 9:57 AM, wrote:
> The following bug has been logged on the website:
>
> Bug reference: 7521
> Logged by: Boy de Laat
> Email address: b...@atsc.nl
> PostgreSQL version: 9.1.4
> Operating system: CentOS 6.2 x86_64
> Description:
>
> I've setup some slave
Robert Haas writes:
> On Wed, Sep 5, 2012 at 9:57 AM, wrote:
>> So it would be nice if there is an option to disable WAL logging while
>> running pg_dump.
> pg_dump doesn't modify any data, so I don't see how it could be
> causing WAL logs to get generated.
Doesn't hint-bit setting cause WAL t
Robert Haas writes:
> On Mon, Aug 27, 2012 at 9:58 AM, Bruce Momjian wrote:
>> From Tom Lane in the above thread:
>>> Hmm. I can see how that would happen if you're using one of the Windows
>>> environments wherein malloc's done inside libpq have to be free'd inside
>>> libpq. (The PQExpBuffer
On Thu, Sep 6, 2012 at 3:55 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Wed, Sep 5, 2012 at 9:57 AM, wrote:
>>> So it would be nice if there is an option to disable WAL logging while
>>> running pg_dump.
>
>> pg_dump doesn't modify any data, so I don't see how it could be
>> causing WAL log
On 06.09.2012 13:07, Robert Haas wrote:
On Thu, Sep 6, 2012 at 3:55 PM, Tom Lane wrote:
Robert Haas writes:
On Wed, Sep 5, 2012 at 9:57 AM, wrote:
So it would be nice if there is an option to disable WAL logging while
running pg_dump.
pg_dump doesn't modify any data, so I don't see how i
On Thu, Sep 6, 2012 at 4:08 PM, Heikki Linnakangas wrote:
> On 06.09.2012 13:07, Robert Haas wrote:
pg_dump doesn't modify any data, so I don't see how it could be
causing WAL logs to get generated.
>>>
>>> Doesn't hint-bit setting cause WAL traffic these days?
>>
>> I sure as heck don't
Heikki Linnakangas writes:
> On 06.09.2012 13:07, Robert Haas wrote:
>> On Thu, Sep 6, 2012 at 3:55 PM, Tom Lane wrote:
>>> Doesn't hint-bit setting cause WAL traffic these days?
>> I sure as heck don't think so.
> It does not. HOT page pruning does, however. It could be that..
Sorry, I was th
At the time my backup starts i see much WAL logs being generated?
Met vriendelijke groet,
Boy de Laat
Verzonden via iPhone
Op 6 sep. 2012 om 21:44 heeft "Robert Haas" het
volgende geschreven:
> On Wed, Sep 5, 2012 at 9:57 AM, wrote:
> > The following bug has been logged on the website:
> >
Robert Haas writes:
> Well, bad news. Dave built an installer off the 9.1 tip, we provided
> it to the customer, and they can still reproduce the problem. It's
> not clear whether we've narrowed the scope of the problem without
> eliminating it, or whether that fix just didn't help at all. But
On Thu, Sep 6, 2012 at 4:23 PM, Tom Lane wrote:
> Heikki Linnakangas writes:
>> On 06.09.2012 13:07, Robert Haas wrote:
>>> On Thu, Sep 6, 2012 at 3:55 PM, Tom Lane wrote:
Doesn't hint-bit setting cause WAL traffic these days?
>
>>> I sure as heck don't think so.
>
>> It does not. HOT page
Excerpts from Tom Lane's message of jue sep 06 17:23:07 -0300 2012:
> Heikki Linnakangas writes:
> > On 06.09.2012 13:07, Robert Haas wrote:
> >> On Thu, Sep 6, 2012 at 3:55 PM, Tom Lane wrote:
> >>> Doesn't hint-bit setting cause WAL traffic these days?
>
> >> I sure as heck don't think so.
>
On Thu, Sep 6, 2012 at 5:07 PM, Alvaro Herrera wrote:
> How about secondary effects -- say pg_dump reads a lot of data into
> buffers that were previously dirty and those get evicted. Could page
> eviction cause lots of WAL to be emitted?
No. Simon's proposed checksum patch would have that effe
Excerpts from Boy de Laat's message of jue sep 06 17:24:35 -0300 2012:
>
> At the time my backup starts i see much WAL logs being generated?
I guess we'd need to see what the generated WAL logs are, either with
xlogdump or XLOG_DEBUG turned on ...
--
Álvaro Herrerahttp://www.2nd
Marko Tiikkaja writes:
> On 03/09/2012 18:06, Tom Lane wrote:
>> This might be the wrong theory. You seem to have debug symbols for that
>> core dump --- can you tell which of the dereferences in line 3373
>> caused the crash?
> The current_call_data->prodesc->fn_readonly one.
> Please let me kn
I wrote:
> Another thing that seems a bit risky is that plperl_func_handler sets up
> current_call_data as a pointer to a mostly-zeroed struct and then does
> assorted things that could throw error. That would leave a dangling
> value of current_call_data ...
Meh, scratch that --- I missed that t
On Fri, Sep 7, 2012 at 2:43 AM, Alvaro Herrera wrote:
> Excerpts from Boy de Laat's message of jue sep 06 17:24:35 -0300 2012:
> >
> > At the time my backup starts i see much WAL logs being generated?
>
> I guess we'd need to see what the generated WAL logs are, either with
> xlogdump or XLOG_DEBU
The following bug has been logged on the website:
Bug reference: 7522
Logged by: Radu Ovidiu
Email address: ir...@unix-world.org
PostgreSQL version: 9.0.9
Operating system: NetBSD
Description:
Hi,
I am trying to build the PostgreSQL 9.0.9 over NetBSD 5.1.2 (64-bit).
I
ir...@unix-world.org writes:
> I am trying to build the PostgreSQL 9.0.9 over NetBSD 5.1.2 (64-bit).
> I got the following error.
> I tried to compile the 9.1.5 and still the same error.
> The 8.3.17 and 8.4.11 (are OK) they are compiling with no errors (under the
> same build script).
ECPGt_strin
On Friday, September 07, 2012 12:20 AM Amit Kapila wrote:
On Tue, Aug 28, 2012 at 6:40 AM, Amit Kapila wrote:
>> AFAICT during Update also, it doesn't contain useful. The only chance
it
>> would have contain something useful is when it goes for EvalPlanQual and
>> then again comes to check for c
Yes, you are right.
After I checked the sha1 of file I found was modified.
It was downloaded from other location than postgresql and was named
postgresql-9.0.9.tar.bz2, but was not the final.
After I downloaded the original from postgresql.org everything works smooth.
Thanks,
Radu
On Sep 7, 201
On Thu, Sep 6, 2012 at 8:48 PM, Pavan Deolasee wrote:
>
>
> On Fri, Sep 7, 2012 at 2:43 AM, Alvaro Herrera
> wrote:
>>
>> Excerpts from Boy de Laat's message of jue sep 06 17:24:35 -0300 2012:
>> >
>> > At the time my backup starts i see much WAL logs being generated?
>>
>> I guess we'd need to s
26 matches
Mail list logo