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, but the
>> "upgrade" method does not check. I think t
Hi PG List,
I'm missing something or haven't had enough coffee yet. What gives with
the COALESCE in the view below?
mxl_sqr=# \d users
Table "public.users"
Column | Type | Modifiers
-+-+---
user_id | integer | not null
Indexes:
"users_pkey" PRIMARY KEY, btr
You probably mean ts2.user_id not ts2, user_id, right?
Best regards
Holger Friedrich
From: pgsql-general-ow...@postgresql.org
[mailto:pgsql-general-ow...@postgresql.org] On Behalf Of Greg Spiegelberg
Sent: Friday, April 24, 2015 3:07 PM
To: pgsql-general@postgresql.org >> PG-General Mailing List
Color me embarrassed. Must have been the lack of coffee.
Thanks to all who responded!
-Greg
On Fri, Apr 24, 2015 at 7:09 AM,
wrote:
> You probably mean ts2.user_id not ts2, user_id, right?
>
>
>
> Best regards
>
> Holger Friedrich
>
>
>
> *From:* pgsql-general-ow...@postgresql.org [mailto:
>
On 04/24/2015 08:06 AM, Greg Spiegelberg wrote:
Hi PG List,
I'm missing something or haven't had enough coffee yet. What gives with the
COALESCE in the view below?
mxl_sqr=# \d users
Table "public.users"
Column | Type | Modifiers
-+-+---
SELECT COALESCE(ts1.user_id, ts2,user_id, ts3.user_id) AS user_id,
That should probably be ts2 DOT user_id.
Cheers,
Andomar
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
On Fri, Apr 24, 2015 at 9:06 AM, Greg Spiegelberg
wrote:
> *LINE 3: SELECT COALESCE(ts1.user_id, ts2,user_id, ts3.user_id) AS us...*
>
You want ts2.user_id not ts2,user_id
Postgresql is running on a 30 Gb of memory server.
I should have access to the server in few minutes and I'll give you more
information about the other spec.
Thanks
Marc
-Message d'origine-
De : pgsql-general-ow...@postgresql.org
[mailto:pgsql-general-ow...@postgresql.org] De la part d
Server setting
kernel.shmmax = 13322600448
kernel.shmall = 4194304
vm.swappiness = 60
vm.overcommit_memory = 0
vm.overcommit_ratio = 50
Postgresql setting
effective_cache_size| 128MB
checkpoint_segments | 64
maintenance_work_mem| 5GB
segment_size
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 the
Hi friends, I'm traveling to Miami first week of May, I was looking
for some group of PostgreSQL fans there but i didn't found it, if
somebody is there (I'm at Miami Beach) and wants to drink a beer with
me, I am very happy to be in contact, you can write me to this email.
I'm one of the organizer
> I use Postgis and PGrouting extension.
> The error come when I use a pgrouting function pgr_createtopology()
It appears pgrouting violates the 1GB per chunk limit in the postgres backend
when processing large datasets:
https://github.com/pgRouting/pgrouting/issues/291
Bye,
Chris.
--
Sent
On 4/23/15 5:49 PM, Andrey Lizenko wrote:
Can VACUUM be a reason of xact_rollback increasing?
I don't think so, not without generating some kind of error.
What could be happening is plpgsql catching exceptions. A BEGIN block
with an EXCEPTION handle creates an implicit subtransaction (savepoi
13 matches
Mail list logo
