Re: [GENERAL] Why are there no inequality scans for ctid?

Re: hubert depesz lubaczewski 2013-06-28 20130628085246.ga25...@depesz.com On Fri, Jun 28, 2013 at 02:21:10PM +0530, Atri Sharma wrote: How would this be helpful for general use cases? Querying on tids on a specific page doesn't seem too useful for any other case than the one you mentioned

Re: [GENERAL] Query runs forever after upgrading to 9.3

Re: Andrus 2013-09-23 E04C65FDEE80430DB6499621E2EC36BC@dell2 SELECT * FROM toode WHERE toode in (SELECT toode FROM tempkaive) OR toode in (SELECT toode FROM tempalgsemu) Generally, WHERE IN (SELECT) should be rewritten as WHERE EXISTS (SELECT): SELECT * FROM toode o WHERE EXISTS (SELECT

Re: [GENERAL] Moving some of Postgres off a SSD

Re: Robert James 2012-12-18 CAGYyBgiA8G5pqjfqrPqvAuo=iodeftfbl6spa187zfop+h6...@mail.gmail.com I have Postgres running on a SSD. The data is now almost 50GB, which is filling up the drive. How can I move some of the data to my HDD? Use a TABLESPACE. Christoph -- c...@df7cb.de |

Re: [GENERAL] postgresql command line exploit found in the wild

Re: Daniel Verite 2013-04-08 cd81d201-e9fa-4567-ac49-e3e762935747@mm Merlin Moncure wrote: if you have an internet facing database, patch it immediately! By the way: People running 9.1 on debian stable (squeeze) typically use this package:

Re: [GENERAL] Alternative to psql -c ?

Re: James Le Cuirot 2014-06-25 20140625144325.49d1124d@red.yakaraplc.local Hello, I've been using the Chef database cookbook and found it frustrating because it doesn't allow you to use peer authentication. The client process generally runs as root and connects to PostgreSQL using the Ruby

Re: [GENERAL] Best filesystem for a high load db

Re: Bill Moran 2014-11-25 20141125111630.d05d58a9eb083c7cf80ed...@potentialtech.com Anything with a journal is a performance problem. PostgreSQL effectivly does its own journalling with the WAL logs. That's not to say that there's no value to crash recovery to having a journalling filesystem,

Re: [GENERAL] Running pg_upgrade under Debian

Re: Peter Eisentraut 2015-04-24 553a3b85.1070...@gmx.net On 4/20/15 6:09 PM, Bruce Momjian wrote: On Mon, Apr 20, 2015 at 07:06:37PM -0300, Alvaro Herrera wrote: ISTM there's a documentation bug here: in the code, the dump method checks for tablespaces and raises an error if they are found,

Re: [GENERAL] Really unique session ID - PID + connection timestamp?

Re: Durumdara 2016-04-09 > In MS the session id is smallint, so it can repeats after server restarts, > but my coll. found a "session creation timestamp". > This is a key which unique. > With this we can check for died sessions

Re: [GENERAL] Really unique session ID - PID + connection timestamp?

Re: Stephen Frost 2016-04-09 <20160409115712.gt10...@tamriel.snowman.net> > > Btw, what you are describing is exactly what %c in log_line_prefix > > does. > > That's not currently exposed at an SQL level anywhere though, is it? > Perhaps we should add a way to get that. Another thought would be

Re: [GENERAL] Ubuntu/Debian PGDP

Re: Peter Eisentraut 2016-05-07 <6f86345a-0658-2cd9-27d9-c381846eb...@2ndquadrant.com> > On 5/7/16 2:43 AM, Vincenzo Romano wrote: > > In a fresh new install of PostgreSQL 9.5.2 on Ubuntu 16.04 I am getting > > this: > > > > ... > > Setting up postgresql-9.5 (9.5.2-1.pgdg16.04+1) ... > >

Re: [GENERAL] PGDATA / data_directory

Re: Benoit Lobréau 2016-08-31

Re: [GENERAL] PGDATA / data_directory

Re: Jehan-Guillaume de Rorthais 2016-09-07 <20160907140816.3e13eaa3@firost> > Indeed. I never noticed data_directory was set in postgresql.conf file... > > But then, why starting PostgreSQL with the following command ? > > /usr/lib/postgresql/9.4/bin/postgres -D /var/lib/postgresql/9.4/main \

Re: [GENERAL] could not connect to server

Re: Antonio Silva 2016-10-16 > 2016-10-15 06:15:20 BRT [995-1] FATAL: data directory > "/var/lib/postgresql/9.5/main" has group or world access > 2016-10-15 06:15:20 BRT [995-2] DETAIL: Permissions should be u=rwx (0700). > >

Re: [GENERAL] A change in the Debian install

Re: Magnus Hagander 2017-04-06 > On Thu, Apr 6, 2017 at 3:46 PM, Stephen Frost wrote: > > > * Tom Lane (t...@sss.pgh.pa.us) wrote: > > > (But ... these statements are based on an assumption of out-of-the- >

Re: [GENERAL] Where is pg_hba.conf

Re: Igor Korot 2017-08-13 > draft=# SHOW hba_file > draft-# SHOW hba_file; > ERROR: syntax error at or near "SHOW" > LINE 2: SHOW hba_file; > ^ Standard beginners error. If you forgot the ";" on the first

Re: [GENERAL] Where is pg_hba.conf

Re: Igor Korot 2017-08-13 > I need to modify the pg_hba.conf file to get access to the DB > remotely. > > However, I can't find this file anywhere on the system. Try "SHOW hba_file;". Christoph -- Sent via pgsql-general

Re: [GENERAL] ERROR: unexpected chunk number 0 (expected 1) for toast value 76753264 in pg_toast_10920100

Re: Harry Ambrose 2017-08-25 > Hi All, > > Sorry to open this can of worms again. However, we are still struggling > with this issue across quite a large amount of our estate. Hi, we've just seen exactly this error on a

Re: [GENERAL] pg on Debian servers

Re: Magnus Hagander 2017-11-11

Re: [GENERAL] Postgres 10.1 fails to start: server did not start in time

Re: Tom Lane 2017-11-10 <8027.1510347...@sss.pgh.pa.us> > > The recovery succeeds, but when I go to start the cluster on the > > standby, it begins to replay the WAL, and does so for about 30 > > seconds. Then I get a line in my log saying: > > >> pg_ctl: server did not start in time Hi Adam,

Re: [GENERAL] Postgres 10.1 fails to start: server did not start in time

Re: Adam Brusselback 2017-11-11

Re: [GENERAL] Postgres 10.1 fails to start: server did not start in time

Re: To Adam Brusselback 2017-11-11 <2017205316.u56lkmkakdmcx...@msg.df7cb.de> > I'm investigating if it's a good idea to tell systemd to ignore the > exit code of pg_ctl(cluster). Telling systemd to ignore ExecStart errors seems to be the correct solution. The service will still be active,

Re: [GENERAL] Postgres 10.1 fails to start: server did not start in time

Re: Peter J. Holzer 2017-11-12 <20171112173559.m6chmbyf4vz6f...@hjp.at> > Wouldn't it be better to remove the timeout? If some other service > depends on PostgreSQL it probably shouldn't be startet until PostgreSQL > is really up and services which don't need PostgreSQL (e.g. SSH or X11 > login or

Re: [GENERAL] Postgres 10.1 fails to start: server did not start in time

Re: Tom Lane 2017-11-12 <20802.1510513...@sss.pgh.pa.us> > Agreed, but I think Peter has a point: why is there a timeout at all, > let alone one as short as 30 seconds? Since systemd doesn't serialize > service starts unnecessarily, there seems little value in giving up > quickly. And we know