Thread: Re: [HACKERS] Anyone want to assist with the translation of the

The lock on the relation owning the rule wasn't unlocked.

On Wed, 2002-10-02 at 19:36, Michael Paesold wrote:
> Justin Clift <justin@postgresql.org> wrote:
>
>
> > Hi Michael,
> >
> > Michael Paesold wrote:
> > <snip>
> > > Hi Justin,
> > >
> > > I am from Austria, and I would like to help. I could provide a German
> > > translation. The Babelfish's translation is really funny. Machine
> > > translation is readable, but it is no advocacy. ;-) I do not really nead
> an
> > > interface, but just tell me in what way you want the texts.
> >
> > Cool.  Could you deal with an OpenOffice Calc or M$ Excel file having
> > the lines of English text in one column, and doing the German
> > translation into a second column?
> >
> > That might be easiest, and will allow a cut-n-paste of the German
> > version straight into the database backend.
> >
> > Sound workable to you?
>
> Spreadsheet sounds great. I use M$.
> Perhaps you can group the items in categories, at least navigation and text.
> So I know where the text will be put on the website. The translation could
> be different depending on how a word is used. E.g. it is quite common on
> German websites to use the same English word "Home" for the main page; but
> you would not use "Home" in a different context. The exceptable length of a
> translation depends on the context, too.
>
> Best Regards,
> Michael Paesold
>
>
>
> ---------------------------(end of broadcast)---------------------------
> TIP 5: Have you checked our extensive FAQ?
>
> http://www.postgresql.org/users-lounge/docs/faq.html
>
--
  Rod Taylor

Rod Taylor <rbt@rbt.ca> writes:
>       /* Call CreateComments() to create/drop the comments */
>       CreateComments(ruleoid, classoid, 0, comment);
> +
> +     heap_close(relation, AccessShareLock);
>   }
>
>   /*

Ooops.

I think though that this should read

+    heap_close(relation, NoLock);

In general, we hold locks on user relations we are modifying until end
of transaction.  This is different from the rule for system catalogs
(eg, it's okay to drop the AccessShareLock on pg_rewrite a few lines
above this).  The reason for the distinction is that we want to be
sure that the user relation won't get DROPped by someone else before
we've committed our changes.  (If someone else did try to drop it in
that interval, they'd not delete the pg_description row we just added,
because they couldn't see it.)  On the other hand, system catalogs such
as pg_rewrite are not going to go away, by definition, and so it's okay
to drop their locks early.  The only reason we lock system catalogs at
all is to allow VACUUM FULL to nail down exclusive access to a catalog
while it vacuums it.

            regards, tom lane

Tom's change added to Rod's patch:

Your patch has been added to the PostgreSQL unapplied patches list at:

    http://candle.pha.pa.us/cgi-bin/pgpatches

I will try to apply it within the next 48 hours.

---------------------------------------------------------------------------


Tom Lane wrote:
> Rod Taylor <rbt@rbt.ca> writes:
> >       /* Call CreateComments() to create/drop the comments */
> >       CreateComments(ruleoid, classoid, 0, comment);
> > +
> > +     heap_close(relation, AccessShareLock);
> >   }
> >
> >   /*
>
> Ooops.
>
> I think though that this should read
>
> +    heap_close(relation, NoLock);
>
> In general, we hold locks on user relations we are modifying until end
> of transaction.  This is different from the rule for system catalogs
> (eg, it's okay to drop the AccessShareLock on pg_rewrite a few lines
> above this).  The reason for the distinction is that we want to be
> sure that the user relation won't get DROPped by someone else before
> we've committed our changes.  (If someone else did try to drop it in
> that interval, they'd not delete the pg_description row we just added,
> because they couldn't see it.)  On the other hand, system catalogs such
> as pg_rewrite are not going to go away, by definition, and so it's okay
> to drop their locks early.  The only reason we lock system catalogs at
> all is to allow VACUUM FULL to nail down exclusive access to a catalog
> while it vacuums it.
>
>             regards, tom lane
>
> ---------------------------(end of broadcast)---------------------------
> TIP 1: subscribe and unsubscribe commands go to majordomo@postgresql.org
>

--
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073