Re: [GENERAL] use log_statement to log only SELECTs?
Brian Witt wrote: Hi, I've been looking for a way to use log_statement to log only select statements; is this possible? (I'm using PostgreSQL 8.1.18) I'd like to know if someone tried to read the data back from the database, but don't care to see the inserts or updates since these may have sensitive data like credit card data which I don't want logged in the logs. I really don't even care if the SELECT was successful or not, or what the results of the SELECT were. No, log_statement doesn't allow do that, and I can't think of another option. -- Bruce Momjian br...@momjian.ushttp://momjian.us EnterpriseDB http://enterprisedb.com + If your life is a hard drive, Christ can be your backup. + -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] vacuumdb -z do a reindex?
Hi Scott, On Sat, Nov 28, 2009 at 3:12 PM, Irene Barg ib...@noao.edu wrote: Hi Scott, Scott Marlowe wrote: On Fri, Nov 27, 2009 at 2:17 PM, Irene Barg ib...@noao.edu wrote: I've had a simple update running for over 4 hours now (see results from pg_top below). The sql is: Have you looked in pg_locks and pg_stat_activity? By the time I saw your last post, the 'update' had finished, but it took 8 hours. I loaded a dump of the same database on our test system, then ran the same 'update' statement. Below is all of the stats plus a few others. The test system is 2xAMD Athlon(tm) 64 X2 Dual Core Processor 5600+, 6GB RAM, 2xSATA drives. # pg_locks # metadata=# select * from pg_locks; locktype| database | relation | page | tuple | transactionid | classid | objid | objsubid | transaction | pid | mode | granted ---+--+--+--+---+---+-+---+--+-+---+--+- transactionid | | | | |841483 | | | | 841483 | 12742 | ExclusiveLock| t relation |21800 |21849 | | | | | | | 841478 | 12753 | RowShareLock | t relation |21800 |22086 | | | | | | | 841478 | 12753 | AccessShareLock | t relation |21800 |22054 | | | | | | | 841478 | 12753 | AccessShareLock | t relation |21800 |21847 | | | | | | | 841478 | 12753 | AccessShareLock | t relation |21800 |22064 | | | | | | | 841478 | 12753 | AccessShareLock | t relation |21800 |22088 | | | | | | | 841478 | 12753 | AccessShareLock | t relation |21800 |22090 | | | | | | | 841478 | 12753 | AccessShareLock | t relation |21800 |22134 | | | | | | | 841478 | 12753 | AccessShareLock | t relation |21800 |21873 | | | | | | | 841478 | 12753 | AccessShareLock | t relation |21800 |10328 | | | | | | | 841483 | 12742 | AccessShareLock | t relation |21800 |22092 | | | | | | | 841478 | 12753 | AccessShareLock | t relation |21800 |22094 | | | | | | | 841478 | 12753 | AccessShareLock | t relation |21800 |22136 | | | | | | | 841478 | 12753 | AccessShareLock | t relation |21800 |22062 | | | | | | | 841478 | 12753 | AccessShareLock | t transactionid | | | | |841478 | | | | 841478 | 12753 | ExclusiveLock| t relation |21800 |21851 | | | | | | | 841478 | 12753 | RowExclusiveLock | t relation |21800 |22066 | | | | | | | 841478 | 12753 | AccessShareLock | t relation |21800 |21892 | | | | | | | 841478 | 12753 | AccessShareLock | t relation |21800 |21892 | | | | | | | 841478 | 12753 | RowExclusiveLock | t relation |21800 |22050 | | | | | | | 841478 | 12753 | AccessShareLock | t relation |21800 |21915 | | | | | | | 841478 | 12753 | AccessShareLock | t relation |21800 |22056 | | | | | | | 841478 | 12753 | RowExclusiveLock | t relation |21800 |21837 | | | | | | | 841478 | 12753 | AccessShareLock | t relation |21800 |22048 | | | | | | | 841478 | 12753 | AccessShareLock | t relation |21800 |22135 | | | | | | | 841478 | 12753 | AccessShareLock | t relation |21800 |22060 | | | | | | | 841478 | 12753 | AccessShareLock | t relation |21800 |22058 | | | | | | | 841478 |
[GENERAL] duplicating a schema
I need to create a new schema with all the content in an existing one, just with a new name. The way I've found is: - make a backup - load it in a dev box - rename the schema - make a backup of the new schema - restore the new schema on the original DB. Is there a more efficient approach? -- Ivan Sergio Borgonovo http://www.webthatworks.it -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] Postgresql8.4 install breaks Evolution on Ubuntu 9.10
On 28/11/2009 7:10 PM, Magnus Hagander wrote:
On Sat, Nov 28, 2009 at 11:53, Leonardo Camargo
camargoleona...@gmail.com wrote:
Hi all,
I'm wondering if someone here know how to go about fixing this problem that
apparently affects everyone who manually install Postgresql8.4 on Ubuntu
Karmic(9.10).
Postgres installation seems to mess with something that renders other
applications unable to function. For instance my problem is with Evolution
Mail. This is the output I started getting after installing postgres:
evolution: /opt/PostgreSQL/8.4/lib/libxml2.so.2: no version information
available (required by evolution)
This looks like an install from the 1-clicks, right? It looks to me
that it's not karmic-compatible - try installing the debian packages
instead (should be a simple apt-get install postgresql-8.4 - it's
included by default in Karmic IIRC). I've done that many times without
any issues like this.
It's not just incompatible - it's a very poorly behaved installer. It's
apparently adding /opt/PostgreSQL/8.4/lib/ to /etc/ld.so.conf or
modifying the global LD_LIBRARY_PATH.
*BAD IDEA*
If you install any libraries not private to the application *and* very
carefully versioned by soname, you shouldn't be making them visible to
the system linker. If you do, things like this happen. This is a
particularly apalling mistake with such common libraries as libxml2,
which are typically not only used by other apps, but provided as part of
the core packages in the system.
If you need to provide your own versions of such libraries, keep them in
a private directory that's never added to the system linker path.
Executables that need access to them should use rpath linking to access
them if at all possible.
If for some reason you won't or can't use rpath linking, which was
designed to solve this problem, you should use wrapper scripts instead.
Eg, if psql required access to libxml2, it could be wrapped as:
#!/bin/sh
PGDIR=/opt/PostgreSQL/8.4/
LD_LIBRARY_PATH=${PGDIR}/lib:${LD_LIBRARY_PATH}\
${PGDIR}/bin.real/psql #@
where bin.real/psql is the real psql binary, which does not appear on
the PATH. Note that the above exactly preserves all command line args,
and will handle spaces in paths etc without issues.
Another alternative if rpath linking is for some reason rejected and
wrapper scripts are considered (understandably) too ugly is to build
your own versions of the libraries you need with different names that'll
be completely unique, eg pg841libxml2.so . You'll run into some *ugly*
global static data issues this way, though, if other code (possibly user
or plugin code) loads a system version of the same library and it has
any global statics.
So - just use rpath linkage for your added libraries, storing them in a
private directory. Please.
(IMO this is about the only area Windows has a significant advantage in
linking by the way - it loads shared libraries from the directory in
which a binary resides preferentially to all others. There'd be security
issues doing so on *nix, but I'm pretty sure they could be worked around
with appropriate ownership and permissions checks).
--
Craig Ringer
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] Time zone 'GMT+8'
there are 3 terms which refer to GMT GMT in the UK Zulu time for aviators UTC for Scientific measurements UTC is now replacing 'Zulu' and 'GMT' for 0 time references http://wwp.greenwichmeantime.com/info/zulu.htm Martin Gainty __ Verzicht und Vertraulichkeitanmerkung/Note de déni et de confidentialité Diese Nachricht ist vertraulich. Sollten Sie nicht der vorgesehene Empfaenger sein, so bitten wir hoeflich um eine Mitteilung. Jede unbefugte Weiterleitung oder Fertigung einer Kopie ist unzulaessig. Diese Nachricht dient lediglich dem Austausch von Informationen und entfaltet keine rechtliche Bindungswirkung. Aufgrund der leichten Manipulierbarkeit von E-Mails koennen wir keine Haftung fuer den Inhalt uebernehmen. Ce message est confidentiel et peut être privilégié. Si vous n'êtes pas le destinataire prévu, nous te demandons avec bonté que pour satisfaire informez l'expéditeur. N'importe quelle diffusion non autorisée ou la copie de ceci est interdite. Ce message sert à l'information seulement et n'aura pas n'importe quel effet légalement obligatoire. Étant donné que les email peuvent facilement être sujets à la manipulation, nous ne pouvons accepter aucune responsabilité pour le contenu fourni. Date: Sun, 29 Nov 2009 15:08:01 +0800 From: seil...@so-net.net.tw To: pgsql-general@postgresql.org Subject: [GENERAL] Time zone 'GMT+8' The target pgsql is compiled from 8.4rc1. 'GMT+8' can be found in installed binary file .../share/postgresql/timezone/Etc/GMT+8. This is the recorded script: -BEGIN record-- db1=# select now(); now --- 2009-11-29 14:44:37.322414+08 (1 row) db1=# set timezone to 'GMT+8'; SET db1=# select now(); now --- 2009-11-28 22:45:03.397545-08 (1 row) db1=# set timezone to GMT-8'; SET db1=# select now(); now --- 2009-11-29 14:45:39.160701+08 (1 row) db1=# set timezone to '0'; SET db1=# select now(); now --- 2009-11-29 06:45:54.347482+00 (1 row) -END record-- I thought time zone 'GMT+8' was '8' or UTC+8, and 'GMT-8' was '-8' or UTC-8. Does the original time zone settings shipped with source have special interpretation that is different from my understanding? Regards, CN -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general _ Hotmail: Trusted email with powerful SPAM protection. http://clk.atdmt.com/GBL/go/177141665/direct/01/
Re: [GENERAL] [BUGS] BUG #5218: Easy strategic feature requests
On 29/11/2009 6:34 AM, Russell Wallace wrote: (There wasn't a separate form for feature requests, so I'm assuming that like most projects, this one files them together with bugs, please let me know if that is not the case.) http://wiki.postgresql.org/wiki/Todo ... but it's generally preferred to discuss the issue on the -general mailing list. I've replied to that list, where discussion will carry on. Please don't respond to the post on -bugs. Can you make Show Databases, Show Tables and Describe (table) work the way they do in MySQL? This would make things easier for newbies and would also make it easier to port code from MySQL; they would only need to be syntax sugar for the corresponding information schema queries, so it would probably only take a few lines of code, and would improve PostgreSQL's competitive position versus MySQL out of all proportion to the apparent significance of these features. I'm not sure it's as easy as you think in terms of backend implementation (and I suspect it'd be uglier than would be desirable too), but I do agree that something like that behaviour might be a useful helping hand for migrating users. Rather than implementing SHOW (blah) as wrappers for selects from views in the backend, though, IMO it'd make a lot more sense to provide minimal stubs that raised an exception telling the user the right way to do it. SHOW TABLES is a MySQL-specific command that isn't part of the SQL standard and isn't used by other databases. Please query the SQL-standard INFORMATION_SCHEMA instead, or for interactive work use psql's \d command. etc. Opinions, anybody? It would be nice if Use (database) could also be made to work, but I'm guessing this would not be just a few lines of code. It can't be made to work *cleanly*. What MySQL calls a database, PostgreSQL calls a schema within a single database. PostgreSQL has a schema search path that it uses to find objects when they are mentioned with unqualified names. Modifying this search path is roughly equivalent to USE-ing a database in MySQL. This is one of those things where you've just got to learn the right way to do it. In theory, PostgreSQL could be reworked to support changing databases within a connection. In practice ... eek. From my minmimal understanding of the codebase, enabling a backend to switch databases would require a huge overhaul of authentication, backend startup and management, shared memory management, and more. It'd make more sense to let a backend hand a TCP/IP socket over to a newly created backend on a different database. I don't know if that's reasonable or practical. I'm also not sure it makes sense to do. You see, in Pg, if you're switching databases a lot this is a hint you're doing something wrong - you should be using separate schema in the same database instead. The backend could implement USE as a dummy command that raises an exception, as I suggested for other MySQL-isms, saying something like: USE database is a MySQL-specific command that does not make sense in PostgreSQL. Please see mysql-use.html in the PostgreSQL documentation. The docs file in question would explain schema-vs-database, psql's \c command, etc. What would be easy and still useful, however, would be if it could return a specific error message: you can't do this in Postgres, you always need to supply a database name on connection Pg (well, libpq to be more accurate) defaults to connecting to a db with the same name as the running user if nothing else is specified. -- Craig Ringer -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] [BUGS] BUG #5218: Easy strategic feature requests
On Sun, Nov 29, 2009 at 1:57 PM, Craig Ringer cr...@postnewspapers.com.au wrote: Rather than implementing SHOW (blah) as wrappers for selects from views in the backend, though, IMO it'd make a lot more sense to provide minimal stubs that raised an exception telling the user the right way to do it. SHOW TABLES is a MySQL-specific command that isn't part of the SQL standard and isn't used by other databases. Please query the SQL-standard INFORMATION_SCHEMA instead, or for interactive work use psql's \d command. And hopefully a URL to a page that gives more details on INFORMATION_SCHEMA, including the specific commands for the equivalent of SHOW TABLES etc? Okay, fair enough, that would still provide most of the benefit. In theory, PostgreSQL could be reworked to support changing databases within a connection. In practice ... eek. From my minmimal understanding of the codebase, enabling a backend to switch databases would require a huge overhaul of authentication, backend startup and management, shared memory management, and more. eek indeed! Right, it's definitely not worth that sort of headache. An error message explaining the situation would provide much of the benefit for orders of magnitude less cost. -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] Time zone 'GMT+8'
silly silly8...@gmail.com writes: From http://www.postgresql.org/docs/current/static/datatype-datetime.html#DATATYPE-TIMEZONES Another issue to keep in mind is that in POSIX time zone names, positive offsets are used for locations west of Greenwich. Yeah, we're caught between two incompatible conventions :-(. I suggest reading the whole section linked to above, it should make things clearer. regards, tom lane -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] Postgresql8.4 install breaks Evolution on Ubuntu 9.10
So - just use rpath linkage for your added libraries, storing them in a private directory. Please. Argh. It's worse than I hoped. Libraries the One-Click installer tramples all over include: libxml2 libssl libcrypto libreadline libtermcap libuuid ... all of which have the same names and in some cases soversions that they're likely to have in the OS packages. As libpq.so.5 is also added to the linker path, if a user has a distro-packaged version of PostgreSQL which has the same soversion of libpq then the distro-packaged psql etc is also likely to use the one-click install's libpq, leading to the potential for all sorts of exciting breakage if they've been built with different options. An incomplete list of binaries clearly affected by library conflict issues such as the libxml one the OP reported is, as checked in my Ubuntu 9.04 install: /usr/bin/amstex /usr/bin/bonobo-browser /usr/bin/bug-buddy /usr/bin/compiz.real /usr/bin/devhelp /usr/bin/dvd95 /usr/bin/dwell-click-applet /usr/bin/editor /usr/bin/ekiga /usr/bin/eog /usr/bin/etex /usr/bin/eview /usr/bin/evim /usr/bin/evolution /usr/bin/evolution-addressbook-export /usr/bin/ex /usr/bin/gedit /usr/bin/gnome-about-me /usr/bin/gnome-appearance-properties /usr/bin/gnome-default-applications-properties /usr/bin/gnome-desktop-item-edit /usr/bin/gnome-help /usr/bin/gnome-keyboard-properties /usr/bin/gnome-open /usr/bin/gnome-panel /usr/bin/gnome-phone-manager /usr/bin/gnome-pilot-make-password /usr/bin/gnome-text-editor /usr/bin/gnomevfs-cat /usr/bin/gnomevfs-copy /usr/bin/gnomevfs-df /usr/bin/gnomevfs-info /usr/bin/gnomevfs-ls /usr/bin/gnomevfs-mkdir /usr/bin/gnomevfs-monitor /usr/bin/gnomevfs-mv /usr/bin/gnomevfs-rm /usr/bin/gnome-volume-properties /usr/bin/gpilot-applet /usr/bin/gpilotd /usr/bin/gpilotd-control-applet /usr/bin/gpilotd-session-wrapper /usr/bin/gpilot-install-file /usr/bin/grip /usr/bin/gthumb /usr/bin/gview /usr/bin/gvim /usr/bin/gvimdiff /usr/bin/inkscape /usr/bin/inkview /usr/bin/jadetex /usr/bin/latex /usr/bin/meinproc4 /usr/bin/msgattrib /usr/bin/msgcat /usr/bin/msgcmp /usr/bin/msgcomm /usr/bin/msgconv /usr/bin/msgen /usr/bin/msgexec /usr/bin/msgfilter /usr/bin/msgfmt /usr/bin/msggrep /usr/bin/msginit /usr/bin/msgmerge /usr/bin/msgunfmt /usr/bin/msguniq /usr/bin/nautilus /usr/bin/panel-test-applets /usr/bin/pdfetex /usr/bin/pdffonts /usr/bin/pdfimages /usr/bin/pdfinfo /usr/bin/pdfjadetex /usr/bin/pdflatex /usr/bin/pdftex /usr/bin/pdftoabw /usr/bin/pdftohtml /usr/bin/pdftoppm /usr/bin/pdftops /usr/bin/pdftotext /usr/bin/php5-cgi /usr/bin/php-cgi /usr/bin/pidgin /usr/bin/pointer-capture-applet /usr/bin/polkit-gnome-authorization /usr/bin/recode-sr-latin /usr/bin/rgview /usr/bin/rgvim /usr/bin/rhythmbox /usr/bin/rview /usr/bin/rvim /usr/bin/seahorse /usr/bin/seahorse-daemon /usr/bin/test-moniker /usr/bin/tracker-search-tool /usr/bin/vi /usr/bin/view /usr/bin/vim /usr/bin/vimdiff /usr/bin/vim.gnome /usr/bin/vinagre /usr/bin/vino-preferences /usr/bin/virsh /usr/bin/virt-viewer /usr/bin/xfce4-keyboard-settings /usr/bin/xfce4-settings-helper /usr/bin/xgettext /usr/bin/xmlcatalog /usr/bin/xmllint /usr/bin/yelp Other distros will experience different breakage. On Ubuntu 9.10, for example, the standard readline soversion is .5.2 so the libreadline.so.4 bundled in the oc installer won't break users of the distro-packaged libreadline. Ditto libssl and libcrypto (oc: .5.2 ; distro: .0.9.8 ). This needs really urgent attention. Step 1 is probably to rebuild the installer using libraries where everything has been given custom soversions; next step is to use rpath linkage to solve the problem properly. -- Craig Ringe -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] Postgresql8.4 install breaks Evolution on Ubuntu 9.10
Libraries the One-Click installer tramples all over include: libxml2 libssl libcrypto libreadline libtermcap libuuid Apart from libxml2 (which is now being fixed) all other libraries you mentioned , dint get installed (or copied) to the PGHOME/lib directory if the same name library already present in the system (/lib and /usr/lib). ... all of which have the same names and in some cases soversions that they're likely to have in the OS packages. As libpq.so.5 is also added to the linker path, if a user has a distro-packaged version of PostgreSQL which has the same soversion of libpq then the distro-packaged psql etc is also likely to use the one-click install's libpq, leading to the potential for all sorts of exciting breakage if they've been built with different options. An incomplete list of binaries clearly affected by library conflict issues such as the libxml one the OP reported is, as checked in my Ubuntu 9.04 install: /usr/bin/amstex /usr/bin/bonobo-browser /usr/bin/bug-buddy /usr/bin/compiz.real /usr/bin/devhelp /usr/bin/dvd95 /usr/bin/dwell-click-applet /usr/bin/editor /usr/bin/ekiga /usr/bin/eog /usr/bin/etex /usr/bin/eview /usr/bin/evim /usr/bin/evolution /usr/bin/evolution-addressbook-export /usr/bin/ex /usr/bin/gedit /usr/bin/gnome-about-me /usr/bin/gnome-appearance-properties /usr/bin/gnome-default-applications-properties /usr/bin/gnome-desktop-item-edit /usr/bin/gnome-help /usr/bin/gnome-keyboard-properties /usr/bin/gnome-open /usr/bin/gnome-panel /usr/bin/gnome-phone-manager /usr/bin/gnome-pilot-make-password /usr/bin/gnome-text-editor /usr/bin/gnomevfs-cat /usr/bin/gnomevfs-copy /usr/bin/gnomevfs-df /usr/bin/gnomevfs-info /usr/bin/gnomevfs-ls /usr/bin/gnomevfs-mkdir /usr/bin/gnomevfs-monitor /usr/bin/gnomevfs-mv /usr/bin/gnomevfs-rm /usr/bin/gnome-volume-properties /usr/bin/gpilot-applet /usr/bin/gpilotd /usr/bin/gpilotd-control-applet /usr/bin/gpilotd-session-wrapper /usr/bin/gpilot-install-file /usr/bin/grip /usr/bin/gthumb /usr/bin/gview /usr/bin/gvim /usr/bin/gvimdiff /usr/bin/inkscape /usr/bin/inkview /usr/bin/jadetex /usr/bin/latex /usr/bin/meinproc4 /usr/bin/msgattrib /usr/bin/msgcat /usr/bin/msgcmp /usr/bin/msgcomm /usr/bin/msgconv /usr/bin/msgen /usr/bin/msgexec /usr/bin/msgfilter /usr/bin/msgfmt /usr/bin/msggrep /usr/bin/msginit /usr/bin/msgmerge /usr/bin/msgunfmt /usr/bin/msguniq /usr/bin/nautilus /usr/bin/panel-test-applets /usr/bin/pdfetex /usr/bin/pdffonts /usr/bin/pdfimages /usr/bin/pdfinfo /usr/bin/pdfjadetex /usr/bin/pdflatex /usr/bin/pdftex /usr/bin/pdftoabw /usr/bin/pdftohtml /usr/bin/pdftoppm /usr/bin/pdftops /usr/bin/pdftotext /usr/bin/php5-cgi /usr/bin/php-cgi /usr/bin/pidgin /usr/bin/pointer-capture-applet /usr/bin/polkit-gnome-authorization /usr/bin/recode-sr-latin /usr/bin/rgview /usr/bin/rgvim /usr/bin/rhythmbox /usr/bin/rview /usr/bin/rvim /usr/bin/seahorse /usr/bin/seahorse-daemon /usr/bin/test-moniker /usr/bin/tracker-search-tool /usr/bin/vi /usr/bin/view /usr/bin/vim /usr/bin/vimdiff /usr/bin/vim.gnome /usr/bin/vinagre /usr/bin/vino-preferences /usr/bin/virsh /usr/bin/virt-viewer /usr/bin/xfce4-keyboard-settings /usr/bin/xfce4-settings-helper /usr/bin/xgettext /usr/bin/xmlcatalog /usr/bin/xmllint /usr/bin/yelp Other distros will experience different breakage. On Ubuntu 9.10, for example, the standard readline soversion is .5.2 so the libreadline.so.4 bundled in the oc installer won't break users of the distro-packaged libreadline. Ditto libssl and libcrypto (oc: .5.2 ; distro: .0.9.8 ). This needs really urgent attention. Step 1 is probably to rebuild the installer using libraries where everything has been given custom soversions; next step is to use rpath linkage to solve the problem properly. -- Craig Ringe -- Regards, Sachin Srivastava EnterpriseDB http://www.enterprisedb.com, the Enterprise Postgres http://www.enterprisedb.com company.
Re: [GENERAL] Postgresql8.4 install breaks Evolution on Ubuntu 9.10
On Sun, Nov 29, 2009 at 16:18, Sachin Srivastava sachin.srivast...@enterprisedb.com wrote: Libraries the One-Click installer tramples all over include: libxml2 libssl libcrypto libreadline libtermcap libuuid Apart from libxml2 (which is now being fixed) all other libraries you mentioned , dint get installed (or copied) to the PGHOME/lib directory if the same name library already present in the system (/lib and /usr/lib). What happens if they are installed by the packaging system later on? Won't that cause a conflict then? -- Magnus Hagander Me: http://www.hagander.net/ Work: http://www.redpill-linpro.com/ -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] Postgresql8.4 install breaks Evolution on Ubuntu 9.10
On Sun, Nov 29, 2009 at 4:17 PM, Magnus Hagander mag...@hagander.net wrote: On Sun, Nov 29, 2009 at 16:18, Sachin Srivastava sachin.srivast...@enterprisedb.com wrote: Apart from libxml2 (which is now being fixed) all other libraries you mentioned , dint get installed (or copied) to the PGHOME/lib directory if the same name library already present in the system (/lib and /usr/lib). What happens if they are installed by the packaging system later on? Won't that cause a conflict then? Or if the user later uninstalls those libraries -- which can happen automatically when nothing in the packaging system depends on them any longer. But i don't see what the conflict is if they're installed in PGHOME/lib as long as the installer doesn't fiddle with /etc/ld.so.conf or set any environment variables. The binaries should just be built with an rpath pointing to that directory or ship with a startup script which puts that directory in LD_LIBRARY_PATH. Whether you want to append, leaving the system directories ahead of the one-click installed libraries, or prepend so the linker always uses your libraries would depend on how you want it to behave. Setting rpath is equivalent to prepending I believe. -- greg -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] 8.45.1 on mac - Plist problems
PGDATA is /usr/local/postgres/data But you pass /usr/local/postgresql-8.4.1/bin as the data directory? In the future, two things to try: - Examine pg's logfile; would probably have alerted you to the problem. - Look in the console for error messages from launchd (and add keyDebug/keytrue/ to the plist); would probably not have helped you in this case. -- Scott Ribe scott_r...@killerbytes.com http://www.killerbytes.com/ (303) 722-0567 voice -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
[GENERAL] Help, server cannot start anymore
Hi, i recently migrated from mysql to postgres and i might have made a no-no in that process. bascily i want/need a selfcontained folder \database where i can zip that directory move it anywhere, unzip and carry on my busniess with no dependencies. Postgres presented me with a challenge in this regard as i am not allowed to run it from a admin account (yes i know i know, still..), alas i followed the steps here http://charupload.wordpress.com/2008/07/26/manual-installation-of-postgresql-under-administrator-user-in-windows/ initdb -D c:\postgresql\data pg_ctl.exe start -D c:\postgresql\data Fantastic, i was up and running, migrated my data and continued developent .. the server have stopped on occasion on its own for some reason i cannot pinpoint, but now it is totally unable to start up, here is the recent entries from the server log. LOG: could not open directory G:/mysql/pgsql/share/timezone: No such file or directory LOG: could not open directory G:/mysql/pgsql/share/timezone: No such file or directory FATAL: could not select a suitable default timezone DETAIL: It appears that your GMT time zone uses leap seconds. PostgreSQL does not support leap seconds. LOG: could not open directory G:/mysql/pgsql/share/timezone: No such file or directory LOG: could not open directory G:/mysql/pgsql/share/timezone: No such file or directory FATAL: could not select a suitable default timezone DETAIL: It appears that your GMT time zone uses leap seconds. PostgreSQL does not support leap seconds. LOG: could not open directory G:/mysql/pgsql/share/timezone: No such file or directory LOG: could not open directory G:/mysql/pgsql/share/timezone: No such file or directory FATAL: could not select a suitable default timezone DETAIL: It appears that your GMT time zone uses leap seconds. PostgreSQL does not support leap seconds. Dont put anything onto the g:/mysql directory, inhere mysql and postgres lives side by side... I understand the error, the directory is NOT there ... but this thing was running happily a few days ago .. what went wrong ??? -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
[GENERAL] Re: vacuumdb: vacuuming of database xy failed: PANIC: corrupted item pointer: 19227
What is this? PANIC: corrupted item lengths: total 8192, available space 8068 -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] Help, server cannot start anymore
Solved. For now. - LOG: could not open directory G:/mysql/pgsql/share/timezone: No such file or directory I copied this folder from another postgres installation i did some months back on another system and wham, up and running agan. weird. -- On Sun, Nov 29, 2009 at 11:27 AM, CyTG cytg@gmail.com wrote: Hi, i recently migrated from mysql to postgres and i might have made a no-no in that process. bascily i want/need a selfcontained folder \database where i can zip that directory move it anywhere, unzip and carry on my busniess with no dependencies. Postgres presented me with a challenge in this regard as i am not allowed to run it from a admin account (yes i know i know, still..), alas i followed the steps here http://charupload.wordpress.com/2008/07/26/manual-installation-of-postgresql-under-administrator-user-in-windows/ initdb -D c:\postgresql\data pg_ctl.exe start -D c:\postgresql\data Fantastic, i was up and running, migrated my data and continued developent .. the server have stopped on occasion on its own for some reason i cannot pinpoint, but now it is totally unable to start up, here is the recent entries from the server log. LOG: could not open directory G:/mysql/pgsql/share/timezone: No such file or directory LOG: could not open directory G:/mysql/pgsql/share/timezone: No such file or directory FATAL: could not select a suitable default timezone DETAIL: It appears that your GMT time zone uses leap seconds. PostgreSQL does not support leap seconds. LOG: could not open directory G:/mysql/pgsql/share/timezone: No such file or directory LOG: could not open directory G:/mysql/pgsql/share/timezone: No such file or directory FATAL: could not select a suitable default timezone DETAIL: It appears that your GMT time zone uses leap seconds. PostgreSQL does not support leap seconds. LOG: could not open directory G:/mysql/pgsql/share/timezone: No such file or directory LOG: could not open directory G:/mysql/pgsql/share/timezone: No such file or directory FATAL: could not select a suitable default timezone DETAIL: It appears that your GMT time zone uses leap seconds. PostgreSQL does not support leap seconds. Dont put anything onto the g:/mysql directory, inhere mysql and postgres lives side by side... I understand the error, the directory is NOT there ... but this thing was running happily a few days ago .. what went wrong ??? -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] Date with time zone
On Sat, Nov 28, 2009 at 8:55 PM, Adrian Klaver akla...@comcast.net wrote: On Saturday 28 November 2009 3:41:42 pm Eduardo Piombino wrote: Hi Adrian, thanks for your answer. I see current criteria and all the SQL-standard compliance policy, but wouldn't it still make sense to be able to store a date reference, along with a time zone reference? Wouldn't it be useful, wouldn't it be elegant? If i just want to store a reference to Dec 19th without adding an innecesary reference to a dummy time, like 00:00:00 (for time zone tracking's sake), wouldn't it be elegant to be able to say Dec 19th (GMT-3) ? The problem arises around the dates when DST starts and ends. For instance here, Washington State USA, Nov 1st was the change over date. This occurred at 2:00 AM in the morning, so on Nov 1st we where in two time zones PDT then PST. Without a reference to time it makes it hard to keep track. For the sake of simplicity I would like to leave the DST's modifications off the discussion, just for now. Considering a fixed setup, where every country has a fixed time zone (or many, but fixed), I will try to make my point. If I we can all agree on the point at a fixed setup, I'm more than willing to get into a more complex scenario and just then introduce summer times, etc. If you are ok with it. On the other hand, I don't really see the reasons of this statement: Although the date type *cannot *have an associated time zone, the time type can. Why is this so? I'm no guru, but I don't see any obvious technical impossibility to do so. Is this so just because SQL standard says so? Can it be possible that SQL standard is a little short on this kind of need? I will let the SQL gurus answer this one. Again, of course I can always use a timestamp set to 00:00:00 just to use its time zone tracking capabilities, but It is just as dirty as any other patch. As stated above time zones only have meaning with respect to date and time together. I'm not quite sure about this. For example, if you want to say I will accept bets until 6 o'clock (London Time), every day. How does that time reference need to be tied to a specific date?. It's just a reference to a time in the day, by itself. Plus a time zone, because 6 o'clock by itself is also not sufficient, it still needs a time zone reference. It's also not a timestamp, nor a date, its just a time (with time zone tracking capabilities). And that's where I see that time with time zone is a good, and the one data type to use, IMO. A date is a date, and a timestamp is a timestamp, and both, used independently, should be able to keep track of its associated time zone, I think. Am I wrong on this? Apart from what SQL Standard may say, for instance. I would suggest searching the archives. There has been discussions in the past about 'tagged' fields that would track timezones independent of a time/date/timestamp field. I will, thanks for the reference. -- Adrian Klaver akla...@comcast.net Going back to the date with datetime, follow me with this reasoning: If you consider a specific date (in a specific time zone) defined as a specific starting point in time (absolute and universal), and a specific ending point in time, one could say that a date is a period of time ranging from 00:00 hs to 23:59:59. (just as some other member list suggested, with which I totally agree), both times tied to a specific time zone. One could then say that, Dec 19th (London Time) goes from Dec 19th 00:00:00 (London Time) to Dec 19th 23:59:59.9... (London Time). So, making a reference to Dec 19th (London Time) would make sense as it refers to a specific absolute time frame, or range. This range, could be (or not, but that is not the point) useful for some practical situations, but the impossibility to be able to state a reference to a date, without recurring to some tweaks or patches is sthing that at the least, bugs me a little. For instance, if you have a server and you want to tell someone it will be up tomorrow, all day long, with that single reference, your buddy knows exactly that it will be up from 00:00:00 of that day (Your Local Time), to 23:59:59. that day (also in your local time), at least in theory, according to what u said. And tomorrow in that sentence, works as an implicit reference to a day, with a time zone, which combined, references a specific absolute time range. Maybe another thing that goes against this, is that there would seem to be no reasonable applications for that data type, but I recall having the need for this once, and I think that was the first time I would have liked to be able to specify a date along with a time zone. But again, apart from the possible applications, I still think it is a logic data type to have. To be able to reference a specific date, in a specific country, or time zone. Another example that comes into my mind is that you may have some coupons, that u
Re: [GENERAL] Date with time zone
On Sunday 29 November 2009 2:38:43 pm Eduardo Piombino wrote: On Sat, Nov 28, 2009 at 8:55 PM, Adrian Klaver akla...@comcast.net wrote: On Saturday 28 November 2009 3:41:42 pm Eduardo Piombino wrote: Hi Adrian, thanks for your answer. I see current criteria and all the SQL-standard compliance policy, but wouldn't it still make sense to be able to store a date reference, along with a time zone reference? Wouldn't it be useful, wouldn't it be elegant? If i just want to store a reference to Dec 19th without adding an innecesary reference to a dummy time, like 00:00:00 (for time zone tracking's sake), wouldn't it be elegant to be able to say Dec 19th (GMT-3) ? The problem arises around the dates when DST starts and ends. For instance here, Washington State USA, Nov 1st was the change over date. This occurred at 2:00 AM in the morning, so on Nov 1st we where in two time zones PDT then PST. Without a reference to time it makes it hard to keep track. For the sake of simplicity I would like to leave the DST's modifications off the discussion, just for now. Considering a fixed setup, where every country has a fixed time zone (or many, but fixed), I will try to make my point. If I we can all agree on the point at a fixed setup, I'm more than willing to get into a more complex scenario and just then introduce summer times, etc. If you are ok with it. Not really because such an animal does not exist AFAIK. If does it is the exception. As stated above time zones only have meaning with respect to date and time together. I'm not quite sure about this. For example, if you want to say I will accept bets until 6 o'clock (London Time), every day. How does that time reference need to be tied to a specific date?. It's just a reference to a time in the day, by itself. Plus a time zone, because 6 o'clock by itself is also not sufficient, it still needs a time zone reference. It's also not a timestamp, nor a date, its just a time (with time zone tracking capabilities). And that's where I see that time with time zone is a good, and the one data type to use, IMO. Because this assumes you are in the London time zone. If you are placing bets from outside the London time zone you need to be aware of the time offset, because the local time you can place the bet is going to change based on the time zone in effect. To know what time zone is in effect you need to know the date. Going back to the date with datetime, follow me with this reasoning: If you consider a specific date (in a specific time zone) defined as a specific starting point in time (absolute and universal), and a specific ending point in time, one could say that a date is a period of time ranging from 00:00 hs to 23:59:59. (just as some other member list suggested, with which I totally agree), both times tied to a specific time zone. One could then say that, Dec 19th (London Time) goes from Dec 19th 00:00:00 (London Time) to Dec 19th 23:59:59.9... (London Time). So, making a reference to Dec 19th (London Time) would make sense as it refers to a specific absolute time frame, or range. This range, could be (or not, but that is not the point) useful for some practical situations, but the impossibility to be able to state a reference to a date, without recurring to some tweaks or patches is sthing that at the least, bugs me a little. You can referr to date just not with a time zone. For instance, if you have a server and you want to tell someone it will be up tomorrow, all day long, with that single reference, your buddy knows exactly that it will be up from 00:00:00 of that day (Your Local Time), to 23:59:59. that day (also in your local time), at least in theory, according to what u said. Yes, unless it is on a DST transition date. Then it up from local_timezone1 from time1 to time2 and then from local_timezone2 from time1 to time2. And tomorrow in that sentence, works as an implicit reference to a day, with a time zone, which combined, references a specific absolute time range. Now you are getting deeper. A day has different meanings. It can be an arbitrarily anchored 24 hr period or it can be midnight to midnight. So absolute is relative :) Maybe another thing that goes against this, is that there would seem to be no reasonable applications for that data type, but I recall having the need for this once, and I think that was the first time I would have liked to be able to specify a date along with a time zone. But again, apart from the possible applications, I still think it is a logic data type to have. To be able to reference a specific date, in a specific country, or time zone. Again you are assuming that time outside of UTC is more fixed than it is. See here for an educational experience: http://www.twinsun.com/tz/tz-link.htm As a conclusion to all this, sorry guys if I am boring you ! I would almost conclude that: We have
Re: [GENERAL] Postgresql8.4 install breaks Evolution on Ubuntu 9.10
Magnus Hagander wrote:
On Sun, Nov 29, 2009 at 16:18, Sachin Srivastava
sachin.srivast...@enterprisedb.com wrote:
Libraries the One-Click installer tramples all over include:
libxml2
libssl
libcrypto
libreadline
libtermcap
libuuid
Apart from libxml2 (which is now being fixed) all other libraries you
mentioned , dint get installed (or copied) to the PGHOME/lib directory if
the same name library already present in the system (/lib and /usr/lib).
What happens if they are installed by the packaging system later on?
Won't that cause a conflict then?
What if the libraries installed by the system package manager have been
built with different options that render them incompatible with the
shipped PostgreSQL binaries? Possibly subtly so, with crashes or data
corruption down the track rather than immediate and obvious failure?
(Arguably the soname should be changed in this case, but in practice the
soname just isn't sufficient for this sort of thing - you need some kind
of build key and there's no support in GNU ld and ld.so for such).
I'd say ffs, just enable rpath but for the fact that without a wee bit
more work it doesn't handle moving binaries around very well. Mac OS X's
@executable_path runtime linker path substitution doesn't seem to have
a standard equivalent on general *nix. Thankfully, GNU ld.so does offer
a similar runtime path substitution - the ${ORIGIN} variable. From the
ld.so manpage:
$ORIGIN
ld.so understands the string $ORIGIN (or equivalently
${ORIGIN}) in an rpath specification to mean the
directory containing the application executable.
Thus, an application located in somedir/app could be
compiled with gcc -Wl,-rpath,'$ORIGIN/../lib' so that
it finds an associated shared library in somedir/lib
no matter where somedir is located in the directory
hierarchy.
(There's also some other good stuff under RPATH TOKEN EXPANSION. If
you haven't read the entirety of the ld.so and ld man pages, you need to
do so *now* if you're packaging apps for binary distribution).
Note that you can build without rpath, or with normal rpaths, and change
them later using the commonly-available chrpath too. For that matter,
you can skip using $ORIGIN and just use a bundled copy of chrpath to set
rpaths on your binaries at install-time.
http://linux.die.net/man/1/chrpath
So, please, please, PLEASE start using rpath linkage and stop adding
your lib dir to ld.so.conf ! This problem has been around - and solved -
for a very long time, and you'd be much better off using the existing
well-established and robust solutions rather than rolling your own
dangerous workarounds.
--
Craig Ringer
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] Date with time zone
On Sun, Nov 29, 2009 at 8:23 PM, Adrian Klaver akla...@comcast.net wrote: On Sunday 29 November 2009 2:38:43 pm Eduardo Piombino wrote: On Sat, Nov 28, 2009 at 8:55 PM, Adrian Klaver akla...@comcast.net wrote: On Saturday 28 November 2009 3:41:42 pm Eduardo Piombino wrote: Hi Adrian, thanks for your answer. I see current criteria and all the SQL-standard compliance policy, but wouldn't it still make sense to be able to store a date reference, along with a time zone reference? Wouldn't it be useful, wouldn't it be elegant? If i just want to store a reference to Dec 19th without adding an innecesary reference to a dummy time, like 00:00:00 (for time zone tracking's sake), wouldn't it be elegant to be able to say Dec 19th (GMT-3) ? The problem arises around the dates when DST starts and ends. For instance here, Washington State USA, Nov 1st was the change over date. This occurred at 2:00 AM in the morning, so on Nov 1st we where in two time zones PDT then PST. Without a reference to time it makes it hard to keep track. For the sake of simplicity I would like to leave the DST's modifications off the discussion, just for now. Considering a fixed setup, where every country has a fixed time zone (or many, but fixed), I will try to make my point. If I we can all agree on the point at a fixed setup, I'm more than willing to get into a more complex scenario and just then introduce summer times, etc. If you are ok with it. Not really because such an animal does not exist AFAIK. If does it is the exception. Analysis of the extra complications added by DST's does not add anything, yet, to the point I'm trying to make, regardless the lack of such cases in practice. As stated above time zones only have meaning with respect to date and time together. I'm not quite sure about this. For example, if you want to say I will accept bets until 6 o'clock (London Time), every day. How does that time reference need to be tied to a specific date?. It's just a reference to a time in the day, by itself. Plus a time zone, because 6 o'clock by itself is also not sufficient, it still needs a time zone reference. It's also not a timestamp, nor a date, its just a time (with time zone tracking capabilities). And that's where I see that time with time zone is a good, and the one data type to use, IMO. Because this assumes you are in the London time zone. If you are placing bets from outside the London time zone you need to be aware of the time offset, because the local time you can place the bet is going to change based on the time zone in effect. To know what time zone is in effect you need to know the date. I don't really care about the local time from where the bets are being taken. The server is located in London, configured with the London Time offset, and it is this server who accepts or rejects the bets. So if you place a bet after 6PM London Time, regardless it's 10AM in your country, it will still be rejected. It is also very clearly stated in the web page that the bets are taken until 6PM London Time. From a technical point of view, that time, 6PM London Time, can be easily defined by a time with time zone data type, contrary to any other setup based on assumptions (such as assigning the default local time zone of where the server is to the time without time zone, or keeping track of the time zone on a different data field), with a simple 18:00:00+00 (+00 stands for London Time). You can even have a server setup anywhere in the world, with any arbitrary time zone (for the server) and still be able to take bets until 6PM London Time only having specified the same value for the deadline as before 18:00:00+00 (time with time zone). I find it particularly more elegant to use this data type if available, you kill two birds at once. Going back to the date with datetime, follow me with this reasoning: If you consider a specific date (in a specific time zone) defined as a specific starting point in time (absolute and universal), and a specific ending point in time, one could say that a date is a period of time ranging from 00:00 hs to 23:59:59. (just as some other member list suggested, with which I totally agree), both times tied to a specific time zone. One could then say that, Dec 19th (London Time) goes from Dec 19th 00:00:00 (London Time) to Dec 19th 23:59:59.9... (London Time). So, making a reference to Dec 19th (London Time) would make sense as it refers to a specific absolute time frame, or range. This range, could be (or not, but that is not the point) useful for some practical situations, but the impossibility to be able to state a reference to a date, without recurring to some tweaks or patches is sthing that at the least, bugs me a little. You can referr to date just not with a time zone. Yes, but you would miss the important
Re: [GENERAL] Postgresql8.4 install breaks Evolution on Ubuntu 9.10
Greg Stark wrote:
But i don't see what the conflict is if they're installed in
PGHOME/lib as long as the installer doesn't fiddle with
/etc/ld.so.conf or set any environment variables. The binaries should
just be built with an rpath pointing to that directory or ship with a
startup script which puts that directory in LD_LIBRARY_PATH.
In fact, it looks like the EnterpriseDB init scripts *already* set
LD_LIBRARY_PATH when starting the postgresql daemon, despite having also
messed with ld.so.conf . It's a weird half-and-half approach.
I've tested the distribution with ${ORIGIN} based rpath linking without
issues.
Until EnterpriseDB get around to fixing this in their packages, if you
or anyone else need to fix a one-click PostgreSQL-on-Linux binary
install, just make sure chrpath is installed (eg: apt-get install
chrpath) then run the following:
cd /opt/PostgreSQL/8.4
sudo -v
for f in `file * | grep ELF | cut -d : -f 1 `; do
sudo chrpath --replace \${ORIGIN}/../lib $f
done
sudo rm -f /etc/ld.so.conf.d/postgresql-8.4
sudo ldconfig
... which will remove the edb-installed libs from the global search path
and will set the edb binaries to preferentially use the copies of the
libs that came with the distribution. Note that this will change the
checksum of the binaries.
*** TO FIX THIS IN THE EDB ONECLICK DISTRIBUTION ***:
Just build the Pg binaries for the distribution as normal. Once you've
built the binaries and installed to a staging directory, use chrpath to
edit the rpath setting as above, so that the binaries know where to look
for their libraries. Remove /etc/ld.so.conf.d/postgresql-8.4 from the
installer package. Remove setting of LD_LIBRARY_PATH from the init script.
Finally, please rename /etc/init.d/postgresql-8.4 to something that
*doesn't* clobber a distro-installed initscript, like say
/etc/init.d/postgresql-oneclick-8.4 .
*grumbles and restores his original init script from backups after it
was clobbered by the edb installer*
Whether
you want to append, leaving the system directories ahead of the
one-click installed libraries, or prepend so the linker always uses
your libraries would depend on how you want it to behave. Setting
rpath is equivalent to prepending I believe.
It is. It's also much, much safer to do things that way, because a lib
with the same name but incompatible configuration won't land up being
unexpectedly loaded.
--
Craig Ringer
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] Access a Field / Column of a resultset by Number
In response to Daniel Schuchardt : hy group, i currently look for a solution to access a resultset in a db-stored function by number. in plpgsql thats not possible. Can you wait until 8.5? http://okbob.blogspot.com/2009/10/dynamic-access-to-record-fields-in.html Regards, Andreas -- Andreas Kretschmer Kontakt: Heynitz: 035242/47150, D1: 0160/7141639 (mehr: - Header) GnuPG: 0x31720C99, 1006 CCB4 A326 1D42 6431 2EB0 389D 1DC2 3172 0C99 -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
[GENERAL] Fwd: psql+krb5
-- Forwarded message --
From: rahimeh khodadadi rahimeh.khodad...@gmail.com
Date: 2009/11/29
Subject: Re: psql+krb5
To: Denis Feklushkin denis.feklush...@gmail.com
These items have added after my sending.
I repeat again my configurations:
*
1) The configuration of krb5.conf is:
[realms]
EXAMPLE.COM http://example.com/ ={
kdc=star :88
admin_server=star:749
default_domain= example.com
}
.*
2) Then, I created principal as* postgres/s...@example.com * and its
password is saved in* '/usr/local/pgsql/data/postgresql.keytab' .*
(star is localhost IP, but in hosts.conf I configure like: 213.233.169.93
star)
3) I setup *postgresql.conf *as below:
krb_server_keyfile = '/usr/local/pgsql/data/
postgresql.keytab'
krb_srvname = 'postgres/s...@example.com'
krb_server_hostname = 'star' # empty string matches any keytab entry
krb_caseins_users = off
4) I *create user frank* in Psql .
5) Then I set up* hba.conf :*
hostall all 0.0.0.0/0 krb5
hostall all 127.0.0.1/32 krb5
When I want to connect to Postgresql, it gives error.
# *kinit frank*
[r...@star bin]# *./psql -h star -U frank -d test*
psql: *krb5_sendauth: Bad application version was sent (via sendauth)*
I should mention that * both postgresql server and krb-server are in same
system* and* my IP is acquring from dhcp server of university*. Where is
wrong.
2009/11/29 Denis Feklushkin denis.feklush...@gmail.com
On Sun, 29 Nov 2009 14:23:52 +0330
rahimeh khodadadi rahimeh.khodad...@gmail.com wrote:
Thanks for your replying. My detail of configuration is:
I try to setup kerberos authentication in Postgresql 8.1.18 on centos.
But I have some problem.
1) The configuration of krb5.conf is:
[realms]
EXAMPLE.COM http://example.com/http://EXAMPLE.COM
http://example.com/ ={
kdc=star :88
admin_server=star:749
default_domain= example.comhttp://example.com
}
.
2) Then, I created principal as postgres/s...@example.commailto:
s...@example.com and its password is saved in
'/usr/local/pgsql/data/postgresql.keytab' .
(star is localhost IP, but in hosts.conf I configure like:
213.233.169.93 star)
3) I setup postgresql.conf as below:
krb_server_keyfile = '/usr/local/pgsql/data/
postgresql.keytab'
krb_srvname = 'postgres/s...@example.commailto:s...@example.com'
krb_server_hostname = 'star' # empty string matches any
keytab entry
krb_caseins_users = off
4) I create user frank in Psql .
5) Then I set up hba.conf :
hostall all 0.0.0.0/0http://0.0.0.0/0
krb5
hostall all 127.0.0.1/32http://127.0.0.1/32
krb5
When I want to connect to Postgresql, it gives error.
# kinit frank
[r...@star bin]# ./psql -h star -U frank -d test
psql: krb5_sendauth: Bad application version was sent (via sendauth)
some changes in users gives below error :
[r...@www bin]# ./psql -h 213.233.168.249 -U postgres
psql: Kerberos 5 authentication rejected: Wrong principal in
request
I should mention that both postgresql server and krb-server are in
same system and my IP is acquring from dhcp server of university.
Where is wrong.
2009/11/29 Denis Feklushkin denis.feklush...@gmail.com
On Sun, 29 Nov 2009 10:48:30 +0330
rahimeh khodadadi rahimeh.khodad...@gmail.com wrote:
Hi,
When I want to connect to psql via krb5 in Linux, it gives me
error like: [r...@www bin]# ./psql -h 213.233.168.249 -U
postgres psql: Kerberos 5 authentication rejected: Wrong
principal in request
Что в логах KDC?
!!!
И ещё, в тексте который Вы дали встречаются пробелы в именах
принципалов и странные записи mailto:s...@example.com
При настройке важно чтобы ничего этого небыло
--
With Best Regards
Miss.KHodadadi
--
With Best Regards
Miss.KHodadadi
Re: [GENERAL] Postgres 8.4
2009/11/29 Yasser Shakoor yassershak...@gmail.com: Hi I am using postgres 8.4 but couldnot able to use the OLAP functionality can you please advice do i have apply any patch for this. I am using postgres on windows and downloaded the latest version from Enterprise DB site. Regards, Yasser What exactly is OLAP functionality you mention? You can use window function from 8.4 on: SELECT row_number() OVER () FROM tbl; Regards, -- Hitoshi Harada -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
