Re: [BUGS] BUG #2088: logfiles only readable by instance owner
On Fri, Dec 02, 2005 at 02:11:06PM -0600, Jim C. Nasby wrote: > On Fri, Dec 02, 2005 at 12:59:17PM -0500, Bruce Momjian wrote: > > Dick Snippe wrote: > > > On Fri, Dec 02, 2005 at 12:30:17AM -0500, Tom Lane wrote: > > > > > > > "Dick Snippe" <[EMAIL PROTECTED]> writes: > > > > > setting umask 077 makes sense for the data files, but not per se for > > > > > the > > > > > logfile. > > > > > > > > The logfile typically contains data just as sensitive as the data files, > > > > > > true. > > > > > > > so I disagree. > > > > > > we run postgresql as a database engine behind a number of websites. > > > Typically all the data in the database is public data . It would be very > > > nice if there was a method of letting our developers _read_ the logfile, > > > without giving them _write_ access to the data files. > > > > > > What wrong with making this configurable? > > > > We can't add every features that people ask for or our software would be > > unusable. If your log files recycle at midnight, can't you run a cron > > job to chmod it? I suppose if you can find other users who would like > > to set the mode flags on the file, we can add it. > > Would it be possible to rely on setting umask in the shell instead of > hardcoding 077? I guess that would end up being dependant on different > startup scripts though, so it's probably not a good idea. *mumble* mysql *mumble* $UMASK *mumble* $UMASK_DIR *nuff said* :-) > An alternative is to just use syslog. Or I believe you could use a > log-rotation program that allows you to define permissions and tell > PostgreSQL not to rotate. I used to use syslog, but prefer direct file logging, because it keeps the logfiles closer to the application (e.g. useful when running more than 1 instance on the same host) Using a log rotation program is possible (apache rotatelogs comes to mind), but that would require starting postgresql with something like postmaster | rotatelogs and just hope that rotetelogs doesn't die in the weeks or months that postmaster runs. Also postmaster can't be started as a daemon in this case. The other log rotation option (typically logrotate; e.g. let postgresql log to file and periodically rotate that file by using an external script) may not be an option, because I'm not sure that postgresql closes and reopens its logfiles when it receives a sighup. I think I'll stick to touching the logfiles 5 minutes before postmaster may decide to create them. -- Dick Snippe - een Coordinator Publieke Omroep Internet Services Gebouw 12.401 (peperbus) Sumatralaan 45 Hilversum \ fight war tel +31 35 6774252, email [EMAIL PROTECTED] []() \ not wars ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
[BUGS] BUG #2091: ecpglib.h needs to be updated....
The following bug has been logged online: Bug reference: 2091 Logged by: Chuck Wegrzyn Email address: [EMAIL PROTECTED] PostgreSQL version: 8.1.0 Operating system: Linux Description:ecpglib.h needs to be updated Details: There are a number of places in function prototypes of ECPGdo, ECPGprepare and ECPGdeallocate where 'char *' should be changed to 'const char *'. I am sure the other functions have similar problems. In trying to get my make's to work cleanly (no spurious warnings), I put -fwriteable-string as an option. But this is a deprecated option in gcc, which spits out a complaint. So the only way to stop the madness is to cast the function prototypes correctly. Is this a possibility for the next release (or is it in there already)? ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
[BUGS] BUG #2092: No answer to bug reports 1975 and 2055
The following bug has been logged online: Bug reference: 2092 Logged by: Email address: [EMAIL PROTECTED] PostgreSQL version: ... Operating system: ... Description:No answer to bug reports 1975 and 2055 Details: No answer to bug reports 1975 and 2055 yet. Are you going to fix these issues, or is AIX currently unsupportet? ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [BUGS] BUG #2088: logfiles only readable by instance owner
On Fri, Dec 02, 2005 at 12:59:17PM -0500, Bruce Momjian wrote: > Dick Snippe wrote: > > On Fri, Dec 02, 2005 at 12:30:17AM -0500, Tom Lane wrote: > > > > > "Dick Snippe" <[EMAIL PROTECTED]> writes: > > > > setting umask 077 makes sense for the data files, but not per se for the > > > > logfile. > > > > > > The logfile typically contains data just as sensitive as the data files, > > > > true. > > > > > so I disagree. > > > > we run postgresql as a database engine behind a number of websites. > > Typically all the data in the database is public data . It would be very > > nice if there was a method of letting our developers _read_ the logfile, > > without giving them _write_ access to the data files. > > > > What wrong with making this configurable? > > We can't add every features that people ask for or our software would be > unusable. granted. But hardcoding it is the other extreme. > If your log files recycle at midnight, can't you run a cron > job to chmod it? good idea. Actually, I think touching the file before postgresql creates it might even be better (because when postgres has nothing to log there may not be a logfile to chmod), something along the lines of 55 23 * * * touch $(date --date=tomorrow '+logfile-%Y-%m-%d') > I suppose if you can find other users who would like > to set the mode flags on the file, we can add it. Who knows. Keep in mind that logging to file is a relatively new feature in postgresql. We used to log to syslog, but switched to file logging because of the nice logfile rotation features available in 8.x So, when more people switch from 7.x to 8.x, this feature request might pop up more often. -- Dick Snippe - een Coordinator Publieke Omroep Internet Services Gebouw 12.401 (peperbus) Sumatralaan 45 Hilversum \ fight war tel +31 35 6774252, email [EMAIL PROTECTED] []() \ not wars ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [BUGS] BUG #2091: ecpglib.h needs to be updated....
This will be fixed when we release 8.1.1, which is planned for next week. Before then, you can grab from CVS using the 8.1 tag. --- Chuck Wegrzyn wrote: > > The following bug has been logged online: > > Bug reference: 2091 > Logged by: Chuck Wegrzyn > Email address: [EMAIL PROTECTED] > PostgreSQL version: 8.1.0 > Operating system: Linux > Description:ecpglib.h needs to be updated > Details: > > There are a number of places in function prototypes of ECPGdo, ECPGprepare > and ECPGdeallocate where 'char *' should be changed to 'const char *'. I am > sure the other functions have similar problems. > > In trying to get my make's to work cleanly (no spurious warnings), I put > -fwriteable-string as an option. But this is a deprecated option in gcc, > which spits out a complaint. So the only way to stop the madness is to cast > the function prototypes correctly. Is this a possibility for the next > release (or is it in there already)? > > ---(end of broadcast)--- > TIP 9: In versions below 8.0, the planner will ignore your desire to >choose an index scan if your joining column's datatypes do not >match > -- 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 ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [BUGS] BUG #2056: to_char no long takes time as input?
Patch applied to HEAD and 8.1.X.
---
Tom Lane wrote:
> Bruce Momjian writes:
> > I see your issue with HH/HH24, but I wanted this to work:
>
> > test=> select to_char('14 hours'::interval, 'HH');
> > to_char
> > -
> > 14
> > (1 row)
>
> > With the HH/HH24 change that is going to return 2. Do interval folks
> > know they would have to use HH24 for intervals?
>
> Dunno if they know it, but they always had to do it that way before 8.1,
> so it's not a change to require it. I get this in everything back to
> 7.2:
>
> regression=# select to_char('14 hours'::interval, 'HH');
> to_char
> -
> 02
> (1 row)
>
> regression=# select to_char('14 hours'::interval, 'HH24');
> to_char
> -
> 14
> (1 row)
>
> and I don't see anything especially wrong with that behavior, as long as
> it's documented.
>
> > Should we subtract 12 only if the time is < 24. That also seems
> > strange. Also, a zero hour interval to HH would return 12, not 0.
>
> Offhand I'd vote for making the HH code use a "mod 12" calculation,
> and making AM/PM depend on the value "mod 24". This gives at least a
> slightly sane behavior for intervals > 24 hours.
>
> regards, tom lane
>
> ---(end of broadcast)---
> TIP 4: Have you searched our list archives?
>
>http://archives.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
---(end of broadcast)---
TIP 4: Have you searched our list archives?
http://archives.postgresql.org
Re: [BUGS] BUG #2091: ecpglib.h needs to be updated....
"Chuck Wegrzyn" <[EMAIL PROTECTED]> writes: > There are a number of places in function prototypes of ECPGdo, ECPGprepare > and ECPGdeallocate where 'char *' should be changed to 'const char *'. This was already addressed: http://archives.postgresql.org/pgsql-committers/2005-12/msg8.php Do you see anything missed by that patch? regards, tom lane ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [BUGS] BUG #2092: No answer to bug reports 1975 and 2055
"" <[EMAIL PROTECTED]> writes: > No answer to bug reports 1975 and 2055 yet. Are you going to fix these > issues, or is AIX currently unsupportet? You seem to have a problem with missing SSL in the link, but I don't see why that should be; ecpg certainly tries to link to ssl. You'll need to dig into it a little bit for yourself. You haven't provided enough context to let anyone else reproduce the problem, even if they had AIX which most of us don't --- for example, what configure arguments did you use? regards, tom lane ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [BUGS] BUG #2085: pg_dump incompletely dumps ACLs
David J N Begley <[EMAIL PROTECTED]> writes:
> I have verified that _no_ GRANT/REVOKE commands are dumped for the database,
> and only some GRANT/REVOKE commands are dumped for "language" objects (see
> below);
The latter is not really a bug. Languages don't currently have owners
(ie there is no owner column in pg_language). For ACL-munging purposes
we act as though the bootstrap superuser owns the language, that is,
that userid is shown as the grantor of privileges. But having a
superuser revoke his own privileges is a no-op, because he's a superuser
and the privileges aren't going to be enforced against him anyway. So
the fact that pg_dump doesn't process that part of the ACL isn't very
meaningful.
Sooner or later we may get around to assigning explicit owners to
languages, but it's not a high-priority problem --- AFAICS the lack
of ownership doesn't create any problems worse than these sorts of
corner-case confusions. It'll always be true that superuserdom is
needed to create a PL, and distinguishing one superuser from another
is not a particularly useful activity in the context of permission
checks ...
I fooled around with having pg_dump explicitly treat the language as
being owned by the bootstrap superuser, and think I may apply the patch
now even though it doesn't really matter, because it does clean up the
output a little bit --- instead of
--
-- Name: pltcl; Type: ACL; Schema: -; Owner:
--
REVOKE ALL ON LANGUAGE pltcl FROM PUBLIC;
SET SESSION AUTHORIZATION postgres;
GRANT ALL ON LANGUAGE pltcl TO postgres;
RESET SESSION AUTHORIZATION;
SET SESSION AUTHORIZATION postgres;
GRANT ALL ON LANGUAGE pltcl TO tgl;
RESET SESSION AUTHORIZATION;
I get
--
-- Name: pltcl; Type: ACL; Schema: -; Owner: postgres
--
REVOKE ALL ON LANGUAGE pltcl FROM PUBLIC;
REVOKE ALL ON LANGUAGE pltcl FROM postgres;
GRANT ALL ON LANGUAGE pltcl TO postgres;
GRANT ALL ON LANGUAGE pltcl TO tgl;
for a pg_language ACL of "{postgres=U/postgres,tgl=U/postgres}".
Avoiding the SET SESSION AUTHORIZATIONs seems like a good idea.
regards, tom lane
---(end of broadcast)---
TIP 3: Have you checked our extensive FAQ?
http://www.postgresql.org/docs/faq
Re: [BUGS] BUG #2092: No answer to bug reports 1975 and 2055
Dirk Pirschel <[EMAIL PROTECTED]> writes: >> for example, what configure arguments did you use? > Nothing relevant. > ./configure --prefix=$HOME/software --with-includes=/client/include > --with-libs=/client/lib > [...] > checking whether to build with OpenSSL support... no Well, *something* in your link is trying to pull in OpenSSL. What exactly is in /client/lib ... could it be that there is an existing SSL-dependent installation of libpq in there? In theory the link should find the libpq in ../../../../src/interfaces/libpq not the one in /client/lib, but we've seen bizarre linker search behavior before ... regards, tom lane ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [BUGS] BUG #2092: No answer to bug reports 1975 and 2055
I wrote: > What exactly is in /client/lib ... could it be that there is an existing > SSL-dependent installation of libpq in there? In theory the link should > find the libpq in ../../../../src/interfaces/libpq not the one in > /client/lib, but we've seen bizarre linker search behavior before ... Actually, not so bizarre as all that: looking at your command again, the -L/client/lib is in there twice: gcc -O2 -Wall -Wmissing-prototypes -Wpointer-arith -Winline -Wendif-labels -fno-strict-aliasing -L../../../../src/port -L/client/lib -Wl,-bnoentry -Wl,-H512 -Wl,-bM:SRE -o libecpg.so libecpg.a -Wl,-bE:libecpg.exp -L../pgtypeslib -L../../../../src/interfaces/libpq -L../../../../src/port -L/client/lib -lpgtypes -lpq -lm Assuming there is a libpq in /client/lib, I bet this patch will help. regards, tom lane *** src/Makefile.shlib.orig Fri Oct 28 13:32:22 2005 --- src/Makefile.shlib Sat Dec 3 14:58:32 2005 *** *** 76,81 --- 76,84 # Insert -L from LDFLAGS after any -L already present in SHLIB_LINK SHLIB_LINK := $(filter -L%, $(SHLIB_LINK)) $(filter -L%, $(LDFLAGS)) $(filter-out -L%, $(SHLIB_LINK)) + # Need a -L-free version of LDFLAGS to use in combination with SHLIB_LINK + LDFLAGS_NO_L := $(filter-out -L%, $(LDFLAGS)) + # Default shlib naming convention used by the majority of platforms shlib = lib$(NAME)$(DLSUFFIX).$(SO_MAJOR_VERSION).$(SO_MINOR_VERSION) shlib_major = lib$(NAME)$(DLSUFFIX).$(SO_MAJOR_VERSION) *** *** 154,160 ifeq ($(PORTNAME), hpux) shlib = lib$(NAME)$(DLSUFFIX).$(SO_MAJOR_VERSION) ifeq ($(with_gnu_ld), yes) ! LINK.shared = $(CC) $(LDFLAGS) -shared -Wl,-h -Wl,$(soname) else # can't use the CC-syntax rpath pattern here rpath = --- 157,163 ifeq ($(PORTNAME), hpux) shlib = lib$(NAME)$(DLSUFFIX).$(SO_MAJOR_VERSION) ifeq ($(with_gnu_ld), yes) ! LINK.shared = $(CC) $(LDFLAGS_NO_L) -shared -Wl,-h -Wl,$(soname) else # can't use the CC-syntax rpath pattern here rpath = *** *** 309,315 # AIX case $(shlib): lib$(NAME).a $(MKLDEXPORT) lib$(NAME).a > lib$(NAME)$(EXPSUFF) ! $(COMPILER) $(LDFLAGS) $(LDFLAGS_SL) -o $@ $< -Wl,-bE:lib$(NAME)$(EXPSUFF) $(SHLIB_LINK) endif # PORTNAME == aix --- 312,318 # AIX case $(shlib): lib$(NAME).a $(MKLDEXPORT) lib$(NAME).a > lib$(NAME)$(EXPSUFF) ! $(COMPILER) $(LDFLAGS_NO_L) $(LDFLAGS_SL) -o $@ $< -Wl,-bE:lib$(NAME)$(EXPSUFF) $(SHLIB_LINK) endif # PORTNAME == aix ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [BUGS] BUG #2088: logfiles only readable by instance owner
On Fri, Dec 02, 2005 at 23:30:21 +0100, Dick Snippe <[EMAIL PROTECTED]> wrote: > > Using a log rotation program is possible (apache rotatelogs comes to mind), > but that would require starting postgresql with something like > postmaster | rotatelogs > and just hope that rotetelogs doesn't die in the weeks or months that > postmaster runs. Also postmaster can't be started as a daemon in this case. You can use multilog in DJB's daemontools package to do this. It writes the logfiles publicly readable, so you control access to them via the directory they are contained in. ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [BUGS] BUG #2089: Documentation bug: Triggers in plpythonu
Jozef Behran wrote: > A trigger in plpythonu cannot use the `args' list to obtain the arguments > and does not return the row to be written into the database. Instead the > arguments are placed into a global dictionary called "TD". The row is in > TD["new"] as a dictionary keyed by the names of the fields (the values are > the values of the field). The trigger is supposed to return "SKIP" (or > None?) if it wants the operation to be skipped or modify the TD["new"] to > the actual content to be written into the database and then return "MODIFY". I don't see how is this a bug. It's perfectly documented in the "Trigger functions" section, here: http://www.postgresql.org/docs/8.1/static/plpython-trigger.html If this is not what you meant, please explain. -- Alvaro Herrerahttp://www.CommandPrompt.com/ PostgreSQL Replication, Consulting, Custom Development, 24x7 support ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
[BUGS] date overflows
I'm seeing some date input overflows here. I tested on CVS HEAD without --enable-integer-datetimes and 7.4.9 and 8.0.4 with --enable-integer-datetimes, so it appears to have been around for a while: jurka=# select '23456-01-01'::date; date --- 5290466-07-05 (1 row) jurka=# select '14824-01-01 BC'::date; date 11744398-01-21 (1 row) ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [BUGS] date overflows
On Sat, Dec 03, 2005 at 07:53:23PM -0500, Kris Jurka wrote: > I'm seeing some date input overflows here. Yep, I noticed this a few days ago while looking at another problem. I probably should have started a new thread. http://archives.postgresql.org/pgsql-hackers/2005-11/msg01563.php -- Michael Fuhr ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [BUGS] BUG #2092: No answer to bug reports 1975 and 2055
Hi Tom, * Tom Lane wrote on Sat, 03 Dec 2005 at 13:11 -0500: > * Dirk Pirschel writes: > > > No answer to bug reports 1975 and 2055 yet. Are you going to fix these > > issues, or is AIX currently unsupportet? > > You seem to have a problem with missing SSL in the link, but I don't > see why that should be; ecpg certainly tries to link to ssl. You'll > need to dig into it a little bit for yourself. You haven't provided > enough context to let anyone else reproduce the problem even if they > had AIX which most of us don't The first time, i have posted all configure and make output. I received a "message size too large" from the mailing list server. Unfortunately, the www bug reporting form did not complain about message size, only the mail server does later. The second time i have truncated the output to the compiler errors. > for example, what configure arguments did you use? Nothing relevant. ./configure --prefix=$HOME/software --with-includes=/client/include --with-libs=/client/lib [...] checking whether to build with OpenSSL support... no Any hints where to investigate? -Dirk -- Windoze is bootiful pgpEKpSI1zeNX.pgp Description: PGP signature
Re: [BUGS] BUG #2092: No answer to bug reports 1975 and 2055
Hi Tom, * Tom Lane wrote on Sat, 03 Dec 2005 at 15:02 -0500: > looking at your command again, the -L/client/lib is in there twice: > [...] > Assuming there is a libpq in /client/lib, I bet this patch will help. $ cd postgresql-8.1.0 $ patch -i ~/patch src/Makefile.shlib $ ./configure --prefix=$HOME/software --with-includes=/client/include --with-libs=/client/lib $ make [...] All of PostgreSQL successfully made. Ready to install. $ make install [...] PostgreSQL installation complete. Your patch works fine :-) Thanks! Regards, -Dirk -- "If Microsoft can change and compete on quality, I've won." - Linus Torvalds pgpv14RoQ5F50.pgp Description: PGP signature
Re: [BUGS] BUG #2092: No answer to bug reports 1975 and 2055
Hi Tom, * Tom Lane wrote on Sat, 03 Dec 2005 at 14:34 -0500: > Well, *something* in your link is trying to pull in OpenSSL. > > What exactly is in /client/lib ... could it be that there is an existing > SSL-dependent installation of libpq in there? In theory the link should > find the libpq in ../../../../src/interfaces/libpq not the one in > /client/lib, but we've seen bizarre linker search behavior before ... $ cd /client/lib $ ls -l *libpq* lrwxrwxrwx 1 root system 41 Nov 18 2004 libpq.a -> /sw/rs_aix52/postgresql-7.4.6/lib/libpq.a lrwxrwxrwx 1 root system 42 Nov 18 2004 libpq.so -> /sw/rs_aix52/postgresql-7.4.6/lib/libpq.so lrwxrwxrwx 1 root system 44 Nov 18 2004 libpq.so.3 -> /sw/rs_aix52/postgresql-7.4.6/lib/libpq.so.3 Regards, -Dirk -- Close the windows - the penguin is freezing pgpEwWu817Z62.pgp Description: PGP signature
Re: [BUGS] attislocal value changed with the dump
Is there a TODO here?
---
Tom Lane wrote:
> elein <[EMAIL PROTECTED]> writes:
> > This is the repro with the sql file below.
>
> I looked into this, and the answer is you're doing it to yourself;
> you shouldn't be explicitly re-specifying the defaults for the child
> columns.
>
> > create table answer_numeric (
> > avalue numeric
> > ) inherits (answer_values) ;
> > alter table answer_numeric alter column avid set default
> > nextval('answer_values_avid_seq');
>
> It's unnecessary to have that "alter column set default" command,
> because avid will have inherited the default expression from the parent
> anyway. The reason that setting it changes pg_dump's output is that
> what you are setting is not quite right: the actual default expression
> in the parent is
> nextval('public.answer_values_avid_seq')
> Since that's different, pg_dump concludes that the child's default is
> non-inherited and emits a redefinition of the column.
>
> The reason I didn't see the same behavior in CVS tip is that now that
> we use regclass literals for nextval() arguments, the changed default
> still lists out the same way as the parent's default, and so pg_dump
> thinks it's an inherited default.
>
> It strikes me that there is still a risk here, which is that because
> listing of regclass values is search-path-sensitive, pg_dump could
> come to the wrong conclusion about the inheritance of a default when
> the child is in a different schema than the parent. We could probably
> fix that by comparing adbin strings instead of the reverse-compiled
> expressions to decide if a child default matches its parent or not.
>
> Alternatively, maybe we should add explicit inheritance information
> to pg_attrdef. There's already a proposal to do that for constraints...
>
> regards, tom lane
>
> ---(end of broadcast)---
> TIP 9: In versions below 8.0, the planner will ignore your desire to
>choose an index scan if your joining column's datatypes do not
>match
>
--
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
---(end of broadcast)---
TIP 2: Don't 'kill -9' the postmaster
