Grokbase
Topics Posts Groups | in
x
[ help ]

Bruce Momjian (p...@candle.pha.pa.us)

Profile | Posts (7373)

User Information

Display Name:Bruce Momjian
Partial Email Address:p...@candle.pha.pa.us
Posts:
7373 total
595 in PostgreSQL - Admin
512 in PostgreSQL - Advocacy
61 in PostgreSQL - Announce
1052 in PostgreSQL - Bugs
64 in PostgreSQL - Cygwin
760 in PostgreSQL - Docs
2680 in PostgreSQL - General
396 in PostgreSQL - Interfaces
430 in PostgreSQL - JDBC
100 in PostgreSQL - Novice
168 in PostgreSQL - ODBC
297 in PostgreSQL - Performance
7 in PostgreSQL - PHP
496 in PostgreSQL - SQL

5 Most Recent

All Posts
1) Bruce Momjian Re: [Win32] Problem with rename()
| +1 vote
Yea. Where you using WAL archiving? We will have a fix in 8.1.5 to prevent multiple archivers from...
PostgreSQL - Bugs
[ Profile | Reply to group ] [ Flat  Thread  Threaded ]
Peter Brant wrote:
> Really?  If there was a patch, I missed it.
>
> My recollection is that there was general agreement about this
> particular problem (see, for example,
> http://archives.postgresql.org/pgsql-bugs/2006-04/msg00189.php ), but
> things kind of trailed off after that without a resolution.

Yea.  Where you using WAL archiving?  We will have a fix in 8.1.5 to
prevent multiple archivers from starting.  Perhaps that was a cause.

> As far as the complete list of Win32 problems which affected us:
> - The stats collector crashing should indeed be fixed in 8.1.4
> - Missing stats caused by Windows PID recycling is fixed in 8.2
> - Various semaphore problems are probably all fixed with the new
> Win32 semaphore implementation in 8.2
> - The stuck log rename problem mentioned above is still an issue

Yep.  What has me baffled is why no one else is seeing the problem.
We had a rash of reports, and now all is quiet.

> - The "permission denied on fsync" (or something like that) problem
> is still an issue. Unfortunately, IIRC, we could never really nail down
> the underlying problem.

Yes, I just reread that thread.  I also am confused where to go from
here.

> None of these problems affect us any more: the production servers now
> run Linux. Great to have options! (and we were moving that direction
> anyway)

Were you the only one use Win32 in heavy usage?  You were on Win2003. 
Were there some bugs in the OS that got fixed later.

Yea, stumped.  Guess we will have to wait for more reports.  I don't
even see how to document this as a TODO.

--
Bruce Momjian http://candle.pha.pa.us
EnterpriseDB http://www.enterprisedb.com

+ If your life is a hard drive, Christ can be your backup. +
2) Bruce Momjian Re: [Win32] Problem with rename()
| +1 vote
I am assuming this problem and the other rash of Win32 problems reported in March are now all fixed...
PostgreSQL - Bugs
[ Profile | Reply to group ] [ Flat  Thread  Threaded ]
I am assuming this problem and the other rash of Win32 problems reported
in March are now all fixed in 8.1.4.  If not, please let me know.

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


Tom Lane wrote:
> I wrote:
> > "Peter Brant" <Peter.Brant@wicourts.gov> writes:
> >> Does that also explain why an attempt to make a new connection just
> >> hangs?
>
> > Actually, I was just wondering about that --- seems like a bare
> > connection attempt should not generate any WAL entries. Do you have any
> > nondefault actions in ~/.psqlrc or something like that?
>
> I just repeated the hangup scenario here, and confirmed that I can still
> start and stop a plain-vanilla psql session (no ~/.psqlrc, no special
> per-user or per-database settings) without it hanging. I can also do
> simple read-only SELECTs. So I'm thinking your hang must involve some
> additional non-read-only actions.
>
> [ thinks for awhile longer ... ] No, I take that back. Once you'd
> exhausted the current pg_clog page (32K transactions), even read-only
> transactions would be blocked by the need to create a new pg_clog page
> (which is a WAL-logged action). A read-only transaction never actually
> makes a WAL entry, but it does still consume an XID and hence a slot on
> the current pg_clog page. So I just hadn't tried enough transactions.
>
>    regards, tom lane
>
> ---------------------------(end of broadcast)---------------------------
> TIP 2: Don't 'kill -9' the postmaster
>

--
Bruce Momjian http://candle.pha.pa.us
EnterpriseDB http://www.enterprisedb.com

+ If your life is a hard drive, Christ can be your backup. +
3) Bruce Momjian Re: A real currency type
| +1 vote
I have added this URL to the TODO list in case people want to move forward on this. -- Start of PGP...
PostgreSQL - General
[ Profile | Reply to group ] [ Flat  Thread  Threaded ]
I have added this URL to the TODO list in case people want to move
forward on this.

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

Martijn van Oosterhout wrote:
-- Start of PGP signed section.
> For a while I've been wondering about making a type that was really a
> shell around a base type that tagged the type in some way. For example,
> associating a currency with a numeric and complaining about additions
> between mismatches.
>
> Well, I did it and it's available here:
> http://svana.org/kleptog/pgsql/taggedtypes.html
>
> Below some examples of it in action. Yes, that's a timestamp that
> remembers the timezone. Neat huh?
>
> Tested on 7.4 and a recent 8.1devel so it should work for most people.
> Installation reports welcome. Note, this is beta software, don't run it
> on your production server. Thanks.
>
> Have a nice day,
>
>
> test=# select '5.6 USD'::currency + '4.5 USD'::currency;;
>  ?column?  
> -----------
>  10.10 USD
> (1 row)
>
> test=# select '5.6 USD'::currency + '4.5 AUD'::currency;;
> ERROR: Using operator +(currency,currency) with incompatable tags (USD,AUD)
> test=# select c1, print_currency(c1) from c;
>      c1     | print_currency 
> ------------+----------------
>  232.44 USD | US$    232.44
>  21.20 EUR  | ?       21.20
>  -13.44 AUD | AU$    -13.44
>  0.01 USD   | US$      0.01
>  14.00 AUD  | AU$     14.00
> (5 rows)
>
> test=# select 5.4*c1 from c where tag(c1) = 'AUD';
>   ?column?  
> ------------
>  -72.58 AUD
>  75.60 AUD
> (2 rows)
>
> test=# select t, "timestamp"(t), date_part('hour',t) from c;
> t | timestamp | date_part
> -----------------------------------------+---------------------+-----------
> 2005-08-14 02:00:00+02 Europe/Amsterdam | 2005-08-14 02:00:00 | 2
> 2005-08-14 02:00:00+02 Australia/Sydney | 2005-08-14 10:00:00 | 10
> 2005-08-14 02:00:00+02 Asia/Hong_Kong | 2005-08-14 08:00:00 | 8
> 2005-08-14 02:00:00+02 America/New_York | 2005-08-13 20:00:00 | 20
> 2005-08-14 02:00:00+02 Asia/Kuwait | 2005-08-14 03:00:00 | 3
> (5 rows)
>
> --
> Martijn van Oosterhout <kleptog@svana.org> http://svana.org/kleptog/
> > Patent. n. Genius is 5% inspiration and 95% perspiration. A patent is a
> > tool for doing 5% of the work and then sitting around waiting for someone
> > else to do the other 95% so you can sue them.
-- End of PGP section, PGP failed!

--
Bruce Momjian http://candle.pha.pa.us
EnterpriseDB http://www.enterprisedb.com

+ If your life is a hard drive, Christ can be your backup. +
4) Bruce Momjian Re: Omitting tablespace creation from pg_dumpall...
| +1 vote
Should pg_dumpall be using the "SET default_tablespace = foo" method as well? ...
PostgreSQL - General
[ Profile | Reply to group ] [ Flat  Thread  Threaded ]
Should pg_dumpall be using the "SET default_tablespace = foo" method as
well?

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


Florian G. Pflug wrote:
> Chander Ganesan wrote:
> > Tom Lane wrote:
> >> Chander Ganesan <chander@otg-nc.com> writes:
> >>  
> >>> I'd like to suggest that a feature be added to pg_dumpall to remove
> >>> tablespace definitions/creation from the output. While the inclusion
> >>> is important for backups - it's equally painful when attempting to
> >>> migrate data from a development to production database. Since
> >>> PostgreSQL won't create the directory that will contain the
> >>> tablespace, the tablespace creation will fail. Following that, any
> >>> objects that are to be created in that tablespace will fail (since
> >>> the tablespace doesn't exist).
> >>
> >> If the above statements were actually true, it'd be a problem, but they
> >> are not true. The dump only contains "SET default_tablespace = foo"
> >> commands, which may themselves fail, but they won't prevent subsequent
> >> CREATE TABLE commands from succeeding.
> >>
> >>   
> > With PostgreSQL 8.1.4, if I do the following:
> >
> > create tablespace test location '/srv/tblspc';
> > create database test with tablespace = test;
> >
> > The pg_dumpall result will contain:
> > *****
> > CREATE TABLESPACE test OWNER postgres LOCATION '/srv/tblspc';
> > CREATE DATABASE test WITH TEMPLATE=template0 OWNER=postgres
> > ENCODING='utf8' TABLESPACE=test;
>
> Hm.. I guess pg_dumpall is meant to create a identical clone of a
> postgres "cluster" (Note that the term cluster refers to one
> postgres-instance serving multiple databases, and _not_ to a cluster
> in the high-availability sense). For moving a single database from one
> machine to another, pg_dump might suit you more. With pg_dump, you
> normally create the "new" database manually, and _afterwards_ restore
> your dump into this database.
>
> I'd say that pg_dumpall not supporting restoring into a different
> tablespace is compareable to not supporting database renaming. Think
> of pg_dumpall as equivalent to copying the data directory - only that
> it works while the database is online, and supports differing
> architectures on source and destination machine.
>
> greetings, Florian Pflug
>
>
> ---------------------------(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
EnterpriseDB http://www.enterprisedb.com

+ If your life is a hard drive, Christ can be your backup. +
5) Bruce Momjian Re: postgres and ldap
| +1 vote
Doc patch applied. I must have missed the second attachment. ...
PostgreSQL - General
[ Profile | Reply to group ] [ Flat  Thread  Threaded ]
Doc patch applied. I must have missed the second attachment.

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


Tom Lane wrote:
> "Magnus Hagander" <mha@sollentuna.net> writes:
> > Actually, the docs *were* submitted. See
> > http://archives.postgresql.org/pgsql-patches/2005-12/msg00375.php.
> > Applied per
> > http://archives.postgresql.org/pgsql-patches/2006-03/msg00080.php, I
> > think it's just the docs that were missed.
>
> Ah. I had found the docs-less commit but didn't go looking through patches.
> Will gather up the docs and apply unless Bruce beats me to it. Thanks.
>
>    regards, tom lane
>
> ---------------------------(end of broadcast)---------------------------
> TIP 6: explain analyze is your friend
>

--
Bruce Momjian http://candle.pha.pa.us
EnterpriseDB http://www.enterprisedb.com

+ If your life is a hard drive, Christ can be your backup. +

spacer
Profile | Posts (7373)
Home > People > Bruce Momjian