Thomas Kellerer wrote:
>>> I asked this a while back already:
>>>
>>>select to_date('2013-02-31', '-mm-dd');
>>>
>>> will not generate an error (unlike e.g. Oracle)
>>
>> This is by design.
>
> When I previously asked this question the answer as "this is based on
> Oracle's to_date()":
>
I've tried to upgrade a large production database from 9.2.4 to 9.3.2
using pg_upgradecluster (using pg_upgrade method) and it fails with the
error below. Upgrade using dump/restore seems to work on a test system
but would require a too long downtime on the production system.
# pg_upgradecluster -
Hi Ray,
We are already using the following query:
SELECT CASE WHEN pg_last_xlog_receive_location(
) = pg_last_xlog_replay_location() THEN 0 ELSE EXTRACT (EPOCH FROM now() -
pg_last_xact_replay_timestamp()) END AS log_delay;
We cannot use pg_xlog_location_diff as we use postgresql 9.1.
Regards,
Thanks a load Michael. This is really helpful.
Regards,
Granthana
On Tue, Jan 21, 2014 at 12:19 PM, Michael Paquier wrote:
>
>
> On Tue, Jan 21, 2014 at 2:33 PM, Sameer Kumar
> wrote:
> >>
> >>
> >> We are already using the following query:
> >>
> >> SELECT CASE WHEN pg_last_xlog_receive_loc
Yes byte lag as well as it makes more sense.
Regards,
Granthana
Regards,
Granthana
On Tue, Jan 21, 2014 at 11:03 AM, Sameer Kumar wrote:
>
>>
>> We are already using the following query:
>>
>> SELECT CASE WHEN pg_last_xlog_receive_location(
>> ) = pg_last_xlog_replay_location() THEN 0 ELSE EXT
Hello,
Does PostgreSQL provide any notation/method for putting a constraint on
each element of a JSON array?
An example to illustrate:
create table orders(data json);
insert into orders values ('
{
"order_id": 45,
"products": [
{
"product_id": 1,
"name":
On 01/21/2014 05:42 AM, Stefan Warten wrote:
I've tried to upgrade a large production database from 9.2.4 to 9.3.2
using pg_upgradecluster (using pg_upgrade method) and it fails with the
error below. Upgrade using dump/restore seems to work on a test system
but would require a too long downtime o
Postgres General List,
I am stumped trying to prevent an overflowing UDP buffer on a standby
Postgres
service. Any help would be most appreciated.
Essentially a UDP buffer associated with the pg_standby process on my
localhost
interface gradually fills up once I start Postgres until it
This is a cross-post from
http://stackoverflow.com/questions/21238209/info-output-despite-set-client-min-messages-to-warning-just-before
since I'm not getting any answers there yet.
With postgresql-9.0.15 on CentOS 6.5 (accessed via pgAdminIII 1.18.1 on
Win2003), I have a plperlu function that
Ubuntu 12.04.2 LTS with packages from apt.postgresql.org repo.
pg_upgradecluster is the one from postgresql-common=151.pgdg12.4+1.
On 21.01.2014 16:36, Adrian Klaver wrote:
> On 01/21/2014 05:42 AM, Stefan Warten wrote:
>> I've tried to upgrade a large production database from 9.2.4 to 9.3.2
>> u
On Tue, Jan 21, 2014 at 7:57 AM, Kevin Field wrote:
> This is a cross-post from http://stackoverflow.com/
> questions/21238209/info-output-despite-set-client-min-
> messages-to-warning-just-before since I'm not getting any answers there
> yet.
>
> With postgresql-9.0.15 on CentOS 6.5 (accessed vi
Jeff Janes writes:
> Why not use NOTICE? INFO is supposed to be used for things the user
> *requested* to see (for example, by supplying the "verbose" option to one
> of the commands which take that option).
> The documentation could be clearer on this, but it seems to suggest that
> there is no
Postgres Question writes:
> Essentially a UDP buffer associated with the pg_standby process on my
> localhost interface gradually fills up once I start Postgres until it
> hits its maximum capacity and then proceeds to steadily drop packets. A
> restart of Postgres (of course) clears the buffer, b
On 01/21/2014 08:13 AM, Stefan Warten wrote:
Ubuntu 12.04.2 LTS with packages from apt.postgresql.org repo.
pg_upgradecluster is the one from postgresql-common=151.pgdg12.4+1.
Alright I see --method is there, just not in the man pages I was looking
at. Reading through the script I see it will
On Tue, Jan 21, 2014 at 1:34 AM, Maciej Szopinski wrote:
> Hello,
>
> Does PostgreSQL provide any notation/method for putting a constraint on
> each element of a JSON array?
>
> An example to illustrate:
>
>
> [...]
> I know that this can be done by extracting products to a separate table
> with
Why not use NOTICE? INFO is supposed to be used for things the user
*requested* to see (for example, by supplying the "verbose" option to one
of the commands which take that option).
The documentation could be clearer on this, but it seems to suggest that
there is no way to turn off INFO to th
Hi. I'm trying to build the table_log module for Postgres 9.3, and am
wondering if there is an issue with pg_config. I installed Postgres on a
fresh CentOS 6.5 with the pgdg packages:
yum list installed postgres*
Installed Packages
postgresql93.x86_64 9.3.2-1P
Ken Tanzer writes:
> When I look the output of pg_config, and especially compared to my 9.2
> output, it seems suspiciously lacking some 9.3 paths:
> [root@new-agency table_log-0.4.4]# pg_config | more
> BINDIR = /usr/bin
> DOCDIR = /usr/share/doc/pgsql
> HTMLDIR = /usr/share/doc/pgsql
> INCLUDED
On Tue, Jan 21, 2014 at 12:32 PM, Tom Lane wrote:
>
> Exactly where is root's path finding pg_config?
>
> IIRC, most of the paths shown here are actually computed relative to the
> location of the pg_config executable, so I could imagine getting this
> kind of result if you'd done something like
Ken Tanzer writes:
> On Tue, Jan 21, 2014 at 12:32 PM, Tom Lane wrote:
>> IIRC, most of the paths shown here are actually computed relative to the
>> location of the pg_config executable, so I could imagine getting this
>> kind of result if you'd done something like symlinking pg_config into
>> /
On 01/21/2014 01:18 PM, Ken Tanzer wrote:
On Tue, Jan 21, 2014 at 12:32 PM, Tom Lane
Oddly, there was a pg_config in /usr/bin that was not a symlink and not
owned by any package. I'm really puzzled as to how it got there, but I
removed it, and symlinked the one from /usr/pgsql-9.3/bin. It pu
On Tue, Jan 21, 2014 at 1:45 PM, Tom Lane wrote:
> Ken Tanzer writes:
> > On Tue, Jan 21, 2014 at 12:32 PM, Tom Lane wrote:
> >> IIRC, most of the paths shown here are actually computed relative to the
> >> location of the pg_config executable, so I could imagine getting this
> >> kind of resul
When I tried to do CREATE EXTENSION IF NOT EXISTS
/usr/pgsql-9.2/share/extension/plpgsql.control with schema public;
it gave me
ERROR: syntax error at or near "EXTENSION"
CREATE LANGUAGE worked just fine. I only tried CREATE EXTENSION because
the manual said that CREATE LANGUAGE was deprecated.
On 01/21/2014 02:51 PM, Susan Cassidy wrote:
When I tried to do CREATE EXTENSION IF NOT EXISTS
/usr/pgsql-9.2/share/extension/plpgsql.control with schema public;
it gave me
ERROR: syntax error at or near "EXTENSION"
CREATE LANGUAGE worked just fine. I only tried CREATE EXTENSION because
the m
Ken Tanzer writes:
> On Tue, Jan 21, 2014 at 1:45 PM, Tom Lane wrote:
>> Ken Tanzer writes:
>>> It also sounds like from your comment that symlinking to /usr/bin is
>>> frowned upon. What is the better way to deal with this?
>> I had forgotten the details, but if pg_config is giving you the ri
Hi,
On Tue, 2014-01-21 at 13:18 -0800, Ken Tanzer wrote:
> Oddly, there was a pg_config in /usr/bin that was not a symlink and
> not owned by any package. I'm really puzzled as to how it got there,
> but I removed it, and symlinked the one from /usr/pgsql-9.3/bin. It
> puts out better informat
On Mon, Jan 13, 2014 at 09:23:09AM -0500, Joseph Kregloh wrote:
>
>
>
> Right. I know there were multiple issue with this upgrade, jails
> probably being the biggest, but a new one I had never heard is that _if_
> you are placing your tablespaces in the PGDATA directory, and you are
On Tue, Jan 21, 2014 at 3:16 PM, Devrim GÜNDÜZ wrote:
>
> Hi,
>
> On Tue, 2014-01-21 at 13:18 -0800, Ken Tanzer wrote:
>
> > Oddly, there was a pg_config in /usr/bin that was not a symlink and
> > not owned by any package. I'm really puzzled as to how it got there,
> > but I removed it, and syml
Ken Tanzer writes:
> On Tue, Jan 21, 2014 at 3:16 PM, Devrim GÜNDÜZ wrote:
>> Please don't do it. PGDG RPMs are designed for parallel installation
>> (like 9.2 and 9.3 on the same machine), and then the pg_config in
>> regular $PATH might be tricky.
> It didn't seem like a great idea to me eithe
Hi,
On Tue, 2014-01-21 at 18:00 -0800, Ken Tanzer wrote:
> It didn't seem like a great idea to me either, but what's the better
> alternative? Without the symlink I get lots of errors:
>
> make USE_PGXS=1
> make: pg_config: Command not found
Sometimes exporting PG_CONFIG does the trick. Altern
30 matches
Mail list logo
