Hello,
Thanks for helpful answers and sharing all of your knowledge about this
issue. Your knowledge gave me ideas and made it more clear.
Thank all of you again.
Best regards,
Gunce
On Fri, Apr 7, 2017 at 6:30 PM, Guillaume Lelarge
wrote:
> Le 7 avr. 2017 4:58 PM, "Alban Hertroys" a écrit
Please see below.
- Original Message -
From: "Nicolas Paris"
To: "Steve Petrie, P.Eng."
Cc:
Sent: Sunday, April 09, 2017 7:58 AM
Subject: Re: [GENERAL] TimeScaleDB -- Open Source Time Series Database
Released (www.i-programmer.info);
Le 09 avril 2017 à 05:31, Steve Petrie, P.Eng
John Iliffe wrote:
> >
> >
> Basically, nothing.
>
> If I include it in an Apache script exactly as suggested, then the script
> puts out a blank screen, no error messages.
So from the point of view of the Apache process, that file does
not exist. That's consistent with the error y
John Iliffe wrote:
> Based on the reference that Joe sent earlier, I do have a second domain
> socket on /var/pgsql but the problem is how do I get PHP to look there?
pg_connect("host=/var/pgsql [...other parameters...]")
The fact that the value for host starts with a slash indicate
2017-04-06 17:51 GMT+02:00 Tom DalPozzo :
>
>
> 2017-04-04 19:18 GMT+02:00 Scott Marlowe :
>
>> On Tue, Apr 4, 2017 at 9:46 AM, Tom DalPozzo
>> wrote:
>> > Hi,
>> > I have a very big table (10GB).
>> > I noticed that many WAL segments are being written when elaborating read
>> > only transactions
On Sunday 09 April 2017 22:07:12 rob stone wrote:
> On Sun, 2017-04-09 at 20:09 -0400, John Iliffe wrote:
> > >
> > >
> > > You have Apache, PHP, and Postgres all running on your LAN at
> > > 192.168.1.6.
> > >
> > >
> > >
> > >
> > > You are on 192.168.1.10.
> > >
> > >
> > >
> > > Your NOT do
On Sunday 09 April 2017 23:21:58 Adrian Klaver wrote:
> On 04/09/2017 05:30 PM, John Iliffe wrote:
> > On Sunday 09 April 2017 20:01:32 Adrian Klaver wrote:
> >> So the issue is in PHP via Apache using the socket, because if I
> >> remember right you used localhost in the Apache/PHP combination and
> >> On Tue, Apr 4, 2017 at 9:46 AM, Tom DalPozzo
> >> wrote:
> >> > Hi,
> >> > I have a very big table (10GB).
> >> > I noticed that many WAL segments are being written when elaborating read
> >> > only transactions like this:
> >> > select * from dati256 where id >4300 limit 100
On Monday 10 April 2017 09:46:54 Daniel Verite wrote:
> John Iliffe wrote:
> > Based on the reference that Joe sent earlier, I do have a second
> > domain socket on /var/pgsql but the problem is how do I get PHP to
> > look there?
>
> pg_connect("host=/var/pgsql [...other parameters...]")
On Monday 10 April 2017 09:46:54 Daniel Verite wrote:
> John Iliffe wrote:
> > Based on the reference that Joe sent earlier, I do have a second
> > domain socket on /var/pgsql but the problem is how do I get PHP to
> > look there?
>
> pg_connect("host=/var/pgsql [...other parameters...]")
John Iliffe wrote:
> So, the problem is resolved, although I have no idea why it was necessary.
The key seems to be the PrivateTmp=true in the systemd service.
Apache is not chrooted as demonstrated upthread, but that
setting alone makes the normal, system-wide /tmp inaccessible
to its
Il 03/04/2017 18:10, Joe Conway ha scritto:
On 03/31/2017 01:58 AM, Moreno Andreo wrote:
Il 30/03/2017 14:38, Vick Khera ha scritto:
On Thu, Mar 30, 2017 at 6:10 AM, Moreno Andreo
mailto:moreno.and...@evolu-s.it>> wrote:
Since I'm on Google Cloud Platform, I thought it would be a good
Il 03/04/2017 22:32, Alex Kliukin ha
scritto:
as it makes little sense to build an aircraft carrier
to carry a single Cessna.
:-) A bit extreme, but it makes the idea ...
Thanks
Moreno.-
Kind
2017-04-10 16:49 GMT+02:00 Bill Moran :
>
> > >> On Tue, Apr 4, 2017 at 9:46 AM, Tom DalPozzo
> > >> wrote:
> > >> > Hi,
> > >> > I have a very big table (10GB).
> > >> > I noticed that many WAL segments are being written when elaborating
> read
> > >> > only transactions like this:
> > >> > sele
On Sun, Apr 9, 2017 at 4:27 PM, Guyren Howe wrote:
>
> If I do a SELECT with a GROUP_BY and multiple ARRAY_AGGs, will the ARRAY_AGGs
> be guaranteed to have entries in the same (ie corresponding) order?
>
> eg
>
> SELECT
> u.name,
> ARRAY_AGG(o.order_date) AS order_dates,
> ARRAY_AGG(o.order_tota
Merlin Moncure writes:
> On Sun, Apr 9, 2017 at 4:27 PM, Guyren Howe wrote:
>> If I do a SELECT with a GROUP_BY and multiple ARRAY_AGGs, will the
>> ARRAY_AGGs be guaranteed to have entries in the same (ie corresponding)
>> order?
>>
>> eg
>>
>> SELECT
>> u.name,
>> ARRAY_AGG(o.order_date) AS
On 04/10/2017 09:33 AM, Merlin Moncure wrote:
On Sun, Apr 9, 2017 at 4:27 PM, Guyren Howe wrote:
If I do a SELECT with a GROUP_BY and multiple ARRAY_AGGs,
>> will the ARRAY_AGGs be guaranteed to have entries in the
>> same (ie corresponding) order?
It is unsafe to rely on aggregation order un
On Mon, Apr 10, 2017 at 12:01 PM, Tom Lane wrote:
> Merlin Moncure writes:
>> On Sun, Apr 9, 2017 at 4:27 PM, Guyren Howe wrote:
>>> If I do a SELECT with a GROUP_BY and multiple ARRAY_AGGs, will the
>>> ARRAY_AGGs be guaranteed to have entries in the same (ie corresponding)
>>> order?
>>>
>>>
On Mon, Apr 10, 2017 at 11:02 AM, Merlin Moncure wrote:
> On Mon, Apr 10, 2017 at 12:01 PM, Tom Lane wrote:
> > Merlin Moncure writes:
> >> On Sun, Apr 9, 2017 at 4:27 PM, Guyren Howe wrote:
> >>> If I do a SELECT with a GROUP_BY and multiple ARRAY_AGGs, will the
> ARRAY_AGGs be guaranteed to
"David G. Johnston" writes:
> On Mon, Apr 10, 2017 at 11:02 AM, Merlin Moncure wrote:
>> Sure, but isn't it fair to consider that an implementation artifact?
> So, the presence of ORDER BY in the aggregate function call is a PostgreSQL
> extension...
> It seems reasonable to declare that the or
On Mon, Apr 10, 2017 at 1:35 PM, Tom Lane wrote:
> "David G. Johnston" writes:
>> On Mon, Apr 10, 2017 at 11:02 AM, Merlin Moncure wrote:
>>> Sure, but isn't it fair to consider that an implementation artifact?
>
>> So, the presence of ORDER BY in the aggregate function call is a PostgreSQL
>> e
On 04/10/2017 11:35 AM, Tom Lane wrote:
I'm not very keen on recommending that the OP insert an ORDER BY into
each aggregate call, because that would cause a separate sort for each
aggregate (unless someone's improved that recently while I wasn't
looking).
I mentioned this in my other email, up
On Mon, Apr 10, 2017 at 1:43 PM, Merlin Moncure wrote:
> On Mon, Apr 10, 2017 at 1:35 PM, Tom Lane wrote:
>>
>> Yes, and in fact we documented the ORDER-BY-in-subselect solution back
>> before we had the ORDER-BY-in-aggregate feature. I don't remember exactly
>> where, but I'm sure it's still de
Paul Jungwirth writes:
> On 04/10/2017 11:35 AM, Tom Lane wrote:
>> I'm not very keen on recommending that the OP insert an ORDER BY into
>> each aggregate call, because that would cause a separate sort for each
>> aggregate (unless someone's improved that recently while I wasn't
>> looking).
> I
On Monday 10 April 2017 11:53:35 Daniel Verite wrote:
> John Iliffe wrote:
> > So, the problem is resolved, although I have no idea why it was
> > necessary.
>
> The key seems to be the PrivateTmp=true in the systemd service.
> Apache is not chrooted as demonstrated upthread, but that
> sett
On 4/10/2017 2:23 PM, John Iliffe wrote:
On Monday 10 April 2017 11:53:35 Daniel Verite wrote:
John Iliffe wrote:
Given that you set two directories: /tmp and /var/pgsql,
I would think you can let the other apps use /tmp as before
and have only Apache use /var/pgsql ?
Yes, I will do
On 04/10/2017 01:23 PM, John Iliffe wrote:
On Monday 10 April 2017 11:53:35 Daniel Verite wrote:
John Iliffe wrote:
So, the problem is resolved, although I have no idea why it was
necessary.
The key seems to be the PrivateTmp=true in the systemd service.
Apache is not chrooted as demo
John Iliffe wrote:
> Yes, I will do that, but there are several hundred PHP web page scripts to
> be updated. Presumably if one script opens two different databases then
> both of the pg_connect() instances will need to be updated.
If you have many calls to pg_connect() without a host
Hello John,
On Mon, 2017-04-10 at 16:23 -0400, John Iliffe wrote:
> On Monday 10 April 2017 11:53:35 Daniel Verite wrote:
> > John Iliffe wrote:
> > > So, the problem is resolved, although I have no idea why it was
> > > necessary.
> >
>
Good to hear.
> >
>
> Yes, I will do that, but t
Thanks for the idea Rick. It hadn't occurred to me; might have at about
the 200th page :-(
John
=
On Monday 10 April 2017 16:46:14 Rick Widmer wrote:
> On 4/10/2017 2:23 PM, John Iliffe wrote:
> > On Monday 10 April 2017 11:53:35 Daniel Verite wrote:
> >>J
On 04/10/2017 01:23 PM, John Iliffe wrote:
On Monday 10 April 2017 11:53:35 Daniel Verite wrote:
John Iliffe wrote:
So, the problem is resolved, although I have no idea why it was
necessary.
The key seems to be the PrivateTmp=true in the systemd service.
Apache is not chrooted as demo
On 04/10/2017 01:23 PM, John Iliffe wrote:
On Monday 10 April 2017 11:53:35 Daniel Verite wrote:
John Iliffe wrote:
So, the problem is resolved, although I have no idea why it was
necessary.
The key seems to be the PrivateTmp=true in the systemd service.
Apache is not chrooted as demo
Hi All,
I created an out-db raster using the following syntax:
raster2pgsql -s {srid} -c -R -I -C -F -t auto {absolute_file_path}
public.{table} | psql -h {host} -p {port} -d {database} -U {user}
The table was created successfully. I wanted to confirm that the actual
file is being read from the
Hi,
I am trying to use the raster2pgsql tool to import raster images in MrSID
format to PostGIS database on a Windows system. However, I get an error
indicating that the format is not supported which I could confirm by
running:
raster2pgsql -G
Please, could someone help with the basic steps to fo
34 matches
Mail list logo
