Re: [SQL] What does PostgreSQL do when time goes backward?
I wrote: > How does PostgreSQL react to time being stepped at bootup? My Chrony > NTP package might cause it to do so on rare occasions when the > hardware clock is way off. This would only happen during bootup. Ken writes: > PostgreSQL does not use system time to track transactions so you > should be good. Thank you. > Also, these types of clock changes by ntpd use the adjtime() system > call which either slows or speeds the system clock to make the > adjustment over a period of time so it should be minimally disruptive. This is about Chrony <http://www.chrony.tuxfamily.org>, an alternative ntp implementation. In any case, both chronyd and ntpd can step the clock (possibly backwards) at bootup under some rare circumstances. Frank writes: > My ntp client changes clock (by small amount) at any time: > Jul 25 05:29:38 bax ntpd[10269]: adjusting local clock by 0.098724s > Jul 25 05:31:43 bax ntpd[10269]: adjusting local clock by 0.038991s > Jul 25 06:13:38 bax ntpd[10269]: adjusting local clock by -0.037131s > Jul 25 15:01:52 bax ntpd[10269]: adjusting local clock by -0.112429s Ken writes: > These do seem to be larger values than you might expect from a clock > conditioned with ntpd. Is it a VM or is there something going on that > would stop or suspend your system? There is certainly something wrong there. -- John Hasler jhas...@newsguy.com Elmwood, WI USA -- Sent via pgsql-sql mailing list (pgsql-sql@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-sql
[SQL] What does PostgreSQL do when time goes backward?
How does PostgreSQL react to time being stepped at bootup? My Chrony NTP package might cause it to do so on rare occasions when the hardware clock is way off. This would only happen during bootup. -- John Hasler jhas...@newsguy.com Elmwood, WI USA -- Sent via pgsql-sql mailing list (pgsql-sql@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-sql
Re: [SQL] Grass Root Protectionism
D'Arcy J.M. Cain writes: > Hey buddy, I know what I, a non-American, have done for this project. > What have you done? I expect that this guy would tell you that all Free Software is evil and takes food out of the mouths of his children. -- John Hasler j...@dhh.gt.org Elmwood, WI USA -- Sent via pgsql-sql mailing list (pgsql-sql@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-sql
Re: [SQL] Grass Root Protectionism
Bruce Momjian writes: > Without non-US developers, Postgres would be less than half what it is > today Without non-US developers, Postgres would be _much_ less than half what it is today, just as it would be much less than half of what it is today without US developers. Cooperation, like trade, is a positive sum game. > It is US people who are benefitting more from the relationship, not > non-US people. All are benefitting. The notion that someone is "winning" and therefor someone else must be "losing" is the OP's false thesis. -- John Hasler j...@dhh.gt.org Elmwood, WI USA -- Sent via pgsql-sql mailing list (pgsql-sql@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-sql
Re: [SQL] Copyright and Paper walls
Steve writes: > I don't want to pile more wood on the fire, but I think I can see both > sides to this. I believe this is not so much copyright violation concern, > but if the Pg team releases some cool feature relating to rollbacks > down-the-road that is vaguely similar to Oracle's system, reducing the > amount of discussion about Oracle's features on this list would reduce > Oracle's ability to claim that the feature was a direct appropriation. So what if it is direct appropriation? Either it is patented, in which case you infringe whether you looked at their docs or not, or it isn't, in which case they have no grounds for action. There is nothing wrong with discussing Oracle's features or even deliberately duplicating them. -- John Hasler [EMAIL PROTECTED] Elmwood, WI USA -- Sent via pgsql-sql mailing list (pgsql-sql@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-sql
Re: [SQL] accounting schema
Look at LedgerSMB at . It uses Postgresql. -- John Hasler [EMAIL PROTECTED] Elmwood, WI USA ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [SQL] UTF8 encoding and non-text data types
Joe writes: > The Arabic language is written right-to-left, except ... when it comes to > numbers. Perhaps they read their numbers right to left but use a little-endian notation. -- John Hasler [EMAIL PROTECTED] Elmwood, WI USA ---(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: [SQL] Need help with 'unique parents' constraint
Greg Sabino Mullane writes: > Not just old-fashioned, [having only one mother is] the biological law! I see you aren't up on current research. -- John Hasler [EMAIL PROTECTED] Elmwood, WI USA ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [SQL] [GENERAL] CURRENT_TIMESTAMP
Josh Berkus writes:
> now() or now('transaction') returns the transaction timestamp.
> now('statement') returns the statement timestamp now('immediate') returns
> the timestamp at the exact time the function is called.
I like that.
IMHO "the exact time the function is called" is what most people would
expect to get from now(), but it's too late for that.
--
John Hasler
[EMAIL PROTECTED]
Dancing Horse Hill
Elmwood, Wisconsin
---(end of broadcast)---
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to [EMAIL PROTECTED] so that your
message can get through to the mailing list cleanly
Re: [SQL] [GENERAL] CURRENT_TIMESTAMP
Bruce Momjian writes: > My point is that our current behavior may not be the most intuitive, and > that most people may prefer a change. I would prefer a change. -- John Hasler [EMAIL PROTECTED] Dancing Horse Hill Elmwood, Wisconsin ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
Re: [SQL] GUID in postgres
I wrote: > Globally Unique IDentifier, probably. Just hash a 128 bit random number > with the current date. Horst writes: > That gives you no gurantee it will be unique. There is no such guarantee. The probability of a collision due to errors and bugs using a "deterministic" system is sure to be at least as large as the the probability of a chance collision using large random numbers (_random_, not pseudorandom). Stick machine, table, and database ID's in there as well if it makes you more comfortable, but even without them the risk of a collision is down there with the risk of cosmic ray induced errors. _Nothing_, however, can make it zero. > - All tables in need of a global ID _within_ a database inherit a globid > table which contains nothing but an ID of type serial. - When we need > cross-database unique IDs within the same system, the globid table > contains a database identifier as well (like the OID of the pg_database > entry for the database). And that's fine, but the GUID system uses the word "global" in a much more grandiose sense. -- John Hasler [EMAIL PROTECTED] Dancing Horse Hill Elmwood, Wisconsin ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [SQL] GUID in postgres
Josh writes: > I'm sure you could make your own GUID, whatever one is. Globally Unique IDentifier, probably. Just hash a 128 bit random number with the current date. -- John Hasler [EMAIL PROTECTED] Dancing Horse Hill Elmwood, Wisconsin ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
Re: [SQL] Is function atomic?
I wrote: > Do you have any idea when [nested transactions] will [be added]? Richard Huxton writes: > Check the "todo" list in the developers' area on the website - that'll > show what's planned for 7.2 It's listed there: that's why I asked. Is everything on that list planned for 7.2? -- John Hasler [EMAIL PROTECTED] Dancing Horse Hill Elmwood, Wisconsin ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [SQL] Is function atomic?
Richard Huxton writes: > All functions take place within a transaction, but since PG doesn't > support nested transactions yet you can't roll back the effects of a > nested function. Do you have any idea when it will? -- John Hasler [EMAIL PROTECTED] (John Hasler) Dancing Horse Hill Elmwood, WI ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
[SQL] Nested Transactions
Can anyone give me an estimate of when we might expect to see nested transactions implemented? -- John Hasler [EMAIL PROTECTED] (John Hasler) Dancing Horse Hill Elmwood, WI ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://www.postgresql.org/search.mpl
Re: [SQL] function to format floats as money?
I wrote: > Floats are fine for money as long as you only add and subtract and don't > deal in amounts that won't fit in the mantissa. Ross writes: > Or you're writing software in Germany (all of the EU now?) that _might_ get > used in an offical capacity. I was referring to what actually works, not to what might or might not meet with the approval of some officialdom or other. The two seldom bear any discernible relationship. -- John Hasler [EMAIL PROTECTED] (John Hasler) Dancing Horse Hill Elmwood, WI ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [SQL] function to format floats as money?
Ross writes: > But seriously, numeric(10,2) (or whatever precision and scale is correct > for your application) is the standard answer. Floats are fine for money as long as you only add and subtract and don't deal in amounts that won't fit in the mantissa. -- John Hasler [EMAIL PROTECTED] (John Hasler) Dancing Horse Hill Elmwood, WI ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [SQL] Invoice number
Mike Castle writes: > Client 3 comes along. Do they use invoice #1, out of order, or invoice > #3? It shouldn't matter, as long as every number is accounted for. Seems to me that a trigger could make a log entry every time the serial is incremented. Workable? > What happens in a paper world if a cup of coffee is spilt on some > invoices, and these precious items are thrown in the trash? They are returned to accounting with an explanatory note, the numbers are logged as "voided", and the spoiled forms are shredded. -- John Hasler [EMAIL PROTECTED] Dancing Horse Hill Elmwood, Wisconsin
Re: [SQL] Invoice number
Mike Castle writes: > If so, why is no rollbackable an issue? All you should need is unique > numbers. Not necessarily exactly sequential numbers. Sometimes business rules require that every member of a sequence of such things as invoice numbers be accounted for. Speculation: Would it be possible to log SERIAL's as they are issued? It might be sufficient to just record the user id, though it would be more useful to log some indication of what the number was used for (or at least whether or not it was used at all). -- John Hasler [EMAIL PROTECTED] (John Hasler) Dancing Horse Hill Elmwood, WI
Re: [SQL] postgres
Joseph Shraibman writes: > I've been wondering for a long time how people manage to find the mailing > list without finding the web site. They do a Web search on 'postgres' and get a zillion hits on articles in the list archive. They then look at the first article and pull the address out of that. They never notice where the article came from. -- John Hasler [EMAIL PROTECTED] Dancing Horse Hill Elmwood, Wisconsin
Re: [SQL] nested transactions
Bernie Huang writes: > Just out of curiousity, does Postgres support nested transactions? I'd like to know too, and not just out of curiousity. I have a use for that. -- John Hasler [EMAIL PROTECTED] (John Hasler) Dancing Horse Hill Elmwood, WI
Re: [SQL] memory usage
Carolyn Wong writes: > This program seems to use a lot of the memory on the linux server, and > the memory doesn't seem to be released at the end of execution. Are you quite certain that this is actually what is happening? Linux memory usage can be confusing. -- John Hasler [EMAIL PROTECTED] (John Hasler) Dancing Horse Hill Elmwood, WI
