Dear Harry.
You can try this while you are waiting the better solution from Prof. Kevin
Grittner. We did not improve because we do not know if we are in the right
way...
https://www.postgresql.org/message-id/caau9oxsb5gy8lz12kqaa3r1iv19c7famnefixdac1fhrfyt...@mail.gmail.com
You can downloat the
Try using double colon opperator instead of cast().
E. g. task_start::date
Regards,
Amul
Sent from a mobile device. Please excuse brevity and tpyos.
On Mon, 5 Sep, 2016 at 8:29 am, Patrick
2016-09-05 15:17 GMT+12:00 Patrick B :
>
>> You might want to share the version of PostgreSQL you are using.
>>
>> You might want to try date_trunc and AT TIMEZONE function/operators-
>>
>> https://www.postgresql.org/docs/9.4/static/functions-datetim
>> e.html#FUNCTIONS-DATETIME-TRUNC
>>
>> SELECT
2016-09-05 5:17 GMT+02:00 Patrick B :
>
>> You might want to share the version of PostgreSQL you are using.
>>
>> You might want to try date_trunc and AT TIMEZONE function/operators-
>>
>> https://www.postgresql.org/docs/9.4/static/functions-datetim
>> e.html#FUNCTIONS-DATETIME-TRUNC
>>
>> SELECT
>
>
> You might want to share the version of PostgreSQL you are using.
>
> You might want to try date_trunc and AT TIMEZONE function/operators-
>
> https://www.postgresql.org/docs/9.4/static/functions-
> datetime.html#FUNCTIONS-DATETIME-TRUNC
>
> SELECT date_trunc('day', tasks_start at TIME ZONE 'E
Patrick B writes:
> I'm trying to cast the date, using this query:
>> SELECT cast(tasks_start as date) FROM "jobs" WHERE "tasks"."deleted" = 'f'
>> AND "tasks"."recurrence_id" = 1 AND (Date(tasks_start) in ('2016-08-10')
> but it doesn't work.. I get 0 rows... what am I doing wrong?
Are you sure
On Mon, Sep 5, 2016 at 10:59 AM Patrick B wrote:
> Hi guys,
>
> I got the tasks table that has the tasks_start column:
>
>> tasks_start| timestamp(3) without time zone
>
>
>
> select tasks_start from tasks LIMIT 1;
>
>> tasks_start
>> ---
>> 2016-08-10 00:30:00
>
>
> I'm
Hi guys,
I got the tasks table that has the tasks_start column:
> tasks_start| timestamp(3) without time zone
select tasks_start from tasks LIMIT 1;
> tasks_start
> ---
> 2016-08-10 00:30:00
I'm trying to cast the date, using this query:
> SELECT cast(tasks_start a
On 31 August 2016 at 22:38, Salvatore Tomaselli
wrote:
> Hello,
>
> I have been looking around in the documentation and I didn't find anything,
> so I wonder if there is support in bdr for having transactions that happen
> while the global lock is acquired and get replicated everywhere before th
Hi guys,
You can actually reduce the time more by pre-syncing to the new location.
something like:
rsync -va /var/lib/pgsql/ /var/lib/pgsql2/
service postgres stop
rsync -va /var/lib/pgsql/ /var/lib/pgsql2/
The second rsync will only copy the deltas from the first, it still has to
> go in an
On 04/09/16 19:33, Lukas Lehner wrote:
Hi
when I use a search engine for the term "Postgres Certification"
this page shows up
https://www.postgresql.org/about/news/333/
please remove that, very much outdated. The referenced link doesn't
exist anymore (404 No such domain)
In all fairness, th
On 09/04/2016 12:55 PM, Rich Shepard wrote:
On Sun, 4 Sep 2016, Adrian Klaver wrote:
Another thing that came to mind is compatibility with existing
applications/clients. You say you have been running using trust and I am
betting your client connection parameters reflect that. Now for
connection
On Sun, 4 Sep 2016, Adrian Klaver wrote:
Another thing that came to mind is compatibility with existing
applications/clients. You say you have been running using trust and I am
betting your client connection parameters reflect that. Now for
connections methods that can 'see' the .pgpass file and
On 09/04/2016 12:42 PM, Rich Shepard wrote:
On Sun, 4 Sep 2016, Adrian Klaver wrote:
Well first, if you are going to use trust as your auth method then
specifying a password is moot exercise.
I tried adding an explicit password to ~/.pgpass with md5 as the auth
method, but that didn't work
On 09/04/2016 12:10 PM, Rich Shepard wrote:
On Sun, 4 Sep 2016, Adrian Klaver wrote:
You don't it directly. That information is supplied by Postgres when you
do CREATE or ALTER ROLE. The -W switch just does that for the
superuser(postgres in your case) when you initdb a new cluster.
Adrian,
On Sun, 4 Sep 2016, Adrian Klaver wrote:
Well first, if you are going to use trust as your auth method then specifying
a password is moot exercise.
I tried adding an explicit password to ~/.pgpass with md5 as the auth
method, but that didn't work so I went back to trust. That's served well f
On 09/04/2016 12:10 PM, Rich Shepard wrote:
On Sun, 4 Sep 2016, Adrian Klaver wrote:
You don't it directly. That information is supplied by Postgres when you
do CREATE or ALTER ROLE. The -W switch just does that for the
superuser(postgres in your case) when you initdb a new cluster.
Adrian,
On Sun, 4 Sep 2016, Adrian Klaver wrote:
You don't it directly. That information is supplied by Postgres when you
do CREATE or ALTER ROLE. The -W switch just does that for the
superuser(postgres in your case) when you initdb a new cluster.
Adrian,
OK. That makes sense.
Sorry, old habits.
On 09/04/2016 09:43 AM, Rich Shepard wrote:
On Sun, 4 Sep 2016, Adrian Klaver wrote:
-W is not referring to the OS user but the database superuser. Now in
your
case they have the same name, postgres. The settings in /etc/passwd are
not relevant to what -W is doing. -W is referring to user infor
Hi
when I use a search engine for the term "Postgres Certification"
this page shows up
https://www.postgresql.org/about/news/333/
please remove that, very much outdated. The referenced link doesn't exist
anymore (404 No such domain)
Lukas
On Sun, 4 Sep 2016, Adrian Klaver wrote:
I would take Charles's suggestion and set up a .pgpass file just to be
safe.
The file ~/.pgpass already exists, but without an explicit password. I
added my password (plain text). The file already had perms 0600. Perhaps my
password was rejected with
On Sun, 4 Sep 2016, Adrian Klaver wrote:
-W is not referring to the OS user but the database superuser. Now in your
case they have the same name, postgres. The settings in /etc/passwd are
not relevant to what -W is doing. -W is referring to user information
being stored in the cluster in the sys
On Sun, 4 Sep 2016, Adrian Klaver wrote:
Just be aware that you now have a password for the postgres user and that
if you ever do enable md5 you will need it. I would take Charles's
suggestion and set up a .pgpass file just to be safe.
Adrian,
OK. I'll also read the page at the URL you provi
On 09/04/2016 09:01 AM, Rich Shepard wrote:
On Sun, 4 Sep 2016, Adrian Klaver wrote:
Actually there is an important difference. In your 9.3 file you have set
METHOD set to trust and in the 9.5 file it is set to md5, which is
password. Set the METHOD to trust in your 9.5 file and restart the
dat
On 09/04/2016 09:01 AM, Rich Shepard wrote:
On Sun, 4 Sep 2016, Adrian Klaver wrote:
Actually there is an important difference. In your 9.3 file you have set
METHOD set to trust and in the 9.5 file it is set to md5, which is
password. Set the METHOD to trust in your 9.5 file and restart the
dat
On Sun, 4 Sep 2016, Adrian Klaver wrote:
-W is not referring to the OS user but the database superuser. Now in your
case they have the same name, postgres. The settings in /etc/passwd are
not relevant to what -W is doing. -W is referring to user information
being stored in the cluster in the sys
On Sun, 4 Sep 2016, Charles Clavadetscher wrote:
Well, there you have it. As Adrian suggested you may set temporarily the
authentication method to trust, set yourself a password and change it back
to md5.
Charles,
I've had a password on this LAN for almost 2 decades. I've not before set
a p
On Sun, 4 Sep 2016, Adrian Klaver wrote:
Actually there is an important difference. In your 9.3 file you have set
METHOD set to trust and in the 9.5 file it is set to md5, which is
password. Set the METHOD to trust in your 9.5 file and restart the
database. Now for the non-socket access methods
On 09/04/2016 08:14 AM, Rich Shepard wrote:
On Sat, 3 Sep 2016, Adrian Klaver wrote:
Or if you are fine running the 9.5 instance at port 5432, what happens
if you do?:
psql -d postgres -U some_user -p 5432
$ psql -d postgres -U rshepard -p 5432
Password for user rshepard: FATAL: password au
On 09/04/2016 08:11 AM, Rich Shepard wrote:
On Sun, 4 Sep 2016, Adrian Klaver wrote:
But the message you sent me offlist showed the 9.5 instance running.
But now it's not running.
How are you starting the instance?
As superuser poostgres: pg_ctl start -D /var/lib/pgsql/data &
After
Hi
On 09/04/2016 05:16 PM, Charles Clavadetscher wrote:
Hi
On 09/04/2016 05:14 PM, Rich Shepard wrote:
On Sat, 3 Sep 2016, Adrian Klaver wrote:
Or if you are fine running the 9.5 instance at port 5432, what happens
if you do?:
psql -d postgres -U some_user -p 5432
$ psql -d postgres -U rs
Hi
On 09/04/2016 05:14 PM, Rich Shepard wrote:
On Sat, 3 Sep 2016, Adrian Klaver wrote:
Or if you are fine running the 9.5 instance at port 5432, what happens
if you do?:
psql -d postgres -U some_user -p 5432
$ psql -d postgres -U rshepard -p 5432
Password for user rshepard: FATAL: passwor
Hello
On 09/04/2016 05:11 PM, Rich Shepard wrote:
On Sun, 4 Sep 2016, Adrian Klaver wrote:
But the message you sent me offlist showed the 9.5 instance running.
But now it's not running.
How are you starting the instance?
As superuser poostgres: pg_ctl start -D /var/lib/pgsql/data &
On Sat, 3 Sep 2016, Adrian Klaver wrote:
Or if you are fine running the 9.5 instance at port 5432, what happens if you
do?:
psql -d postgres -U some_user -p 5432
$ psql -d postgres -U rshepard -p 5432
Password for user rshepard:
FATAL: password authentication failed for user "rshepard"
DE
On Sun, 4 Sep 2016, Adrian Klaver wrote:
But the message you sent me offlist showed the 9.5 instance running.
But now it's not running.
How are you starting the instance?
As superuser poostgres: pg_ctl start -D /var/lib/pgsql/data &
After removing an orphaned postmaster.pid the abov
On 09/04/2016 07:07 AM, Rich Shepard wrote:
On Sun, 4 Sep 2016, Adrian Klaver wrote:
The above is not possible. If the postmaster was not running there
would be no rejection error.
Adrian,
Yes. I conflated when the postmaster was running -- using the 9.3.4
server
-- and now when it's not r
On 09/04/2016 07:08 AM, Rich Shepard wrote:
On Sun, 4 Sep 2016, Charles Clavadetscher wrote:
Are you able to connect to the new instance with any user at all, e.g.
with psql? If so you can use the command \du to list all users.
Charles,
No. The postmaster is not running; trying to start it
Hello,
Has anyone already tested to integrate presto (https://prestodb.io/) within
postgresql thought the postgres_fdw extension ?
Presto is a distributed SQL query engine able to scale horizontally on top
of hadoop, cassandra or mongodb.
Moreover, presto has a PostgreSQL protocol (
https://githu
On Sun, 4 Sep 2016, Adrian Klaver wrote:
Actually you already have. From an email that I just realized was offlist:
"As superuser postgres connected to 9.5.4 'psql -l' shows all databases
loaded:
xxx | rshepard | UTF8 | C | en_US.UTF-8 |
xxx| rshepard | UTF8
On Sun, 4 Sep 2016, Charles Clavadetscher wrote:
Are you able to connect to the new instance with any user at all, e.g.
with psql? If so you can use the command \du to list all users.
Charles,
No. The postmaster is not running; trying to start it requires a password
which is also rejected.
On 09/04/2016 05:40 AM, Rich Shepard wrote:
On Sun, 4 Sep 2016, Charles Clavadetscher wrote:
Does the user rshepard exist in the new 9.5 instance?
I assume so but do not know how to check this.
Actually you already have. From an email that I just realized was offlist:
"As superuser postg
On Sun, 4 Sep 2016, Adrian Klaver wrote:
The above is not possible. If the postmaster was not running there would be
no rejection error.
Adrian,
Yes. I conflated when the postmaster was running -- using the 9.3.4 server
-- and now when it's not running. Now I'm wondering if I mistakenly use
On 09/04/2016 06:26 AM, Rich Shepard wrote:
Ccing list
On Sat, 3 Sep 2016, Adrian Klaver wrote:
Well the pg_dumpall *.sql file has the global
information(users/passwords), so it is a chicken and egg problem.
FYI, you can do:
pg_dumpall -g
https://www.postgresql.org/docs/9.5/static/app-pg-dum
On Sun, 4 Sep 2016, Charles Clavadetscher wrote:
Does the user rshepard exist in the new 9.5 instance?
I assume so but do not know how to check this.
Rich
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/
Re: Benoit Lobréau 2016-08-31
> Hi,
>
> My company is using PGDATA to store configuration files and the guc
> data_directory to give the path to the instance directory.
>
> They would use it like this:
>
> pg_ctl start -D -w
>
> with this directory setup:
>
> /CONFDIR => postgresql.conf pg_
45 matches
Mail list logo
