Re: How many Mandatory Process are there in Postgres

>
> Hi Scott, Thomas,

Thank you for the update.

> >> Oracle uses a completely different implementation of MVCC
> architecture.
> >> It
> >> overwrites the data and then uses rollback segments to provide 'previous
> >> versions' to running transactions etc.
> >>
> >> PostgreSQL does not overwrite the data - it just creates a copy of the
> >> row
> >> and then decides which version should each session see (depending on the
> >> transaction IDs etc.). So it does not need to do rollbacks the way
> >> Oracle
> >> does, but it has to remove stale copies of the rows (such that no
> >> running
> >> transaction can see) - that's why there is VACUUM.
> >
> >
> > Here, if you have issued a command pg_start_backup() at that time the
> > cluster is freezed, and if any transaction takes place before the
> > pg_stop_backup() issued at that time where the transaction data will be
> > kept
> > if the undo's are not there.
>
>
> What do you mean by 'freezed'? The cluster operates normally, the
> pg_start_backup() just creates a backup label (and performs a checkpoint),
> but that's not a problem. OK, there could be a performance decrease
> because of full page writes, but the data will be processed as if there is
> no backup running. PostgreSQL does not need the checkpoints to perform
> backup.
>

The 'UNDO' data is just kept in the main data files. Then, based on what
> your xid is, and the xmin / xmax on each row, it's either visible or not.
> That's what vacuum does, clean up the rows that are for 'undo' and can
> never been seen anymore. The REDO itself is kept in the transaction logs.

> Like Thomas says, the pg_start_backup() just creates a label that tells the
> restoring database what pg_xlog record to start with when you 'restore' your
> data. The 'UNDO' type of data (just the old rows actually) is just kept in
> the main table until vacuum nukes 'em.

--Scott
Q1. Does vacuum process come into existence even you turn off the
autovacuum.? What is the main work for vacuum process, to the clean the
buffers or work only when autovacuum in on and to clean up the rows that are
'undo'
Q2. Do you mean to say there is a vacuum process which will clean up the
buffers that are for 'undo'?
Q3. Fine, if the vacuum is off then your data files will hold the undo data
also in it?

> See this:
>
> http://wiki.postgresql.org/wiki/User:Gsmith#How_is_the_shared_buffer_cache_organized

Shared buffers is a LRU cache, i.e. when it's full and a new buffer is
> requested, some of the 'oldest' buffers are removed.

Suppose, if there is a big transaction going on , in between of the
transaction shared_buffer got filled even after oldest buffers are removed,
at that time where does operation performs to finish up the transaction. As
it is a shared buffer every clients will be accessing this and even they
demand for the space for there operation too.

Regards
Raghav

On Thu, Mar 25, 2010 at 10:49 PM, Scott Mead
<scott(dot)lists(at)enterprisedb(dot)com>wrote:

> 2010/3/25 <tv(at)fuzzy(dot)cz>
>
> <Snip>
>
>
>> >> Oracle uses a completely different implementation of MVCC architecture.
>> >> It
>> >> overwrites the data and then uses rollback segments to provide
>> 'previous
>> >> versions' to running transactions etc.
>> >>
>> >> PostgreSQL does not overwrite the data - it just creates a copy of the
>> >> row
>> >> and then decides which version should each session see (depending on
>> the
>> >> transaction IDs etc.). So it does not need to do rollbacks the way
>> >> Oracle
>> >> does, but it has to remove stale copies of the rows (such that no
>> >> running
>> >> transaction can see) - that's why there is VACUUM.
>> >
>> >
>> > Here, if you have issued a command pg_start_backup() at that time the
>> > cluster is freezed, and if any transaction takes place before the
>> > pg_stop_backup() issued at that time where the transaction data will be
>> > kept
>> > if the undo's are not there.
>>
>> What do you mean by 'freezed'? The cluster operates normally, the
>> pg_start_backup() just creates a backup label (and performs a checkpoint),
>> but that's not a problem. OK, there could be a performance decrease
>> because of full page writes, but the data will be processed as if there is
>> no backup running. PostgreSQL does not need the checkpoints to perform
>> backup.
>>
>
> The 'UNDO' data is just kept in the main data files. Then, based on what
> your xid is, and the xmin / xmax on each row, it's either visible or not.
> That's what vacuum does, clean up the rows that are for 'undo' and can
> never been seen anymore. The REDO itself is kept in the transaction logs.
>
> Like Thomas says, the pg_start_backup() just creates a label that tells the
> restoring database what pg_xlog record to start with when you 'restore' your
> data. The 'UNDO' type of data (just the old rows actually) is just kept in
> the main table until vacuum nukes 'em.
>
> --Scott
>