"Anand Kumar, Karthik" wrote:
> We finally made some headway on this - we noticed messages like
> the below
> in /var/log/messages whenever the issue happened:
>
> Mar 26 07:39:58 site-db01b kernel: postmaster: page allocation failure.
> Anyone have any idea why memory was so fragmented, and wh
You're right. This was my error.
Sent from my iPhone
> On Apr 7, 2014, at 8:53 PM, Tom Lane wrote:
>
> Robert DiFalco writes:
>> Is there any way to set the timezone of the postgres server differently
>> than the OS? I *have* tried setting timezone = 'UTC' in my postgresql.conf
>> file but th
Robert DiFalco writes:
> Is there any way to set the timezone of the postgres server differently
> than the OS? I *have* tried setting timezone = 'UTC' in my postgresql.conf
> file but that seems to be a VIEW of time zone. It doesn't seem to behave
> the same as running a postgresql server on a ma
On Tue, Apr 8, 2014 at 12:33 PM, Gaurav Jindal wrote:
> How to import the .sql file using PSQL or PgAdmin? Can anyone guide me with
> details and step by step instructions.
>
> I tried \i filename.sql command but permission denied. I don't know how to
> make it work. Can anyone helps me out. Thank
Is there any way to set the timezone of the postgres server differently
than the OS? I *have* tried setting timezone = 'UTC' in my postgresql.conf
file but that seems to be a VIEW of time zone. It doesn't seem to behave
the same as running a postgresql server on a machine that is in UTC. The
machin
How to import the .sql file using PSQL or PgAdmin? Can anyone guide me with
details and step by step instructions.
I tried \i filename.sql command but permission denied. I don't know how to
make it work. Can anyone helps me out. Thanks!
Gaurav
On Tue, Apr 08, 2014 at 12:46:37AM +0200, Stefan Keller wrote:
> Hi Andrew
>
> 2014-04-07 23:37 GMT+02:00 Andrew Sullivan wrote:
> > (1) this has been discussed many times in the past (...)
>
> Can you point me to one of these discussions?
>
> Actually, I browsed once again the mailing list and
Hi Andrew
2014-04-07 23:37 GMT+02:00 Andrew Sullivan wrote:
> (1) this has been discussed many times in the past (...)
Can you point me to one of these discussions?
Actually, I browsed once again the mailing list and this is one of the few
posts I found:
"In-Memory Columnar Store" 9.12.13 by kni
On Mon, Apr 7, 2014 at 6:46 PM, Nithya Soman
wrote:
> How can we find the total row count for all db tables in psql version 7.4.3
> ??
Are you aware that 7.4 is EOL for 5 years? 7.4.3 is missing as well at
least 4 years of bug fixes in its stable branch.
> The query which worked fine in psql 9.2
Hi Jeff
Unfortunately it's not just the one particular query, there's no pattern
that I can see besides the time they're being executed.
We did go from Autovac only to nightly vac. I'm going to implement autovac
again, we've been operating without for a few months now. Will run both
nightly manua
On Mon, Apr 07, 2014 at 10:43:58PM +0200, Stefan Keller wrote:
> running out-of-memory [1][2] - i.e. pretty much what has been discussed
> here - although little bit reluctantly :-)
It is just possible that some of the reluctance is because (1) this
has been discussed many times in the past, partl
Hi Hadi, hi all
It makes sense to me to design cstore_fdw for volume of data which is
larger than main memory.
Coming back to my original thread, I'd like to ponder further on what makes
in-memory special - and how to configure or extend Postgres to implement
that.
I found e.g. some brand new fu
On Mon, Apr 7, 2014 at 3:58 AM, Rebecca Clarke wrote:
> Thanks, I'll run the EXPLAIN (ANALYZE, BUFFERS) today and tomorrow
> morning. I just tried it now on a query that took 109035.116 ms this
> morning (Which returns one row). It has returned 675.496 ms. I will run
> on this same query at 5am t
On 04/05/2014 08:47 AM, Andy Colson wrote:
Hi All.
I've started using replication, and I'd like to monitor my logs for
any errors or problems. I don't want to do it manually, and I'm not
interested in stats (a la PgBadger).
What I'd like, is the instant PG logs: "FATAL: wal segment already
Hey Stefan,
@Hadi: Can you say something about usage of cstore FDW in-memory?
>
>
We designed cstore_fdw with the applications in mind where volume of data
is much larger than main memory. In general, columnar stores usually bring
two benefits:
1. Doing less disk I/O than row stores. We can skip
On 04/07/2014 07:48 AM, Sofer, Yuval wrote:
Hi,
Postgres server (9.2.8) crash on Windows sporadically
Usually it happens after machine reboot that we do, once in a day
After ~4 minutes it crashes with this error in the log:
2014-04-06 08:08:01.069 GMTLOG: server process (PID 5304) exited wit
Hi
How can we find the total row count for all db tables in psql version
7.4.3 ??
The query which worked fine in psql 9.2 version is :
SELECT schemaname,relname,n_live_tup FROM pg_stat_user_tables ORDER BY
n_live_tup DESC.
But same query throws error as 'ERROR: column "n_live_tup" does not exis
Thanks Tom, that worked!
On Mon, Mar 24, 2014 at 8:47 PM, Tom Lane wrote:
> Ilya Ivanov writes:
> > I need to find all active (status=0) items not belonging to any active
> > trigger. The best I could come up with is this:
>
> > select count(itemid) from items where status='0' and itemid not i
On 04/07/2014 07:48 AM, Sofer, Yuval wrote:
Hi,
Postgres server (9.2.8) crash on Windows sporadically
Usually it happens after machine reboot that we do, once in a day
After ~4 minutes it crashes with this error in the log:
2014-04-06 08:08:01.069 GMTLOG: server process (PID 5304) exited wit
Hi,
Postgres server (9.2.8) crash on Windows sporadically
Usually it happens after machine reboot that we do, once in a day
After ~4 minutes it crashes with this error in the log:
2014-04-06 08:08:01.069 GMTLOG: server process (PID 5304) exited with exit
code 0
2014-04-06 08:08:01.069 GMTLOG:
On Mon, Apr 7, 2014 at 6:14 AM, Andrew Sullivan wrote:
> On Mon, Apr 07, 2014 at 10:32:59AM +0100, Rebecca Clarke wrote:
>
>> normally execute promptly, are taking a long time when they are executed
>> first thing in the morning (after the database has been inactive for
>> several hours). After th
howardn...@selestial.com wrote:
>> http://www.postgresql.org/docs/current/static/collation.html#AEN33298
>> The ordering depends on the collation. Which collations are available
>> and how they order depends on your operating system. What is your OS
>> and what do you get for SHOW lc_collate; Yours
On Mon, Apr 07, 2014 at 10:32:59AM +0100, Rebecca Clarke wrote:
> normally execute promptly, are taking a long time when they are executed
> first thing in the morning (after the database has been inactive for
> several hours). After the first execution, everything is back to normal.
Just guessin
On 07/04/2014 11:58, Albe Laurenz wrote:
http://www.postgresql.org/docs/current/static/collation.html#AEN33298
The ordering depends on the collation. Which collations are available
and how they order depends on your operating system. What is your OS
and what do you get for SHOW lc_collate; Your
Thanks, I'll run the EXPLAIN (ANALYZE, BUFFERS) today and tomorrow morning.
I just tried it now on a query that took 109035.116 ms this morning (Which
returns one row). It has returned 675.496 ms. I will run on this same query
at 5am tomorrow. Thank you.
At present we run pg_dumps every three hour
howardn...@selestial.com wrote:
> just as I thought I had postgres mastered :) the ordering of strings is
> causing me some confusion.
>
> Can someone explain how the database orders strings in the ORDER BY command.
>
> My example:
>
> My database is encoding is UTF-8, and default language is e
Hi,
just as I thought I had postgres mastered :) the ordering of strings is
causing me some confusion.
Can someone explain how the database orders strings in the ORDER BY command.
My example:
My database is encoding is UTF-8, and default language is english,
If I have a text column in a ta
Rebecca Clarke wrote:
> I'm a bit stumped. At present I'm finding that queries to my database, that
> normally execute promptly,
> are taking a long time when they are executed first thing in the morning
> (after the database has been
> inactive for several hours). After the first execution, ever
On Mon, Apr 7, 2014 at 3:02 PM, Rebecca Clarke wrote:
> Hi all.
>
> I'm a bit stumped. At present I'm finding that queries to my database,
> that normally execute promptly, are taking a long time when they are
> executed first thing in the morning (after the database has been inactive
> for sever
Hi all.
I'm a bit stumped. At present I'm finding that queries to my database, that
normally execute promptly, are taking a long time when they are executed
first thing in the morning (after the database has been inactive for
several hours). After the first execution, everything is back to normal.
Hi,
I wrote
> Finally the paper is mostly about column stores - nothing about
persistence.
Regarding column store, Hadi wrote 2014-04-03 18:43 GMT+02:00 about the
release of a PostgreSQL Columnar Store called "cstore_fdw" [1]!
@Hadi: Can you say something about usage of cstore FDW in-memory?
Re
Hi Florian
Thanks for the remark. I've seen recently somebody from the "core" team
(was it at PgCon Rev Meeting [1] or a blog) mentioning it meaning to revive
it?
Yours, Stefan
[1] http://wiki.postgresql.org/wiki/PgCon_2013_Developer_Meeting
2014-04-07 8:15 GMT+02:00 Florian Weimer :
> On 04
On 04/02/2014 12:32 AM, Stefan Keller wrote:
It also mentions an insert-only technique: "This approach has been
adopted before in POSTGRES [21] in 1987 and was called "time-travel".
I would be interested what "time-travel" is and if this is still used by
Postgres.
Back in the old days, Postgre
33 matches
Mail list logo
