On Mon, 2008-09-15 at 16:00 +0100, Simon Riggs wrote:
> On Mon, 2008-09-15 at 10:04 -0400, Tom Lane wrote:
> > Simon Riggs <[EMAIL PROTECTED]> writes:
>
> > > The version mismatch idea presumes that a code author would
> structure
> > > their code in two pieces: one to generate the WAL and one to
On Mon, 2008-09-15 at 16:43 +0100, Gregory Stark wrote:
> Simon Riggs <[EMAIL PROTECTED]> writes:
>
> > Bottom line is that any backup of Postgres needs to include plugin
> > directories, otherwise parts of the application could stop working
> > following restore. This patch doesn't change that.
Simon Riggs <[EMAIL PROTECTED]> writes:
> Bottom line is that any backup of Postgres needs to include plugin
> directories, otherwise parts of the application could stop working
> following restore. This patch doesn't change that.
No, backups of executables are normally not the same backups as th
On Mon, 2008-09-15 at 10:04 -0400, Tom Lane wrote:
> Simon Riggs <[EMAIL PROTECTED]> writes:
> > The version mismatch idea presumes that a code author would structure
> > their code in two pieces: one to generate the WAL and one to read it.
>
> No, the version mismatch problem is that you might
Simon Riggs <[EMAIL PROTECTED]> writes:
> We have plugin APIs with possible version mismatches in other contexts,
> but I don't see us doing anything about that. In the context of WAL, the
> basic WAL format has not changed in about 6 releases, so its been one of
> the most stable file formats.
Er
Simon Riggs wrote:
On Mon, 2008-09-15 at 08:52 -0400, Tom Lane wrote:
I've never heard of anyone building a non-core index AM at all; much
less trying to use it in a production context. Given the obvious
potential for version-mismatch-type problems, it's hard to believe
that anyone ever would t
Simon Riggs <[EMAIL PROTECTED]> writes:
> The version mismatch idea presumes that a code author would structure
> their code in two pieces: one to generate the WAL and one to read it.
> Seems much more likely to me that authors would have one module
> containing both as a way of avoiding the probl
On Mon, 2008-09-15 at 08:52 -0400, Tom Lane wrote:
> Gregory Stark <[EMAIL PROTECTED]> writes:
> > Simon Riggs <[EMAIL PROTECTED]> writes:
> >> Indexes have always been able to be added dynamically. Now they can be
> >> recovered correctly as well.
>
> > Hm, so currently if you want to add a new
Tom Lane <[EMAIL PROTECTED]> writes:
> Gregory Stark <[EMAIL PROTECTED]> writes:
>> Simon Riggs <[EMAIL PROTECTED]> writes:
>>> Indexes have always been able to be added dynamically. Now they can be
>>> recovered correctly as well.
>
>> Hm, so currently if you want to add a new indexam you can't j
Gregory Stark <[EMAIL PROTECTED]> writes:
> Simon Riggs <[EMAIL PROTECTED]> writes:
>> Indexes have always been able to be added dynamically. Now they can be
>> recovered correctly as well.
> Hm, so currently if you want to add a new indexam you can't just insert into
> pg_am and make them recover
On Mon, 2008-09-15 at 10:47 +0100, Gregory Stark wrote:
> Simon Riggs <[EMAIL PROTECTED]> writes:
>
> > On Sat, 2008-09-13 at 10:59 +0300, Heikki Linnakangas wrote:
> >
> >> The 2nd use case, however, I find pretty unconvincing. I can't think of
> >> a good example of that. Anything that needs t
Simon Riggs <[EMAIL PROTECTED]> writes:
> On Sat, 2008-09-13 at 10:59 +0300, Heikki Linnakangas wrote:
>
>> The 2nd use case, however, I find pretty unconvincing. I can't think of
>> a good example of that. Anything that needs to define its own resource
>> manager is very low-level stuff, and pr
On Sat, 2008-09-13 at 10:59 +0300, Heikki Linnakangas wrote:
> The importance of the WAL will only increase as more people start to
> use it for PITR, replication etc.
Agreed.
> The 2nd use case, however, I find pretty unconvincing. I can't think of
> a good example of that. Anything that need
Simon Riggs wrote:
On Tue, 2008-09-02 at 11:39 -0400, Tom Lane wrote:
, I'm not seeing the use-case
for an rmgr that only executes during recovery; in fact I'm not entirely
sure that I see a use-case for this entire patch. Where are the WAL
records that the "loadable rmgr" processes going to co
On Tue, 2008-09-02 at 11:39 -0400, Tom Lane wrote:
> Simon Riggs <[EMAIL PROTECTED]> writes:
> > On Tue, 2008-09-02 at 18:30 +0900, ITAGAKI Takahiro wrote:
> >> How about adding a new variable "recovery_preload_libaries" like as
> >> shared_preload_libraries? Rmgr libs in it are loaded only in sta
Simon Riggs <[EMAIL PROTECTED]> writes:
> On Tue, 2008-09-02 at 18:30 +0900, ITAGAKI Takahiro wrote:
>> How about adding a new variable "recovery_preload_libaries" like as
>> shared_preload_libraries? Rmgr libs in it are loaded only in startup
>> process and only if recovery is needed.
> Good poin
On Tue, 2008-09-02 at 13:38 +0300, Heikki Linnakangas wrote:
> There's one more reason to use shared_preload_libraries. It provides a
> sanity check that the library required for recovery is present and
> can
> be loaded, even when no recovery is required. If you have
> misconfigured
> your sys
ITAGAKI Takahiro wrote:
I see that RmgrTable should be malloc'd when required,
but there is another issue; when to load rmgr libraries.
Rmgr objects are needed only in startup process during recovery.
If we want to reduce resource consumption by rmgrs, I think it is
better not to load rmgr libra
On Tue, 2008-09-02 at 18:30 +0900, ITAGAKI Takahiro wrote:
> Simon Riggs <[EMAIL PROTECTED]> wrote:
>
> > > Why do we need to set rmgr_hook in _PG_init(), and add or mofify rmgrs
> > > in our hook functions?
> >
> > If we modify RmgrTable in _PG_init() then we would have to have that
> > structu
Simon Riggs <[EMAIL PROTECTED]> wrote:
> > Why do we need to set rmgr_hook in _PG_init(), and add or mofify rmgrs
> > in our hook functions?
>
> If we modify RmgrTable in _PG_init() then we would have to have that
> structure available in all backends, which was a stated objective to
> avoid. We
20 matches
Mail list logo
