On May 29, 2008, at 1:57 AM, Hannu Krosing wrote:
On Wed, 2008-05-28 at 19:11 -0400, Mike wrote:
Can somebody point to the most logical place in the code to intercept
the WAL writes? (just a rough direction would be enough)- or if this
doesn’t make sense at all, another suggestion on where to
Mike schrieb:
Hello,
I’m new to the core PostgreSQL code, so pardon the question if the
answer is really obvious, and I’m just missing it, but I’ve got a
relatively large web application that uses PostgreSQL as a back-end
database, and we’re heavily using memcached to cache frequently
acces
On Wed, 2008-05-28 at 21:47 -0400, Mike wrote:
> On Wed, May 28, 2008 at 8:30 PM, Mike <[EMAIL PROTECTED]> wrote:
> >> When you say a bit of decoding, is that because the data written to the
> logs
> >> is after the query parser/planner? Or because it's written in several
> >> chunks? Or?
> >
> >B
"Mike" <[EMAIL PROTECTED]> writes:
> Is there another place in the code, I can get access to the statements (or
> statement "like" information), after a transaction commit?
No.
Bear in mind that what you have decided to do amounts to rolling your
own replication system. This is a Hard Problem.
>On Wed, May 28, 2008 at 8:30 PM, Mike <[EMAIL PROTECTED]> wrote:
>> When you say a bit of decoding, is that because the data written to the
logs
>> is after the query parser/planner? Or because it's written in several
>> chunks? Or?
>
>Because that's the actual recovery record. There is no SQL te
On Wed, 2008-05-28 at 19:11 -0400, Mike wrote:
>
> Can somebody point to the most logical place in the code to intercept
> the WAL writes? (just a rough direction would be enough)- or if this
> doesn’t make sense at all, another suggestion on where to get the
> data?
I don't think that intercep
On Wed, May 28, 2008 at 7:11 PM, Mike <[EMAIL PROTECTED]> wrote:
>> Can somebody point to the most logical place in the code to intercept the
>> WAL writes? (just a rough direction would be enough)
>
>XLogInsert
>
Great- I'll take a look at that code.
>> or if this doesn't make sense at all, anot
And you will have a chance to encounter full page writes, whole page
image, which could be produced during the hot backup and the first
modification to the data page after a checkpoint (if you turn full
page write option "on" by GUC).
2008/5/29 Mike <[EMAIL PROTECTED]>:
> On Wed, May 28, 2008 at 8
On Wed, May 28, 2008 at 8:30 PM, Mike <[EMAIL PROTECTED]> wrote:
>> When you say a bit of decoding, is that because the data written to the
logs
>> is after the query parser/planner? Or because it's written in several
>> chunks? Or?
>
>Because that's the actual recovery record. There is no SQL tex
On Wed, May 28, 2008 at 8:30 PM, Mike <[EMAIL PROTECTED]> wrote:
> When you say a bit of decoding, is that because the data written to the logs
> is after the query parser/planner? Or because it's written in several
> chunks? Or?
Because that's the actual recovery record. There is no SQL text, ju
On Wed, 2008-05-28 at 19:11 -0400, Mike wrote:
> Can somebody point to the most logical place in the code to intercept
> the WAL writes? (just a rough direction would be enough)- or if this
> doesn’t make sense at all, another suggestion on where to get the
> data? (I’m trying to avoid doing it usi
On Wed, May 28, 2008 at 7:11 PM, Mike <[EMAIL PROTECTED]> wrote:
> Can somebody point to the most logical place in the code to intercept the
> WAL writes? (just a rough direction would be enough)
XLogInsert
> or if this doesn't make sense at all, another suggestion on where to get
> the data? (I'
Hello,
I'm new to the core PostgreSQL code, so pardon the question if the answer is
really obvious, and I'm just missing it, but I've got a relatively large web
application that uses PostgreSQL as a back-end database, and we're heavily
using memcached to cache frequently accessed data.
I'm
13 matches
Mail list logo
