unregister
On Fri, Aug 3, 2012 at 12:08 PM, Radovan Jablonovsky
wrote:
> Thanks you for your response.
>
> Database config:
> shared_buffers = 8GB
> temp_buffers = 32MB
> work_mem = 64MB
> maintenance_work_mem = 512MB
> effective_cache_size = 16GB
>
> In usual load there are not much pressure on memory, but
Alanoly Andrews writes:
> On this issue, instead of going for a newer version of xlc, as suggested, I
> opted to get a newer version of the Postgres source code, 9.1.4. After
> compiling it with the same xlc version, I found that pg_dump works as
> expected. So, the problem appears to be somewh
Radovan Jablonovsky wrote:
> In usual load there are not much pressure on memory, but it is
> possible to have all clients start using heavy reports. They are
> valid requests and could consume all memory.
Your clients will get their results back faster if you can arrange
some way to queue the
Radovan Jablonovsky writes:
> In usual load there are not much pressure on memory, but it is possible to
> have all clients start using heavy reports. They are valid requests and
> could consume all memory. In this border and not likely but possible
> scenario it could be useful to let OOM killer
> [ shrug... ] If you really insist on re-inventing that wheel, go
ahead, but it sounds to me like you'll just be introducing additional
points of failure. regards, tom lane
I just checked some programming languages (Python, C#), and the same
problem exists there. All of them say that "when th
Thanks you for your response.
Database config:
shared_buffers = 8GB
temp_buffers = 32MB
work_mem = 64MB
maintenance_work_mem = 512MB
effective_cache_size = 16GB
In usual load there are not much pressure on memory, but it is possible to
have all clients start using heavy reports. They are valid re
2012.08.03. 18:38 keltezéssel, Tom Lane írta:
Laszlo Nagy writes:
I have intentionally chosen an example where the local time is changed
from summer time to winter time (e.g. local time suddenly "goes back"
one hour). It demonstrates that you cannot use "at time zone "
expression to convert
Laszlo Nagy writes:
> I have intentionally chosen an example where the local time is changed
> from summer time to winter time (e.g. local time suddenly "goes back"
> one hour). It demonstrates that you cannot use "at time zone "
> expression to convert a timestamptz into a desired time zon
On 08/03/2012 08:23 AM, Laszlo Nagy wrote:
...
It works. Thank you!
So is it impossible to construct a query with columns that are
different time zones? I hope I'm not going to need that. :-)
I'm not sure you have internalized the meaning of timestamptz. It helps
to instead think of it as
You could store the zone in a separate field and then create a VIEW on
the table that used a function to take both values and return the
timestamptz just as it was inserted.
Well no, it is not possible. A timestamptz value is interpreted as UTC,
regardless of your local timezone. A timestam
On 8/3/2012 11:23 AM, Laszlo Nagy wrote:
I suspect that you have not correctly internalized what timestamptz
values actually are. Internally they are just time values specified in
UTC (or UT1 if you want to be picky). On input, the value is rotated
from whatever zone is specified in the string
On 2012-08-03 16:19, Tom Lane wrote:
Laszlo Nagy writes:
So how do I create a query that results in something like:
a
--
Sun Oct 30 02:00:00 2011 +0500
Sun Oct 30 02:00:00 2011 +0600
(2 rows)
Set the "timezone" setting to the zone you have in mind
Laszlo Nagy writes:
> So how do I create a query that results in something like:
> a
> --
> Sun Oct 30 02:00:00 2011 +0500
> Sun Oct 30 02:00:00 2011 +0600
> (2 rows)
Set the "timezone" setting to the zone you have in mind, and then just
print the valu
Here is a better example that shows what I actually have in my database.
Suppose I have this table, with UTC timestamps in it:
template1=> create table test ( a timestamptz not null primary key );
NOTICE: CREATE TABLE / PRIMARY KEY will create implicit index
"test_pkey" for table "test"
CREA
On 2012-08-03 10:31, Laszlo Nagy wrote:
select abbrev,utc_offset,count(*) from pg_timezone_names
where abbrev='EST'
group by abbrev,utc_offset
There are 12 times zones with 'EST' code, offset = GMT+10. And there
are 8 time zones with 'EST' code, offset= GMT+5 at the same time!
Sorry, I still h
On Fri, Aug 3, 2012 at 5:18 PM, Laszlo Nagy wrote:
>
>
> Isn't:
>
> select now() at time zone 'Australia/ATC'
>
> supposed to be:
>
> select now() at time zone 'Australia/ACT'
>
> I see now. The abbreviation is usually a time zone name. But to be
> correct, the time zone name should be used
Isn't:
select now() at time zone 'Australia/ATC'
supposed to be:
select now() at time zone 'Australia/ACT'
I see now. The abbreviation is usually a time zone name. But to be
correct, the time zone name should be used (and not the abbreviation).
And looking at the pg_timezone_names table f
Re-sending this since I seem to have left out the list itself:
On Fri, Aug 3, 2012 at 4:31 PM, Laszlo Nagy wrote:
> select abbrev,utc_offset,count(*) from pg_timezone_names
> where abbrev='EST'
> group by abbrev,utc_offset
>
> There are 12 times zones with 'EST' code, offset = GMT+10. And there
On 08/03/2012 04:37 PM, Laszlo Nagy wrote:
It is also better because with a view, you can also do " name is null
". But you cannot do that with a function (unless you write
unnecessary circumstancial code.)
While I agree with you on the view - among other things, it lets the
query optimiser p
Then you can do:
select *
from retrieve_user('foo', 'bar');
Personally I'd prefer to create view that wraps that select statement
and then simply do a
select *
from user_view
where name = 'foo'
and password = 'bar'
It is also better because with a view, you can also d
select abbrev,utc_offset,count(*) from pg_timezone_names
where abbrev='EST'
group by abbrev,utc_offset
There are 12 times zones with 'EST' code, offset = GMT+10. And there are
8 time zones with 'EST' code, offset= GMT+5 at the same time!
So how much it is supposed to be?
select now() at time
22 matches
Mail list logo
