On Dec 3, 2013, at 3:53 PM, Andreas Brandl wrote:
> John,
>
>> ...
>> For a variety of reasons I would prefer disk usage to be as low as
>> possible, thus I would like to run a VACUUM FULL during some
>> maintenance cycle (since it exclusively locks the table). However,
>
> you might want to
John,
> Due to running low on disk space, we have recently removed a majority
> of rows from a table to an archival DB.
>
> Although VACUUM allows disk space to be re-used, VACUUM FULL is the
> only one that actively reclaims disk space for use by the OS.
> http://www.postgresql.org/docs/9.0/sta
On Dec 3, 2013, at 2:15 PM, Tom Lane wrote:
> Steven Schlansker writes:
>> I’ve seen murmuring on the list regarding
>> https://wiki.postgresql.org/wiki/Nov2013ReplicationIssue
>
>> Is there an ETA on a release with the bug fix for this? I’m putting off
>> building from source because I pre
Steven Schlansker writes:
> Ive seen murmuring on the list regarding
> https://wiki.postgresql.org/wiki/Nov2013ReplicationIssue
> Is there an ETA on a release with the bug fix for this? Im putting off
> building from source because I prefer to use the pgdg RPM packages, but if we
> dont ge
Due to running low on disk space, we have recently removed a majority of rows
from a table to an archival DB.
Although VACUUM allows disk space to be re-used, VACUUM FULL is the only one
that actively reclaims disk space for use by the OS.
http://www.postgresql.org/docs/9.0/static/routine-vac
Hi everyone,
I’ve seen murmuring on the list regarding
https://wiki.postgresql.org/wiki/Nov2013ReplicationIssue
Is there an ETA on a release with the bug fix for this? I’m putting off
building from source because I prefer to use the pgdg RPM packages, but if we
don’t get a release soon it mig
2013/12/2 Tom Lane
> Zev Benjamin writes:
> > This actually looks to mostly be a parser limitation:
>
> Well, you'd also need some execution-time infrastructure to evaluate an
> expression, if we allowed one there, but I agree it wouldn't be a
> tremendously complicated patch. We'd just not for
We recently experienced crash on out postgres production server. Here's our
server environment:
- Postgres 9.3
- in OpenVZ container
- total memory: 64GB
Here's the error snippet from postgres log:
ERROR: could not read block 356121 in file "base/33134/33598.2": Bad
address
LOG: server proces
I'll probably go by using 3 queries and putting them in a transaction.
Thanks
On Wed, Nov 27, 2013 at 5:38 PM, David Johnston wrote:
> Dorian Hoxha wrote
> > Hi,
> >
> > So i have (table where data will be read) :
> > CREATE TABLE data (vid,cid,pid,number);
> >
> > Tables where data will be wr
I need advise about where is best place for adding such features.
Currently I found that 'postmaster' have event loop(including handling
SIGHUP) inside PostgressMain(postgress.c) for realoding configuration
file, based on my investigation my plan is handling ldap events just before
SIGHUP.
PS I
On Mon, 2 Dec 2013 15:46:17 -0800, Nick wrote:
[...]
> This is what I have currently for the line that I am specifically talking
> about:
>
> INSERT INTO club_Games(memberID, gameID, hardwareID, count, status)
>VALUES ((SELECT memberID FROM members WHERE name = 'Fred Flinstone'),
> (SELEC
11 matches
Mail list logo