fix schema ownership on first connection preliminary patch v2

From: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>
To: Fabien COELHO <coelho(at)cri(dot)ensmp(dot)fr>
Cc: PostgreSQL-patches <pgsql-patches(at)postgresql(dot)org>
Subject: fix schema ownership on first connection preliminary patch v2
Date: 2004-07-09 20:42:18
Message-ID: 200407092042.i69KgIR08723@candle.pha.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers pgsql-patches


I have added the v2 version of this patch to the patch queue (attached).
I agree with Tom that there is no need for regression tests for this
feature and have removed that part of the patch.

http://momjian.postgresql.org/cgi-bin/pgpatches

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

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

Fabien COELHO wrote:
>
> Dear hackers,
>
> Please find attached a preliminary patch to fix schema ownership on first
> connection. It is for comments and advices as I still have doubts about
> various how-and-where issues, thus it is not submitted to the patch list.
>
> (1) It adds a new "datisinit" attribute to pg_database, which tells
> whether the database initialization was performed or not.
> The documentation is updated accordingly.
>
> (2) This boolean is tested in postinit.c:ReverifyMyDatabase,
> and InitializeDatabase is called if necessary.
>
> (3) The routine updates pg_database datisinit, as well as pg_namespace
> ownership and acl stuff. The acl item update part is not yet
> appropriate: I'd like some answers before going on.
>
> (4) Some validation is added. It passes for me.
>
>
> My questions:
>
> - is the place for the first connection housekeeping updates appropriate?
> it seems so from ReverifyMyDatabase comments, but these are only comments.
>
> - it is quite convenient to use SPI_* stuff for this very rare updates,
> but I'm not that confident about the issue... On the other hand, the
> all-C solution would result in a much longer and less obvious code.
>
> - it is unclear to me whether it should be allowed to skip this under
> some condition, when the database is accessed in "debug" mode from
> a standalone postgres for instance?
>
> - also I'm wondering how to react (what to do and how to do it) on
> errors within or under these initialization. For instance, how to
> be sure that the CurrentUser is reset as expected?
>
> Thanks in advance for your answers and comments.
>
> Have a nice day.
>
> --
> Fabien Coelho - coelho(at)cri(dot)ensmp(dot)fr

Content-Description:

[ Attachment, skipping... ]

>
> ---------------------------(end of broadcast)---------------------------
> TIP 7: don't forget to increase your free space map settings

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

Attachment Content-Type Size
unknown_filename text/plain 13.5 KB

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Alvaro Herrera 2004-07-09 20:43:51 Re: Nested Transactions, Abort All
Previous Message Simon Riggs 2004-07-09 20:32:20 Re: Nested Transactions, Abort All

Browse pgsql-patches by date

  From Date Subject
Next Message Kris Jurka 2004-07-09 23:55:07 Re: ResultSerMetaData.getColumnDisplaySize() with timestamp
Previous Message Simon Riggs 2004-07-09 19:38:39 Re: PITR Archive Recovery plus WIP PITR