he help.
On Thu, Sep 1, 2011 at 10:03 PM, Tom Lane wrote:
> Fazool writes:
>> I am implementing some functionality into Postgresql, where I want to
>> track which row was accessed by a user query. I am implementing the
>> functionality inside Postgres, so that there are no
Hello everyone,
I am implementing some functionality into Postgresql, where I want to
track which row was accessed by a user query. I am implementing the
functionality inside Postgres, so that there are no changes required
on client side (e.g. re-writing queries).
Rows are identified by OIDs, and
On Tue, Oct 26, 2010 at 11:23 AM, Robert Haas wrote:
> On Tue, Oct 26, 2010 at 2:13 PM, Heikki Linnakangas
> wrote:
> >
> >> Can you please describe why
> >> walsender reading directly from the buffers was given up? To avoid a lot
> >> of
> >> locking?
> >
> > To avoid locking yes, and complexit
> Might I suggest adopting the same technique walsender does, ie just read
> the data back from disk? There's a reason why we gave up trying to have
> walsender read directly from the buffers.
>
>
That is exactly what I do not want to do, i.e. read from disk, as long as
the piece of WAL is availab
Hello guys,
I'm writing a function that will read data from the buffer in xlog (i.e.
from XLogCtl->pages and XLogCtl->xlblocks). I want to make sure that I am
doing it correctly.
For reading from the buffer, do I need to lock WALInsertLock or
WALWriteLock? Also, can you explain a bit the usage of
I believe we should come up with a universal solution that will solve
potential future problems as well (for example, if in sync replication, we
decide to send writes to standbys in parallel to writing on local disk).
The ideal thing would be to have an id that is incremented on every failure,
and
Hello guys,
The concept of time line makes sense to me in the case of asynchronous
replication. But in case of synchronous replication, I am not so sure.
When a standby connects to the primary, it checks if both have the same time
line. If not, it doesn't start.
Now, consider the following scena
Ah, great. I missed looking there.
Thanks.
On Sun, Sep 26, 2010 at 4:19 PM, Fujii Masao wrote:
> On Mon, Sep 27, 2010 at 7:46 AM, fazool mein wrote:
> > I checked the code for the keepalive feature. It seems that the socket
> > options are only set on the primary's socket
ed or some bug?
Thanks.
On Fri, Sep 17, 2010 at 7:05 PM, fazool mein wrote:
> Apologies. I'm new to Postgres and I didn't see that feature. It satisfies
> what I want to do.
>
> Thanks.
>
>
> On Thu, Sep 16, 2010 at 7:34 PM, Fujii Masao wrote:
>
>>
Thanks for the tips.
In our case, SIGINT makes more sense. I'll use that.
Regards
On Tue, Sep 21, 2010 at 7:50 PM, Fujii Masao wrote:
> On Wed, Sep 22, 2010 at 2:50 AM, fazool mein wrote:
> > Yes, I'll be modifying the code. In the walreceiver, I used the following
>
On Tue, Sep 21, 2010 at 8:32 AM, David Fetter wrote:
> On Mon, Sep 20, 2010 at 05:48:40PM -0700, fazool mein wrote:
> > Hi,
> >
> > I want to shut down the server under certain conditions that can be
> > checked inside a backend process. For instance, while running
&g
On Mon, Sep 20, 2010 at 9:44 PM, Fujii Masao wrote:
> On Tue, Sep 21, 2010 at 9:48 AM, fazool mein wrote:
> > Hi,
> >
> > I want to shut down the server under certain conditions that can be
> checked
> > inside a backend process. For instance, while running symme
Hi,
I want to shut down the server under certain conditions that can be checked
inside a backend process. For instance, while running symmetric replication,
if the primary dies, I want the the walreceiver to detect that and shutdown
the standby. The reason for shutdown is that I want to execute so
Apologies. I'm new to Postgres and I didn't see that feature. It satisfies
what I want to do.
Thanks.
On Thu, Sep 16, 2010 at 7:34 PM, Fujii Masao wrote:
> On Fri, Sep 17, 2010 at 6:49 AM, fazool mein wrote:
> > I am designing a heartbeat system between replicas to
Hello everyone,
I am designing a heartbeat system between replicas to know when a replica
goes down so that necessary measures can be taken. As I see, there are two
ways of doing it:
1) Creating a separate heartbeat process on replicas.
2) Creating a heartbeat message, and sending it over the con
Thanks!
I'll wait for the merging then; there is no point in benchmarking otherwise.
Regards
On Tue, Aug 31, 2010 at 6:06 PM, Fujii Masao wrote:
> On Wed, Sep 1, 2010 at 9:34 AM, Robert Haas wrote:
> >> There are patches, and the latest from Fujii Masao is probably worth
> >> looking at :)
>
Hello everyone,
I'm interested in benchmarking synchronous replication, to see how
performance degrades compared to asynchronous streaming replication.
I browsed through the archive of emails, but things still seem unclear. Do
we have a final agreed upon patch that I can use? Any links for that?
17 matches
Mail list logo
