Thanks, applied.
---
Robert Lor wrote:
> Tom Lane wrote:
> > Robert Lor writes:
> >
> >> Tom Lane wrote:
> >>
> >>> I agree. If the probe is meant to track only *some* WAL writes
> >>> then it needs to be named som
Tom Lane wrote:
Robert Lor writes:
Tom Lane wrote:
I agree. If the probe is meant to track only *some* WAL writes
then it needs to be named something less generic than
TRACE_POSTGRESQL_WAL_BUFFER_WRITE.
How about change it to TRACE_POSTGRESQL_WAL_BUFFER_WRITE_DIRTY similar to
Robert Lor writes:
> Tom Lane wrote:
>> I agree. If the probe is meant to track only *some* WAL writes
>> then it needs to be named something less generic than
>> TRACE_POSTGRESQL_WAL_BUFFER_WRITE.
>>
> How about change it to TRACE_POSTGRESQL_WAL_BUFFER_WRITE_DIRTY similar to
> TRACE_POSTGRESQL
Tom Lane wrote:
"Fujii Masao" writes:
I understood your intention. But, I think that its function name is somewhat
confusing.
I agree. If the probe is meant to track only *some* WAL writes
then it needs to be named something less generic than
TRACE_POSTGRESQL_WAL_BUFFER_WRITE.
H
"Fujii Masao" writes:
> On Thu, Dec 18, 2008 at 4:49 AM, Robert Lor wrote:
>> My understanding is that we only want to track the XLogWrite when advancing
>> to the next buffer page, and if there is unwritten data in the new buffer
>> page, that indicates no more empty WAL buffer pages available,
Hi,
On Thu, Dec 18, 2008 at 4:49 AM, Robert Lor wrote:
> Alvaro Herrera wrote:
>>
>> But there are 5 callers of XLogWrite ... why aren't the other ones being
>> tracked too?
>>
>>
>
> This probe originally came from Simon, so it can't possibly be wrong :-)
>
> My understanding is that we only wan
Alvaro Herrera wrote:
But there are 5 callers of XLogWrite ... why aren't the other ones being
tracked too?
This probe originally came from Simon, so it can't possibly be wrong :-)
My understanding is that we only want to track the XLogWrite when
advancing to the next buffer page, and if
Robert Lor escribió:
> Fujii Masao wrote:
>> Hi,
>>
>> On Wed, Dec 17, 2008 at 4:53 AM, Robert Lor wrote:
>> Why is TRACE_POSTGRESQL_WAL_BUFFER_WRITE_START/DONE called
>> only in AdvanceXLInsertBuffer? We can trace only a part of WAL buffer write?
>>
> The intention of these probes is to deter
Fujii Masao wrote:
Hi,
On Wed, Dec 17, 2008 at 4:53 AM, Robert Lor wrote:
@@ -1313,12 +1318,14 @@ AdvanceXLInsertBuffer(bool new_segment)
* Have to write buffers while holding insert
lock. This is
* not good, so only write as m
Hi,
On Wed, Dec 17, 2008 at 4:53 AM, Robert Lor wrote:
> @@ -1313,12 +1318,14 @@ AdvanceXLInsertBuffer(bool new_segment)
> * Have to write buffers while holding insert
> lock. This is
> * not good, so only write as much as we
> absol
Thanks, applied.
---
Robert Lor wrote:
> Bruce Momjian wrote:
> >
> > I am seeing the following error when linking the backend on a BSD machine:
> >
> >
> >
> The updated patch attached should fix this problem. My bad for
Bruce Momjian wrote:
I am seeing the following error when linking the backend on a BSD machine:
The updated patch attached should fix this problem. My bad for
overlooking this.
-Robert
Index: src/backend/access/transam/xlog.c
Bruce Momjian wrote:
> I am seeing the following error when linking the backend on a BSD machine:
>
> ./../src/port/libpgport_srv.a -lssl -lcrypto -lgetopt -ldl -lutil -lm -o
> postgres
> storage/buffer/bufmgr.o: In function `ReadBuffer_common':
> storage/buffer/bufmgr.o(.
Robert Lor wrote:
> Bruce Momjian wrote:
> > Should I apply this or hold it for 8.5?
> >
> >
> >
> I think it should go into 8.4 as it also fixes existing problems.
I am seeing the following error when linking the backend on a BSD machine:
./../src/port/libpgport_srv.a -lssl -lcrypto -
Bruce Momjian wrote:
Should I apply this or hold it for 8.5?
I think it should go into 8.4 as it also fixes existing problems.
-Robert
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hack
Robert Lor wrote:
> Peter Eisentraut wrote:
>> Robert Lor wrote:
>>>
>>> The attached patch contains a couple of fixes in the existing probes
>>> and includes a few new ones.
>>>
>>> - Fixed compilation errors on OS X for probes that use typedefs
>>
>> Could you explain what these errors are abou
Peter Eisentraut wrote:
Robert Lor wrote:
The attached patch contains a couple of fixes in the existing probes
and includes a few new ones.
- Fixed compilation errors on OS X for probes that use typedefs
Could you explain what these errors are about? I don't see any errors
on my machine.
Robert Lor wrote:
The attached patch contains a couple of fixes in the existing probes and
includes a few new ones.
- Fixed compilation errors on OS X for probes that use typedefs
Could you explain what these errors are about? I don't see any errors
on my machine.
--
Sent via pgsql-hac
Should I apply this or hold it for 8.5?
---
Robert Lor wrote:
>
> The attached patch contains a couple of fixes in the existing probes and
> includes a few new ones.
>
> - Fixed compilation errors on OS X for probes that
The attached patch contains a couple of fixes in the existing probes and
includes a few new ones.
- Fixed compilation errors on OS X for probes that use typedefs
- Fixed a number of probes to pass ForkNumber per the relation forks patch
- The new probes are those that were taken out from the p
20 matches
Mail list logo
