On 12 September 2015 at 05:21, Charles Lynch
wrote:
> We have, just recently, ran into a problem. I created a test cluster only
> within NV and after about a week of working without any problems, we got an
> error: Unexpected EOF on SSL connection. I had seen something like this
> before but on i
El 13/09/15 a las 18:20, Jan de Visser escribió:
>
> Try
>
> jan@bison:~$ sudo -u postgres -s
> postgres@bison:~$ psql
> psql (9.4.4)
> Type "help" for help.
>
> postgres=# ALTER USER postgres PASSWORD 'postgres';
> ALTER ROLE
> postgres=# \q
I would recommend using psql's \password meta-comman
On 10/09/15 06:40, Jeff Janes wrote:
> Vacuuming will allow the space to be reused internally. It will not
> visibly shrink the index, but will mark that space as eligible for reuse.
>
> If you have a 36GB index and a reindex would have reduced it to 15GB,
> then a vacuum will leave it at 36GB b
On September 14, 2015 07:22:58 AM Martín Marqués
wrote:
> I would recommend using psql's \password meta-
command instead of ALTER
> USER to change a password, as to avoid having the
password stamped in
> the logs.
You learn something new every day :-)
jan
Hi Christian:
On Mon, Sep 14, 2015 at 1:54 PM, Christian Ramseyer wrote:
> I agree with your append-only and disposable partition approach, it
> would work a lot better. The idea with using a second schema for
> selective backups is great, I'll totally steal this :)
Feel free. Just remember if y
Hi,
Im running:
PostgreSQL 9.4.4 on x86_64-unknown-linux-gnu, compiled by gcc (GCC) 4.9.2
20150212 (Red Hat 4.9.2-6), 64-bit
I make use of table inheritance. I've created a table, added a
child table, and after that added a column to the parent table
(example code below).
As you can see below
On September 14, 2015 07:22:58 AM Martín Marqués
wrote:
> I would recommend using psql's \password meta-
command instead of ALTER
> USER to change a password, as to avoid having the
password stamped in
> the logs.
You learn something new every day :-)
jan
On Mon, Sep 14, 2015 at 11:11 AM, Ingmar Brouns wrote:
>
> However, when I dump the schema using pg_dump, and then load the
> resulting sql file, suddenly 'c' does follow 'a'. So restoring my
> schema has changed my table's layout. I feel dumping and loading
> should not alter column positions. A
Oh, and don't reply to people individually. I'm going to move this to
-general with one last copy for -bugs even though it is not one.
On Mon, Sep 14, 2015 at 3:01 PM, David G. Johnston <
david.g.johns...@gmail.com> wrote:
> On Mon, Sep 14, 2015 at 2:55 PM, Biswadeep Banerjee <
> biswadeep.baner
El 14/09/15 a las 06:37, Craig Ringer escribió:
>
> Support is focused mainly on RHEL/CentOS/Fedora, but Debian/Ubuntu
> packages are also produced. We're a little behind at the moment and
> haven't got 0.9.2 packages out. I'll be pushing 0.9.3 soon and will
> produce 0.9.3 packages for Debian/Ubun
On 9/14/15 11:59 AM, David G. Johnston wrote:
On Mon, Sep 14, 2015 at 11:11 AM, Ingmar Brouns mailto:swi...@gmail.com>>wrote:
However, when I dump the schema using pg_dump, and then load the
resulting sql file, suddenly 'c' does follow 'a'. So restoring my
schema has changed my tabl
On 9/12/15 9:38 AM, Daniel Verite wrote:
"seriously flawed" is a bit of a stretch. Most sane developers would not
>have schema names of one letter.
>They usually name a schema something practical, which totally avoids your
>nit picky exception.
That's confusing the example with the problem it sh
Jim,
Have you actually tried this, or is it just a theory? AFAIK, the function
will work because only the schema name is changed.. So please provide
a full working example of a function that fails and I will attempt a
solution.
On Mon, Sep 14, 2015 at 6:36 PM, Jim Nasby wrote:
> On 9/12/15 9:38
Actually, on further thought, you example shows that it works correctly
because we do want all references to the old schema to be changed to the
new schema, since all copies of functions will now reside in the new
schema. Otherwise, there is no point of duplicating those functions.
On Mon, Sep 14,
We're in a situation where we would like to take advantage of the pgpass
hostname field to determine which password gets used. For example:
psql -h prod-server -d foo # should use the prod password
psql -h beta-server -d foo # should use the beta password
This would *seem* to be simple, just put
15 matches
Mail list logo
