Discussion:
Regarding timezone
Dev Kumkar
2014-09-10 14:50:00 UTC
Permalink
Hello,

I want to change the timezone to Europe/Moscow. Moscow timezone is changing
from +4 to +3

On the box, I have changed the timezone to MSK+3.

>From the db side I have modified the following files:
1) postgresql.conf
timezone = 'Europe/Moscow'
2) pgsql/share/postgresql/timezonesets/Default
MSK 10800 # Moscow Time (caution: this used to mean
10800)
# (Europe/Moscow)
# date
Wed Sep 10 17:34:14 MSK 2014

Running following queries the output is as follows:
- select now() => "2014-09-10 18:34:19.041994+04"
- select now() at time zone 'MSK' => "2014-09-10 17:34:31.006944"

What changes needs to done so that now() returns expected value which
matches with the time zone?

Thanks in advance!

Regards...
Tom Lane
2014-09-10 15:13:30 UTC
Permalink
Dev Kumkar <***@gmail.com> writes:
> I want to change the timezone to Europe/Moscow. Moscow timezone is changing
> from +4 to +3

You'd want to get a new version of the IANA timezone database files for
that. Depending on what packaging you're using, this might be an
operating-system update not a Postgres update. If you are relying
on the Postgres copies, you'd have to update src/timezone/data/ and
then do a "make install" in src/timezone.

regards, tom lane


--
Sent via pgsql-general mailing list (pgsql-***@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
Dev Kumkar
2014-09-12 05:59:23 UTC
Permalink
On Wed, Sep 10, 2014 at 8:43 PM, Tom Lane <***@sss.pgh.pa.us> wrote:

> You'd want to get a new version of the IANA timezone database files for
> that. Depending on what packaging you're using, this might be an
> operating-system update not a Postgres update. If you are relying
> on the Postgres copies, you'd have to update src/timezone/data/ and
> then do a "make install" in src/timezone.
>
> regards, tom lane
>

Thanks Tom !
Actually am using the postgres binaries and not building from sources. Is
there any solution if using the binaries and want to update timezone
settings?

Regards...
Adrian Klaver
2014-09-12 14:01:03 UTC
Permalink
On 09/11/2014 10:59 PM, Dev Kumkar wrote:
>
> On Wed, Sep 10, 2014 at 8:43 PM, Tom Lane <***@sss.pgh.pa.us
> <mailto:***@sss.pgh.pa.us>> wrote:
>
> You'd want to get a new version of the IANA timezone database files for
> that. Depending on what packaging you're using, this might be an
> operating-system update not a Postgres update. If you are relying
> on the Postgres copies, you'd have to update src/timezone/data/ and
> then do a "make install" in src/timezone.
>
> regards, tom lane
>
>
> Thanks Tom !
> Actually am using the postgres binaries and not building from sources.
> Is there any solution if using the binaries and want to update timezone
> settings?

What OS and what packaging?

>
> Regards...


--
Adrian Klaver
***@aklaver.com


--
Sent via pgsql-general mailing list (pgsql-***@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
Dev Kumkar
2014-09-16 12:46:33 UTC
Permalink
On Fri, Sep 12, 2014 at 7:31 PM, Adrian Klaver <***@aklaver.com>
wrote:

>
> What OS and what packaging?
>
> For both windows-64-bit and Linux-64-bit.
PostgreSQL version - 9.3.4

I believe the file "pgsql/share/postgresql/timezone/Europe/Moscow" will
require changes.
As the above changes will then be reflected in the function
*pg_timezone_names()* which will modify the output as follows:

<< "Europe/Moscow";"MSK";"04:00:00";f
>> "Europe/Moscow";"MSK";"03:00:00";f

Can I get a modified version of this file?

Regards...
Dev Kumkar
2014-09-17 06:43:25 UTC
Permalink
On Tue, Sep 16, 2014 at 6:16 PM, Dev Kumkar <***@gmail.com> wrote:

> On Fri, Sep 12, 2014 at 7:31 PM, Adrian Klaver <***@aklaver.com>
> wrote:
>
>>
>> What OS and what packaging?
>>
>> For both windows-64-bit and Linux-64-bit.
> PostgreSQL version - 9.3.4
>
> I believe the file "pgsql/share/postgresql/timezone/Europe/Moscow" will
> require changes.
> As the above changes will then be reflected in the function
> *pg_timezone_names()* which will modify the output as follows:
>
> << "Europe/Moscow";"MSK";"04:00:00";f
> >> "Europe/Moscow";"MSK";"03:00:00";f
>
> Can I get a modified version of this file?
>
> Regards...
>

Any inputs?

Regards...
Adrian Klaver
2014-09-17 13:54:53 UTC
Permalink
On 09/16/2014 11:43 PM, Dev Kumkar wrote:
> On Tue, Sep 16, 2014 at 6:16 PM, Dev Kumkar <***@gmail.com
> <mailto:***@gmail.com>> wrote:
>
> On Fri, Sep 12, 2014 at 7:31 PM, Adrian Klaver
> <***@aklaver.com <mailto:***@aklaver.com>> wrote:
>
>
> What OS and what packaging?
>
> For both windows-64-bit and Linux-64-bit.
> PostgreSQL version - 9.3.4
>
> I believe the file "pgsql/share/postgresql/timezone/Europe/Moscow"
> will require changes.
> As the above changes will then be reflected in the function
> *pg_timezone_names()* which will modify the output as follows:
>
> << "Europe/Moscow";"MSK";"04:00:00";f
> >> "Europe/Moscow";"MSK";"03:00:00";f
>
> Can I get a modified version of this file?
>
> Regards...
>
>
> Any inputs?

Tom already answered this upstream:

http://www.postgresql.org/message-id/***@sss.pgh.pa.us

It is possible that the binary package(s) you are using do not use the
Postgres built in timezone information. They can be compiled to use the
OS timezone database:

http://www.postgresql.org/docs/9.3/interactive/install-procedure.html

--with-system-tzdata=DIRECTORY

PostgreSQL includes its own time zone database, which it requires
for date and time operations. This time zone database is in fact
compatible with the "zoneinfo" time zone database provided by many
operating systems such as FreeBSD, Linux, and Solaris, so it would be
redundant to install it again. When this option is used, the
system-supplied time zone database in DIRECTORY is used instead of the
one included in the PostgreSQL source distribution. DIRECTORY must be
specified as an absolute path. /usr/share/zoneinfo is a likely directory
on some operating systems. Note that the installation routine will not
detect mismatching or erroneous time zone data. If you use this option,
you are advised to run the regression tests to verify that the time zone
data you have pointed to works correctly with PostgreSQL.

This option is mainly aimed at binary package distributors who know
their target operating system well. The main advantage of using this
option is that the PostgreSQL package won't need to be upgraded whenever
any of the many local daylight-saving time rules change. Another
advantage is that PostgreSQL can be cross-compiled more
straightforwardly if the time zone database files do not need to be
built during the installation.


So you will need to determine what method you binaries use. If they are
using the system timezone data, you will need to update that.

>
> Regards...


--
Adrian Klaver
***@aklaver.com


--
Sent via pgsql-general mailing list (pgsql-***@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
Dev Kumkar
2014-09-17 14:53:34 UTC
Permalink
On Wed, Sep 17, 2014 at 7:24 PM, Adrian Klaver <***@aklaver.com>
wrote:

> So you will need to determine what method you binaries use. If they are
> using the system timezone data, you will need to update that.


Thanks!

Just a hack here, how about copying
"pgsql/share/postgresql/timezone/Etc/GMT-3" as
"pgsql/share/postgresql/timezone/Europe/Moscow"
This will make the *pg_timezone_names()* function to return output as
follows:
>> "Europe/Moscow";"GMT-3";"03:00:00";f

With this "now()" function returns expected data for Moscow timezone.
Please let me know your comments here.

Regards..
Adrian Klaver
2014-09-17 15:22:57 UTC
Permalink
On 09/17/2014 07:53 AM, Dev Kumkar wrote:
> On Wed, Sep 17, 2014 at 7:24 PM, Adrian Klaver
> <***@aklaver.com <mailto:***@aklaver.com>> wrote:
>
> So you will need to determine what method you binaries use. If they
> are using the system timezone data, you will need to update that.
>
>
> Thanks!
>
> Just a hack here, how about copying
> "pgsql/share/postgresql/timezone/Etc/GMT-3" as
> "pgsql/share/postgresql/timezone/Europe/Moscow"
> This will make the *pg_timezone_names()* function to return output as
> follows:
> >> "Europe/Moscow";"GMT-3";"03:00:00";f
>
> With this "now()" function returns expected data for Moscow timezone.
> Please let me know your comments here.

I am not that versed in the timezone handling to make a definitive
statement. I would say it should work until you upgrade. At that point
the new Moscow timezone should be correct and the change will not
matter. I would verify on the upgrade though.

>
> Regards..


--
Adrian Klaver
***@aklaver.com


--
Sent via pgsql-general mailing list (pgsql-***@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
Dev Kumkar
2014-09-17 18:20:29 UTC
Permalink
On Wed, Sep 17, 2014 at 8:52 PM, Adrian Klaver <***@aklaver.com>
wrote:

>
> I am not that versed in the timezone handling to make a definitive
> statement. I would say it should work until you upgrade. At that point the
> new Moscow timezone should be correct and the change will not matter. I
> would verify on the upgrade though.


Which upgraded postgres version will have the corrected Moscow timezone?

Tom, can you too provide your comments on the mentioned hack here.

Regards...
Tom Lane
2014-09-17 18:31:17 UTC
Permalink
Dev Kumkar <***@gmail.com> writes:
> Which upgraded postgres version will have the corrected Moscow timezone?

The next set of minor releases, whenever those are (and no, there's
no schedule).

> Tom, can you too provide your comments on the mentioned hack here.

It would break timezone reporting for historical Moscow timestamps, ie
they'd be printed as GMT-3 whether or not that was applicable at the time.
Don't know whether you care about that.

regards, tom lane


--
Sent via pgsql-general mailing list (pgsql-***@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
Dev Kumkar
2014-09-17 19:26:47 UTC
Permalink
On Thu, Sep 18, 2014 at 12:01 AM, Tom Lane <***@sss.pgh.pa.us> wrote:

> The next set of minor releases, whenever those are (and no, there's
> no schedule).
>

I hope the binaries archive containing ""pgsql/share/postgresql/
timezone/Europe/Moscow" uploaded at
http://www.enterprisedb.com/products-services-training/pgbindownload will
also get corrected.

It would break timezone reporting for historical Moscow timestamps, ie
> they'd be printed as GMT-3 whether or not that was applicable at the time.
> Don't know whether you care about that.


The column storing datetime is of type "timestamp" and timezone is not
being stored. So should not be an issue for this particular use-case. For
"timestamp with time zone" that was definitely an issue.
By the way won't that be issue anyways once the Moscow timezone is
corrected in upgraded postgres version?

Regards...
Adrian Klaver
2014-09-17 19:52:23 UTC
Permalink
On 09/17/2014 12:26 PM, Dev Kumkar wrote:
> On Thu, Sep 18, 2014 at 12:01 AM, Tom Lane <***@sss.pgh.pa.us
> <mailto:***@sss.pgh.pa.us>> wrote:
>
> The next set of minor releases, whenever those are (and no, there's
> no schedule).
>
>
> I hope the binaries archive containing ""pgsql/share/postgresql/
> timezone/Europe/Moscow" uploaded at
> http://www.enterprisedb.com/products-services-training/pgbindownload
> will also get corrected.

They will.

>
> It would break timezone reporting for historical Moscow timestamps, ie
> they'd be printed as GMT-3 whether or not that was applicable at the
> time.
> Don't know whether you care about that.
>
>
> The column storing datetime is of type "timestamp" and timezone is not
> being stored. So should not be an issue for this particular use-case.
> For "timestamp with time zone" that was definitely an issue.
> By the way won't that be issue anyways once the Moscow timezone is
> corrected in upgraded postgres version?

No, because a timezone(versus an offset) definition includes a
historical record of the changes in the timezone. For all the gory
details see:

http://en.wikipedia.org/wiki/Tz_database

>
> Regards...


--
Adrian Klaver
***@aklaver.com


--
Sent via pgsql-general mailing list (pgsql-***@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
Dev Kumkar
2014-09-17 20:14:05 UTC
Permalink
On Thu, Sep 18, 2014 at 1:22 AM, Adrian Klaver <***@aklaver.com>
wrote:

> On 09/17/2014 12:26 PM, Dev Kumkar wrote:
>
>> I hope the binaries archive containing ""pgsql/share/postgresql/
>> timezone/Europe/Moscow" uploaded at
>> http://www.enterprisedb.com/products-services-training/pgbindownload
>> will also get corrected.
>>
>
> They will.
>

Thanks, on 25 October 2014 the timezone will change permanently. Currently
binaries are at 9.3.5.1 level, will keep an watch on the update.

No, because a timezone(versus an offset) definition includes a historical
> record of the changes in the timezone. For all the gory details see:
>
> http://en.wikipedia.org/wiki/Tz_database


Great info! So the historical Moscow timestamps will still reflect GMT+4
based on the datetime.
Sure, awaiting fix and will cross-check the behavior.
Adrian Klaver
2014-09-17 20:47:40 UTC
Permalink
On 09/17/2014 01:14 PM, Dev Kumkar wrote:
> On Thu, Sep 18, 2014 at 1:22 AM, Adrian Klaver
> <***@aklaver.com <mailto:***@aklaver.com>> wrote:
>
> On 09/17/2014 12:26 PM, Dev Kumkar wrote:
>
> I hope the binaries archive containing ""pgsql/share/postgresql/
> timezone/Europe/Moscow" uploaded at
> http://www.enterprisedb.com/__products-services-training/__pgbindownload
> <http://www.enterprisedb.com/products-services-training/pgbindownload>
> will also get corrected.
>
>
> They will.
>
>
> Thanks, on 25 October 2014 the timezone will change permanently.
> Currently binaries are at 9.3.5.1 level, will keep an watch on the update.
>
> No, because a timezone(versus an offset) definition includes a
> historical record of the changes in the timezone. For all the gory
> details see:
>
> http://en.wikipedia.org/wiki/Tz_database
>
>
> Great info! So the historical Moscow timestamps will still reflect GMT+4
> based on the datetime.

Or GMT+3 depending on the time of the year and what year:

http://en.wikipedia.org/wiki/Moscow_Time

A timezone definition does not necessarily mean a single offset. For
instance I live on the US West coast(Washington state) so I am in the
America/Los_Angeles(or US/Pacific ) timezone. This means the actual
offset changes over the course of a year and by year:

test=> show timezone;
TimeZone


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


US/Pacific


(1 row)





test=> select now();
now


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


2014-09-17 13:43:22.546162-07


(1 row)





test=> select '2014-11-03'::timestamptz;
timestamptz
------------------------
2014-11-03 00:00:00-08
(1 row)


test=> select '2000-10-30'::timestamptz;
timestamptz
------------------------
2000-10-30 00:00:00-08
(1 row)


> Sure, awaiting fix and will cross-check the behavior.


--
Adrian Klaver
***@aklaver.com


--
Sent via pgsql-general mailing list (pgsql-***@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
l***@kni-online.de
2014-09-17 15:08:58 UTC
Permalink
<html><head></head><body><div style="font-family: Verdana;font-size: 12.0px;"><div>Hi list,<br/>
I have a strange problem in postgres (PostgreSQL 9.3.1, compiled by Visual C++ build 1600, 64-bit), there are granted privileges on schemas, tables, columns for roles that don&#39;t exist.</div>

<div><br/>
Example:<br/>
In pgAdmin for schema user_data the follwing wrong grants are reported:<br/>
...<br/>
GRANT ALL ON SCHEMA user_data TO &quot;482499&quot;;<br/>
GRANT ALL ON SCHEMA user_data TO &quot;17708&quot;;<br/>
...</div>

<div><br/>
Problem is:<br/>
- these roles don&#39;t exist,<br/>
- they can&#39;t be dropped (DROP ROLE &quot;482499&quot;; =&gt; FEHLER:&nbsp; Rolle &bdquo;482499&ldquo; existiert nicht)<br/>
- grants can&#39;t be revoked (REVOKE ALL ON SCHEMA &quot;user_data&quot; FROM &quot;482499&quot;; =&gt; FEHLER:&nbsp; Rolle &bdquo;482499&ldquo; existiert nicht)<br/>
- ROLES can be recreated and dropped afterwards, but the grants persists:<br/>
&nbsp;&nbsp;&nbsp; CREATE ROLE &quot;482499&quot;;<br/>
&nbsp;&nbsp;&nbsp; DROP OWNED BY &quot;482499&quot;;<br/>
&nbsp;&nbsp;&nbsp; REVOKE CONNECT ON DATABASE &quot;wver_ims&quot; FROM &quot;482499&quot;;<br/>
&nbsp;&nbsp;&nbsp; REVOKE ALL ON SCHEMA &quot;user_data&quot; FROM &quot;482499&quot;;<br/>
&nbsp;&nbsp;&nbsp; DROP ROLE &quot;482499&quot;;<br/>
- new tables can&#39;t be created in schemas with these grants<br/>
&nbsp;&nbsp;&nbsp; CREATE TABLE user_data.test<br/>
&nbsp;&nbsp;&nbsp; (<br/>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; id serial,<br/>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; PRIMARY KEY (id)<br/>
&nbsp;&nbsp;&nbsp; );<br/>
&nbsp;&nbsp;&nbsp; =&gt; FEHLER:&nbsp; Rolle 17708 wurde gleichzeitig gel&ouml;scht<br/>
&nbsp;&nbsp; &nbsp;<br/>
&nbsp;&nbsp; &nbsp;<br/>
The roles are not listed in any catalog<br/>
&nbsp;&nbsp; &nbsp;SELECT * FROM information_schema.xxxxxxx WHERE grantee in (&#39;243683&#39;,&#39;243666&#39;,&#39;243689&#39;,&#39;482499&#39;,&#39;482499&#39;,&#39;17708&#39;);</div>

<div><br/>
Only in pg_auth_members there is a set for each of these roles:<br/>
&nbsp;&nbsp; &nbsp;SELECT * FROM pg_catalog.pg_auth_members WHERE member in (&#39;243683&#39;,&#39;243666&#39;,&#39;243689&#39;,&#39;482499&#39;,&#39;482499&#39;,&#39;17708&#39;);</div>

<div>&nbsp;</div>

<div>What can I do to get rid of these roles and grants?</div>

<div>&nbsp;</div>

<div>Ludwig</div></div></body></html>
Adrian Klaver
2014-09-17 15:33:33 UTC
Permalink
On 09/17/2014 08:08 AM, ***@kni-online.de wrote:
> Hi list,
> I have a strange problem in postgres (PostgreSQL 9.3.1, compiled by
> Visual C++ build 1600, 64-bit), there are granted privileges on schemas,
> tables, columns for roles that don't exist.

So how did the data get into the database?

>
> Example:
> In pgAdmin for schema user_data the follwing wrong grants are reported:
> ...
> GRANT ALL ON SCHEMA user_data TO "482499";
> GRANT ALL ON SCHEMA user_data TO "17708";

Where these actual roles at some point in time?

> ...
>
> Problem is:
> - these roles don't exist,
> - they can't be dropped (DROP ROLE "482499"; => FEHLER: Rolle „482499“
> existiert nicht)
> - grants can't be revoked (REVOKE ALL ON SCHEMA "user_data" FROM
> "482499"; => FEHLER: Rolle „482499“ existiert nicht)
> - ROLES can be recreated and dropped afterwards, but the grants persists:
> CREATE ROLE "482499";
> DROP OWNED BY "482499";
> REVOKE CONNECT ON DATABASE "wver_ims" FROM "482499";
> REVOKE ALL ON SCHEMA "user_data" FROM "482499";
> DROP ROLE "482499";
> - new tables can't be created in schemas with these grants
> CREATE TABLE user_data.test
> (
> id serial,
> PRIMARY KEY (id)
> );
> => FEHLER: Rolle 17708 wurde gleichzeitig gelöscht
>
>
> The roles are not listed in any catalog
> SELECT * FROM information_schema.xxxxxxx WHERE grantee in
> ('243683','243666','243689','482499','482499','17708');
>
> Only in pg_auth_members there is a set for each of these roles:
> SELECT * FROM pg_catalog.pg_auth_members WHERE member in
> ('243683','243666','243689','482499','482499','17708');

What does pg_auth_members show for the problem roles?

> What can I do to get rid of these roles and grants?
> Ludwig


--
Adrian Klaver
***@aklaver.com


--
Sent via pgsql-general mailing list (pgsql-***@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
l***@kni-online.de
2014-09-18 11:12:48 UTC
Permalink
<html><head></head><body><div style="font-family: Verdana;font-size: 12.0px;"><div>
<div>Hi Adrian,</div>

<div>data got into the database with normal update/insert-queries from logged-in database-users using &quot;normal&quot; PG-Users/roles,</div>

<div>the &quot;ghost-roles&quot; (with these unusual numerical role-names) were never created by me, I don&#39;t know where they come from.</div>

<div>&nbsp;</div>

<div>The query</div>

<div>[SNIP]</div>

<div>SELECT * FROM pg_catalog.pg_auth_members WHERE member in (&#39;243683&#39;,&#39;243666&#39;,&#39;243689&#39;,&#39;482499&#39;,&#39;482499&#39;,&#39;17708&#39;);</div>

<div>[/SNIP]</div>

<div>&nbsp;</div>

<div>has the following result:</div>

<div>[SNIP]</div>

<div>roleid;member;grantor;admin_option;</div>

<div>
<div>17699;17708;10;f<br/>
17699;482499;17687;f<br/>
17701;243666;17687;f<br/>
17699;243683;17687;f<br/>
17710;243689;17687;f</div>
</div>

<div>[/SNIP]</div>

<div>&nbsp;</div>

<div>Yust a thought:</div>

<div>In some schemas the public user has full default-privileges (it&#39;s for uploading GIS-data from Shapefiles, each uploaded file generates a new table).</div>

<div>[SNIP]</div>

<div>ALTER DEFAULT PRIVILEGES IN SCHEMA user_data<br/>
&nbsp;&nbsp;&nbsp; GRANT INSERT, SELECT, UPDATE, DELETE, TRUNCATE, REFERENCES, TRIGGER ON TABLES<br/>
&nbsp;&nbsp;&nbsp; TO public;</div>

<div>
<div>[/SNIP]</div>

<div>&nbsp;</div>

<div>Another thought:</div>

<div>Each &quot;normal&quot; DB-user has *one* granted role, but some of theses roles themselves can have mutliple granted subroles.</div>

<div>&nbsp;</div>

<div>Perhaps a reason for my problems?</div>

<div>&nbsp;</div>

<div>Ludwig</div>

<div name="quote" style="margin:10px 5px 5px 10px; padding: 10px 0 10px 10px; border-left:2px solid #C3D9E5; word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;">
<div style="margin:0 0 10px 0;"><b>Gesendet:</b>&nbsp;Mittwoch, 17. September 2014 um 17:33 Uhr<br/>
<b>Von:</b>&nbsp;&quot;Adrian Klaver&quot; &lt;***@aklaver.com&gt;<br/>
<b>An:</b>&nbsp;&quot;***@kni-online.de&quot; &lt;***@kni-online.de&gt;, pgsql-***@postgresql.org<br/>
<b>Betreff:</b>&nbsp;Re: [GENERAL] strange problem with not existing roles</div>

<div name="quoted-content">On 09/17/2014 08:08 AM, ***@kni-online.de wrote:<br/>
&gt; Hi list,<br/>
&gt; I have a strange problem in postgres (PostgreSQL 9.3.1, compiled by<br/>
&gt; Visual C++ build 1600, 64-bit), there are granted privileges on schemas,<br/>
&gt; tables, columns for roles that don&#39;t exist.<br/>
<br/>
So how did the data get into the database?<br/>
<br/>
&gt;<br/>
&gt; Example:<br/>
&gt; In pgAdmin for schema user_data the follwing wrong grants are reported:<br/>
&gt; ...<br/>
&gt; GRANT ALL ON SCHEMA user_data TO &quot;482499&quot;;<br/>
&gt; GRANT ALL ON SCHEMA user_data TO &quot;17708&quot;;<br/>
<br/>
Where these actual roles at some point in time?<br/>
<br/>
&gt; ...<br/>
&gt;<br/>
&gt; Problem is:<br/>
&gt; - these roles don&#39;t exist,<br/>
&gt; - they can&#39;t be dropped (DROP ROLE &quot;482499&quot;; =&gt; FEHLER: Rolle &bdquo;482499&ldquo;<br/>
&gt; existiert nicht)<br/>
&gt; - grants can&#39;t be revoked (REVOKE ALL ON SCHEMA &quot;user_data&quot; FROM<br/>
&gt; &quot;482499&quot;; =&gt; FEHLER: Rolle &bdquo;482499&ldquo; existiert nicht)<br/>
&gt; - ROLES can be recreated and dropped afterwards, but the grants persists:<br/>
&gt; CREATE ROLE &quot;482499&quot;;<br/>
&gt; DROP OWNED BY &quot;482499&quot;;<br/>
&gt; REVOKE CONNECT ON DATABASE &quot;wver_ims&quot; FROM &quot;482499&quot;;<br/>
&gt; REVOKE ALL ON SCHEMA &quot;user_data&quot; FROM &quot;482499&quot;;<br/>
&gt; DROP ROLE &quot;482499&quot;;<br/>
&gt; - new tables can&#39;t be created in schemas with these grants<br/>
&gt; CREATE TABLE user_data.test<br/>
&gt; (<br/>
&gt; id serial,<br/>
&gt; PRIMARY KEY (id)<br/>
&gt; );<br/>
&gt; =&gt; FEHLER: Rolle 17708 wurde gleichzeitig gel&ouml;scht<br/>
&gt;<br/>
&gt;<br/>
&gt; The roles are not listed in any catalog<br/>
&gt; SELECT * FROM information_schema.xxxxxxx WHERE grantee in<br/>
&gt; (&#39;243683&#39;,&#39;243666&#39;,&#39;243689&#39;,&#39;482499&#39;,&#39;482499&#39;,&#39;17708&#39;);<br/>
&gt;<br/>
&gt; Only in pg_auth_members there is a set for each of these roles:<br/>
&gt; SELECT * FROM pg_catalog.pg_auth_members WHERE member in<br/>
&gt; (&#39;243683&#39;,&#39;243666&#39;,&#39;243689&#39;,&#39;482499&#39;,&#39;482499&#39;,&#39;17708&#39;);<br/>
<br/>
What does pg_auth_members show for the problem roles?<br/>
<br/>
&gt; What can I do to get rid of these roles and grants?<br/>
&gt; Ludwig<br/>
<br/>
<br/>
--<br/>
Adrian Klaver<br/>
***@aklaver.com<br/>
<br/>
<br/>
--<br/>
Sent via pgsql-general mailing list (pgsql-***@postgresql.org)<br/>
To make changes to your subscription:<br/>
<a href="http://www.postgresql.org/mailpref/pgsql-general" target="_blank">http://www.postgresql.org/mailpref/pgsql-general</a></div>
</div>
</div>
</div></div></body></html>
Adrian Klaver
2014-09-18 13:53:25 UTC
Permalink
On 09/18/2014 04:12 AM, ***@kni-online.de wrote:
> Hi Adrian,
> data got into the database with normal update/insert-queries from
> logged-in database-users using "normal" PG-Users/roles,
> the "ghost-roles" (with these unusual numerical role-names) were never
> created by me, I don't know where they come from.

I should have been more specific.

Did the database get created by restoring a dump file from somewhere, or
via pg_upgrade or just by creating the schema and adding data over time?

The numeric part, at least as shown below, is the oid of the role and
all roles have that. The question is whether pgAdmin is showing the oid
or the actual role name? See below for a queries to help determine that.

> The query
> [SNIP]
> SELECT * FROM pg_catalog.pg_auth_members WHERE member in
> ('243683','243666','243689','482499','482499','17708');
> [/SNIP]
> has the following result:
> [SNIP]
> roleid;member;grantor;admin_option;
> 17699;17708;10;f
> 17699;482499;17687;f
> 17701;243666;17687;f
> 17699;243683;17687;f
> 17710;243689;17687;f
> [/SNIP]

So what is the result if you do?:

select * from pg_roles where oid in(10, 482499, 17708, 17687);

select * from pg_roles where rolname in('482499', '17708');

10 should be the postgres role, it is the others that are of interest.

> Yust a thought:
> In some schemas the public user has full default-privileges (it's for
> uploading GIS-data from Shapefiles, each uploaded file generates a new
> table).

So who originaly created the schema?

> [SNIP]
> ALTER DEFAULT PRIVILEGES IN SCHEMA user_data
> GRANT INSERT, SELECT, UPDATE, DELETE, TRUNCATE, REFERENCES, TRIGGER
> ON TABLES
> TO public;
> [/SNIP]
> Another thought:
> Each "normal" DB-user has *one* granted role, but some of theses roles
> themselves can have mutliple granted subroles.
> Perhaps a reason for my problems?

Not sure. At this point just trying to establish the current state.

> Ludwig

--
Adrian Klaver
***@aklaver.com


--
Sent via pgsql-general mailing list (pgsql-***@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
l***@kni-online.de
2014-09-18 16:44:53 UTC
Permalink
<html><head></head><body><div style="font-family: Verdana;font-size: 12.0px;"><div>
<div>Hi Adrian,</div>

<div>this database runs as develop-version on my PC and was created by hand, no dumps or pg_upgrade.</div>

<div>&nbsp;</div>

<div>The same database runs as production-version on another server (PostgreSQL 9.3.1, compiled by Visual C++ build 1600, 32-bit), so far without these problems.</div>

<div>&nbsp;</div>

<div>pgAdmin shows a mix of the normal roles and these &quot;ghost-roles&quot;, I don&#39;t know the queries running in pgAdmins-background for that result.</div>

<div>&nbsp;</div>

<div>[SNIP]</div>

<div>select * from pg_roles where oid in(10, 482499, 17708, 17687);</div>

<div>=&gt;</div>

<div>[SNIP]</div>

<div>
<div>kniprath;t;t;t;t;t;t;f;-1;********;infinity;;17687<br/>
postgres;t;t;t;t;t;t;t;-1;********;infinity;;10</div>

<div>[/SNIP]</div>

<div>&nbsp;</div>

<div>[SNIP]</div>

<div>select * from pg_roles where rolname in(&#39;482499&#39;, &#39;17708&#39;);</div>

<div>[/SNIP]</div>

<div>=&gt; empty result</div>

<div>&nbsp;</div>

<div>One tested workaround was to dump the schema-contents (tables, sequences, functions etc.), drop and recreate the schema and restore the dumped contents.</div>

<div>But I&#39;m curious about what has caused the problems and how to avoid them...</div>

<div>&nbsp;</div>

<div>Ludwig</div>
</div>

<div>&nbsp;
<div name="quote" style="margin:10px 5px 5px 10px; padding: 10px 0 10px 10px; border-left:2px solid #C3D9E5; word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;">
<div style="margin:0 0 10px 0;"><b>Gesendet:</b>&nbsp;Donnerstag, 18. September 2014 um 15:53 Uhr<br/>
<b>Von:</b>&nbsp;&quot;Adrian Klaver&quot; &lt;***@aklaver.com&gt;<br/>
<b>An:</b>&nbsp;&quot;***@kni-online.de&quot; &lt;***@kni-online.de&gt;, pgsql-***@postgresql.org<br/>
<b>Betreff:</b>&nbsp;Re: [GENERAL] strange problem with not existing roles</div>

<div name="quoted-content">On 09/18/2014 04:12 AM, ***@kni-online.de wrote:<br/>
&gt; Hi Adrian,<br/>
&gt; data got into the database with normal update/insert-queries from<br/>
&gt; logged-in database-users using &quot;normal&quot; PG-Users/roles,<br/>
&gt; the &quot;ghost-roles&quot; (with these unusual numerical role-names) were never<br/>
&gt; created by me, I don&#39;t know where they come from.<br/>
<br/>
I should have been more specific.<br/>
<br/>
Did the database get created by restoring a dump file from somewhere, or<br/>
via pg_upgrade or just by creating the schema and adding data over time?<br/>
<br/>
The numeric part, at least as shown below, is the oid of the role and<br/>
all roles have that. The question is whether pgAdmin is showing the oid<br/>
or the actual role name? See below for a queries to help determine that.<br/>
<br/>
&gt; The query<br/>
&gt; [SNIP]<br/>
&gt; SELECT * FROM pg_catalog.pg_auth_members WHERE member in<br/>
&gt; (&#39;243683&#39;,&#39;243666&#39;,&#39;243689&#39;,&#39;482499&#39;,&#39;482499&#39;,&#39;17708&#39;);<br/>
&gt; [/SNIP]<br/>
&gt; has the following result:<br/>
&gt; [SNIP]<br/>
&gt; roleid;member;grantor;admin_option;<br/>
&gt; 17699;17708;10;f<br/>
&gt; 17699;482499;17687;f<br/>
&gt; 17701;243666;17687;f<br/>
&gt; 17699;243683;17687;f<br/>
&gt; 17710;243689;17687;f<br/>
&gt; [/SNIP]<br/>
<br/>
So what is the result if you do?:<br/>
<br/>
select * from pg_roles where oid in(10, 482499, 17708, 17687);<br/>
<br/>
select * from pg_roles where rolname in(&#39;482499&#39;, &#39;17708&#39;);<br/>
<br/>
10 should be the postgres role, it is the others that are of interest.<br/>
<br/>
&gt; Yust a thought:<br/>
&gt; In some schemas the public user has full default-privileges (it&#39;s for<br/>
&gt; uploading GIS-data from Shapefiles, each uploaded file generates a new<br/>
&gt; table).<br/>
<br/>
So who originaly created the schema?<br/>
<br/>
&gt; [SNIP]<br/>
&gt; ALTER DEFAULT PRIVILEGES IN SCHEMA user_data<br/>
&gt; GRANT INSERT, SELECT, UPDATE, DELETE, TRUNCATE, REFERENCES, TRIGGER<br/>
&gt; ON TABLES<br/>
&gt; TO public;<br/>
&gt; [/SNIP]<br/>
&gt; Another thought:<br/>
&gt; Each &quot;normal&quot; DB-user has *one* granted role, but some of theses roles<br/>
&gt; themselves can have mutliple granted subroles.<br/>
&gt; Perhaps a reason for my problems?<br/>
<br/>
Not sure. At this point just trying to establish the current state.<br/>
<br/>
&gt; Ludwig<br/>
<br/>
--<br/>
Adrian Klaver<br/>
***@aklaver.com<br/>
<br/>
<br/>
--<br/>
Sent via pgsql-general mailing list (pgsql-***@postgresql.org)<br/>
To make changes to your subscription:<br/>
<a href="http://www.postgresql.org/mailpref/pgsql-general" target="_blank">http://www.postgresql.org/mailpref/pgsql-general</a></div>
</div>
</div>
</div></div></body></html>
Adrian Klaver
2014-09-18 19:40:49 UTC
Permalink
On 09/18/2014 09:44 AM, ***@kni-online.de wrote:
> Hi Adrian,
> this database runs as develop-version on my PC and was created by hand,
> no dumps or pg_upgrade.
> The same database runs as production-version on another server
> (PostgreSQL 9.3.1, compiled by Visual C++ build 1600, 32-bit), so far
> without these problems.
> pgAdmin shows a mix of the normal roles and these "ghost-roles", I don't
> know the queries running in pgAdmins-background for that result.

I would say pgAdmin could not find a rolname in pg_roles so it just used
the role oid as the role 'name'.

> [SNIP]
> select * from pg_roles where oid in(10, 482499, 17708, 17687);
> =>
> [SNIP]
> kniprath;t;t;t;t;t;t;f;-1;********;infinity;;17687
> postgres;t;t;t;t;t;t;t;-1;********;infinity;;10
> [/SNIP]
> [SNIP]
> select * from pg_roles where rolname in('482499', '17708');
> [/SNIP]
> => empty result
> One tested workaround was to dump the schema-contents (tables,
> sequences, functions etc.), drop and recreate the schema and restore the
> dumped contents.
> But I'm curious about what has caused the problems and how to avoid them...

Hard to say at this point. The only thing I can point out is the
postgres role granted membership to the 17708 'role' to whatever role
has the oid of 17699 and the kniprath role did the same for the 482499
'role'. Maybe looking up what is the role with an oid of 17699 might jog
the memory, so:

select * from pg_roles where oid = 17699;

The only other thing I can think to do is troll the Postgres logs over
the time period in question for the oids, GRANT, REVOKE, the schema
user_data and see if anything stands out.

> Ludwig



--
Adrian Klaver
***@aklaver.com


--
Sent via pgsql-general mailing list (pgsql-***@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
l***@kni-online.de
2014-09-23 10:54:35 UTC
Permalink
<html><head></head><body><div style="font-family: Verdana;font-size: 12.0px;"><div>
<div>Hi List,</div>

<div>a workaround for my own problems as described below:</div>

<div style="margin:0 0 10px 0;">In the following system-table-colums (type aclitem[]) I replaced all entries with these non-existing Group-Roles with something like {postgres=arwdDxt/postgres,kniprath=arwdDxt/kniprath}, this resets the privileges to just these two (Admin-) users.</div>

<div style="margin:0 0 10px 0;">&nbsp;&nbsp; pg_namespace.nspacl</div>

<div style="margin:0 0 10px 0;">&nbsp;&nbsp; pg_class.relacl</div>

<div style="margin:0 0 10px 0;">&nbsp;&nbsp; pg_default_acl.defaclacl</div>

<div style="margin:0 0 10px 0;">I dont&#39;t think it&#39;s good practice to update systemtables manually, but apparently I previously did something in my database, that messed the contents.</div>

<div style="margin:0 0 10px 0;">Ludwig</div>

<div style="margin:0 0 10px 0;"><b>Gesendet:</b>&nbsp;Mittwoch, 17. September 2014 um 17:08 Uhr<br/>
<b>Von:</b>&nbsp;&quot;***@kni-online.de&quot; &lt;***@kni-online.de&gt;<br/>
<b>An:</b>&nbsp;pgsql-***@postgresql.org<br/>
<b>Betreff:</b>&nbsp;strange problem with not existing roles</div>

<div>
<div name="quote" style="margin:10px 5px 5px 10px; padding: 10px 0 10px 10px; border-left:2px solid #C3D9E5; word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;">
<div name="quoted-content">
<div style="font-family: Verdana;font-size: 12.0px;">
<div>Hi list,<br/>
I have a strange problem in postgres (PostgreSQL 9.3.1, compiled by Visual C++ build 1600, 64-bit), there are granted privileges on schemas, tables, columns for roles that don&#39;t exist.</div>

<div><br/>
Example:<br/>
In pgAdmin for schema user_data the follwing wrong grants are reported:<br/>
...<br/>
GRANT ALL ON SCHEMA user_data TO &quot;482499&quot;;<br/>
GRANT ALL ON SCHEMA user_data TO &quot;17708&quot;;<br/>
...</div>

<div><br/>
Problem is:<br/>
- these roles don&#39;t exist,<br/>
- they can&#39;t be dropped (DROP ROLE &quot;482499&quot;; =&gt; FEHLER:&nbsp; Rolle &bdquo;482499&ldquo; existiert nicht)<br/>
- grants can&#39;t be revoked (REVOKE ALL ON SCHEMA &quot;user_data&quot; FROM &quot;482499&quot;; =&gt; FEHLER:&nbsp; Rolle &bdquo;482499&ldquo; existiert nicht)<br/>
- ROLES can be recreated and dropped afterwards, but the grants persists:<br/>
&nbsp;&nbsp;&nbsp; CREATE ROLE &quot;482499&quot;;<br/>
&nbsp;&nbsp;&nbsp; DROP OWNED BY &quot;482499&quot;;<br/>
&nbsp;&nbsp;&nbsp; REVOKE CONNECT ON DATABASE &quot;wver_ims&quot; FROM &quot;482499&quot;;<br/>
&nbsp;&nbsp;&nbsp; REVOKE ALL ON SCHEMA &quot;user_data&quot; FROM &quot;482499&quot;;<br/>
&nbsp;&nbsp;&nbsp; DROP ROLE &quot;482499&quot;;<br/>
- new tables can&#39;t be created in schemas with these grants<br/>
&nbsp;&nbsp;&nbsp; CREATE TABLE user_data.test<br/>
&nbsp;&nbsp;&nbsp; (<br/>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; id serial,<br/>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; PRIMARY KEY (id)<br/>
&nbsp;&nbsp;&nbsp; );<br/>
&nbsp;&nbsp;&nbsp; =&gt; FEHLER:&nbsp; Rolle 17708 wurde gleichzeitig gel&ouml;scht<br/>
&nbsp;&nbsp; &nbsp;<br/>
&nbsp;&nbsp; &nbsp;<br/>
The roles are not listed in any catalog<br/>
&nbsp;&nbsp; &nbsp;SELECT * FROM information_schema.xxxxxxx WHERE grantee in (&#39;243683&#39;,&#39;243666&#39;,&#39;243689&#39;,&#39;482499&#39;,&#39;482499&#39;,&#39;17708&#39;);</div>

<div><br/>
Only in pg_auth_members there is a set for each of these roles:<br/>
&nbsp;&nbsp; &nbsp;SELECT * FROM pg_catalog.pg_auth_members WHERE member in (&#39;243683&#39;,&#39;243666&#39;,&#39;243689&#39;,&#39;482499&#39;,&#39;482499&#39;,&#39;17708&#39;);</div>

<div>&nbsp;</div>

<div>What can I do to get rid of these roles and grants?</div>

<div>&nbsp;</div>

<div>Ludwig</div>
</div>
</div>
</div>
</div>
</div></div></body></html>
Continue reading on narkive:
Loading...