Re: [PATCHES] Snapshot management, final
[Reposting with compressed patch] Okay, I think I've fixed most of the issues in the reviewed patch. Updated patch attached. The most interesting change is that I've done away with CopySnapshot as a public routine in favor of a new PushUpdatedSnapshot which does the copy-update-push sequence. Also I added a refcount to RegdSnapshotElt as suggested, and changed the subxact logic to substract that exact amount on abort. There's something I'm not sure what to do about: Tom Lane wrote: > Also, I think that the whole snapshot-sharing mechanism is not working > as intended except for the serializable case; otherwise sequences > like > x = RegisterSnapshot(GetTransactionSnapshot()); > y = RegisterSnapshot(GetTransactionSnapshot()); > will result in x and y being separate copies. Or are you assuming > that this just isn't worth optimizing? It's not that I don't think it's worth optimizing, but I think it's a bit away from the scope of this patch. The problem here is how to notice that two consecutive GetTransactionSnapshot calls should really return different snapshots, considering that shared state may change in between. Perhaps there's an easy way to optimize that; I don't know. What does work is to get (say) a registered snapshot and push it as active snapshot. That results in a successfully shared snapshot. For example PortalStart does that for cursors, etc. (FWIW another thing which is probably worth rethinking is the handling of snapshots around PortalStart. Some callers pass the currently active snapshot; Others pass InvalidSnapshot. Another passes an arbitrary snapshot. When it's Invalid, PortalStart calls GetTransactionSnapshot, otherwise it uses the passed snap for PushActiveSnapshot. So this is all a bit confusing and wasteful and could use some clean up. This is material for a new patch however.) -- Alvaro Herrerahttp://www.CommandPrompt.com/ PostgreSQL Replication, Consulting, Custom Development, 24x7 support snapshot-9.patch.gz Description: Binary data -- Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-patches
Re: [PATCHES] [NOVICE] encoding problems
On Fri, 9 May 2008 08:38:01 -0400 Alvaro Herrera <[EMAIL PROTECTED]> wrote: > Bruce Momjian escribió: > > Guillaume Smet wrote: > > > On Thu, May 8, 2008 at 9:11 PM, Bruce Momjian <[EMAIL PROTECTED]> > > > wrote: > > > > As I mentioned it before, is there any chance for this fix to be > > > backported to 8.3 branch? IMHO it's a usability regression. > > > > No, we don't change behaviors in back branches unless we get lots of > > complaints, and we haven't in this case. > > complaints++ > I suppose this a "Me Too" post, but Bruce Momjian invites it. You folks take this to a level way beyond me, but I can tell you that the idea of using spaces instead of the terminal hard tabs would solve my problem -- I'd prefer _any_ choice of whitespace over seeing "\x09" on the terminal. -- Cliff Nieuwenhuis "As long as the error messages keep changing we're making progress." -- Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-patches
Re: [PATCHES] create or replace language
On Sat, 3 May 2008 21:12:51 +0200 Andreas 'ads' Scherbaum wrote: > On Sat, 03 May 2008 13:34:05 -0400 Tom Lane wrote: > > > So maybe the right thing is that CREATE OR REPLACE LANGUAGE can change > > "inessential" properties of an existing language, but not the core > > properties --- which might only be the handler function, though you > > could make a case for the validator and the trusted flag as well. > > Already thought about that: exchanging the handler function or the > libbrary might only be useful in a developing environment, i don't see > other use cases here. The same is true for the validator (but a missing > validator could be added afterwards) and in my opinion i would prefer > not to change the trust flag - some functions may depend on this. > > The name cannot be changed at all so only the owner and maybe the > validator is left ... Even the owner does not make sense, because it seems it is not possible that the owner will changed through the SQL interface. ALTER LANGUAGE already exists for this purpose and CREATE LANGUAGE has no option for the language owner. So do we want to replace any data (in my opinion only the validator is left) at all or just skip any error message? Kind regards -- Andreas 'ads' Scherbaum German PostgreSQL User Group -- Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-patches
