2010/5/19 Peter Eisentraut :
> On tis, 2010-05-18 at 18:26 -0400, Ben Hockey wrote:
>> ecmascript 5 is the most recent specification for JavaScript and i
>> would think that having a DATESTYLE format to simplify
>> interoperability with JavaScript applications would be highly
>> desirable.
>
> Note
On tis, 2010-05-18 at 18:26 -0400, Ben Hockey wrote:
> ecmascript 5 is the most recent specification for JavaScript and i
> would think that having a DATESTYLE format to simplify
> interoperability with JavaScript applications would be highly
> desirable.
Note that we haven't got any other datesty
On Wed, May 19, 2010 at 12:59 PM, Robert Haas wrote:
> In terms of removing the backup label file, can we simply have an
> additional boolean in the postmaster that indicates whether we've ever
> reached PM_RUN, and only consider removing the backup file if so?
Yes, but I prefer XLogCtl->SharedRe
2010/5/19 Robert Haas :
> On Tue, May 18, 2010 at 6:26 PM, Ben Hockey wrote:
>> hi,
>> i mistakenly had posted this to pgsql-bugs already and got a response (see
>> below - edited). i'm posting here since afaik it is the way i should be
>> requesting new features. my suggestion is to add a DATES
On Tue, May 18, 2010 at 6:26 PM, Ben Hockey wrote:
> hi,
> i mistakenly had posted this to pgsql-bugs already and got a response (see
> below - edited). i'm posting here since afaik it is the way i should be
> requesting new features. my suggestion is to add a DATESTYLE format to
> match the for
On Tue, May 18, 2010 at 8:15 PM, Florian Pflug wrote:
> Will do. Thanks for the link.
>
> Here is an updated version that works for SHARE locks too.
>
> (This message mainly serves as a way to link the updated patch to the commit
> fest entry. Is this how I'm supposed to do that, or am I doing so
On Tue, May 18, 2010 at 10:40 PM, Fujii Masao wrote:
> On Tue, May 18, 2010 at 8:35 PM, Robert Haas wrote:
>> On Mon, May 17, 2010 at 10:40 PM, Fujii Masao wrote:
>>> On Mon, May 17, 2010 at 10:20 PM, Robert Haas wrote:
OK, I think I understand now. But, the SIGTERM sent by the postmaster
On Tue, May 18, 2010 at 8:35 PM, Robert Haas wrote:
> On Mon, May 17, 2010 at 10:40 PM, Fujii Masao wrote:
>> On Mon, May 17, 2010 at 10:20 PM, Robert Haas wrote:
>>> OK, I think I understand now. But, the SIGTERM sent by the postmaster
>>> doesn't kill the recovery process unconditionally. It
On May 17, 2010, at 3:30 , Robert Haas wrote:
> On Sun, May 16, 2010 at 9:07 PM, Florian Pflug wrote:
>> On May 14, 2010, at 22:54 , Robert Haas wrote:
>>> On Thu, May 13, 2010 at 5:39 PM, Tom Lane wrote:
Florian Pflug writes:
> All in all, I believe that SHARE and UPDATE row-level lock
hi,
i mistakenly had posted this to pgsql-bugs already and got a response
(see below - edited). i'm posting here since afaik it is the way i
should be requesting new features. my suggestion is to add a
DATESTYLE format to match the format specified for date time strings
in ecmascript 5.
On Tue, 2010-05-18 at 17:25 -0400, Heikki Linnakangas wrote:
> On 18/05/10 17:17, Simon Riggs wrote:
> > There's no reason that the buffer size we use for XLogRead() should be
> > the same as the send buffer, if you're worried about that. My point is
> > that pq_putmessage contains internal flushes
On Tue, May 18, 2010 at 03:26:17PM -0600, Alex Hunsaker wrote:
> On Tue, May 18, 2010 at 15:20, Jesper Krogh wrote:
> > On 2010-05-18 23:12, Alex Hunsaker wrote:
> >>
> >> set bytea_output 'escape';
> >
> > That was it. Knowing what the problem was I had no problem finding it in the
> > release no
--On 18. Mai 2010 23:20:26 +0200 Jesper Krogh wrote:
That was it. Knowing what the problem was I had no problem finding it in
the release notes.
May I ask whats the reason is for "breaking" the compatibillity?
"Efficency", if i am allowed to call it this way. The new hex
representation sh
On Tue, May 18, 2010 at 15:20, Jesper Krogh wrote:
> On 2010-05-18 23:12, Alex Hunsaker wrote:
>>
>> set bytea_output 'escape';
>
> That was it. Knowing what the problem was I had no problem finding it in the
> release notes.
>
> May I ask whats the reason is for "breaking" the compatibillity?
Th
On 18/05/10 17:17, Simon Riggs wrote:
There's no reason that the buffer size we use for XLogRead() should be
the same as the send buffer, if you're worried about that. My point is
that pq_putmessage contains internal flushes so at the libpq level you
gain nothing by big batches. The read() will b
On Tue, 2010-05-18 at 17:08 -0400, Heikki Linnakangas wrote:
> On 17/05/10 12:36, Jim Nasby wrote:
> > On May 15, 2010, at 12:05 PM, Heikki Linnakangas wrote:
> >> What exactly is the user trying to monitor? If it's "how far behind is
> >> the standby", the difference between pg_current_xlog_insert
On 2010-05-18 23:12, Alex Hunsaker wrote:
set bytea_output 'escape';
That was it. Knowing what the problem was I had no problem finding it in
the release notes.
May I ask whats the reason is for "breaking" the compatibillity?
--
Jesper
--
Sent via pgsql-hackers mailing list (pgsql-hackers@
On Tue, 2010-05-18 at 17:06 -0400, Heikki Linnakangas wrote:
> On 17/05/10 04:40, Simon Riggs wrote:
> > On Sun, 2010-05-16 at 16:53 +0100, Simon Riggs wrote:
> >>>
> >>> Attached patch rearranges the walsender loops slightly to fix the above.
> >>> XLogSend() now only sends up to MAX_SEND_SIZE byt
Jesper Krogh wrote:
> On 2010-05-18 21:56, Bruce Momjian wrote:
> > Jesper Krogh wrote:
> >
> >> On 2010-05-18 20:52, Bruce Momjian wrote:
> >>
> >>> This line above looks very odd because I didn't think the template0
> >>> datfrozenxid could be advanced. Can I see the output of this que
This is an area that the SQL standard didn't think through very clearly
(IMHO). They actually have two ways of specifying functions like this, one
is the ordered aggregate section that this syntax is modeled on, which is
indeed very confusing for multi-parameter aggregates. The other is the
hypot
On Tue, May 18, 2010 at 14:54, Jesper Krogh wrote:
> Hi.
>
> I'm trying to do a test move of one of our applications onto 9.0beta1.
> We use storable and serializes data into a bytea column in the database.
> [ snip insert/select using bytea ]
> 8.4
> id | t
On 17/05/10 12:36, Jim Nasby wrote:
On May 15, 2010, at 12:05 PM, Heikki Linnakangas wrote:
What exactly is the user trying to monitor? If it's "how far behind is
the standby", the difference between pg_current_xlog_insert_location()
in the master and pg_last_xlog_replay_location() in the standb
On 2010-05-18 21:56, Bruce Momjian wrote:
Jesper Krogh wrote:
On 2010-05-18 20:52, Bruce Momjian wrote:
This line above looks very odd because I didn't think the template0
datfrozenxid could be advanced. Can I see the output of this query:
SELECT datname, datfrozenxid, datal
On 17/05/10 04:40, Simon Riggs wrote:
On Sun, 2010-05-16 at 16:53 +0100, Simon Riggs wrote:
Attached patch rearranges the walsender loops slightly to fix the above.
XLogSend() now only sends up to MAX_SEND_SIZE bytes (== XLOG_SEG_SIZE /
2) in one round and returns to the main loop after that ev
Hi.
I'm trying to do a test move of one of our applications onto 9.0beta1.
We use storable and serializes data into a bytea column in the database.
This script uses that:
#!/usr/bin/perl
use strict;
use warnings;
use Storable;
use DBI;
use DBD::Pg;
use Data::Dumper;
my $dbh = DBI->connect("dbi:
Excerpts from Tom Lane's message of vie may 14 15:03:57 -0400 2010:
> Maybe a better solution is to have some kind of notion of a default-only
> entry, which is sufficient to insert the default into the struct but
> isn't accepted as a user-settable item.
This patch (for 8.4, but applies fuzzily
Excerpts from Tony Sullivan's message of mar may 18 13:19:13 -0400 2010:
> Hello everyone,
>
> We are seeing the following error message occasionally in the postgres logs:
>
> 2010-05-13 23:49:03 PDT ERROR: unexpected data beyond EOF in block 4106698 of
> relation "custom_discoveryprofile"
> 201
Alvaro Herrera wrote:
> Excerpts from jesper's message of mar may 18 13:22:12 -0400 2010:
>
> > j...@pal:~$ psql data
> > psql (9.0beta1, server 8.4.1)
> > WARNING: psql version 9.0, server version 8.4.
> > Some psql features might not work.
> > Type "help" for help.
> >
> > data# SELECT
Excerpts from jesper's message of mar may 18 13:22:12 -0400 2010:
> j...@pal:~$ psql data
> psql (9.0beta1, server 8.4.1)
> WARNING: psql version 9.0, server version 8.4.
> Some psql features might not work.
> Type "help" for help.
>
> data# SELECT datname, datfrozenxid FROM pg_database;
jes...@krogh.cc wrote:
> First the new one..
>
> j...@pal:~$ psql -p 5433
> psql (9.0beta1)
> Type "help" for help.
>
> data=# SELECT datname, datfrozenxid FROM pg_database;
> datname | datfrozenxid
> ---+--
> template0 | 654
> postgres | 2374592801
> data
On 18/05/10 07:41, Fujii Masao wrote:
On Sat, May 15, 2010 at 4:59 PM, Heikki Linnakangas
wrote:
BTW, What I'd like to see as a very first patch first is to change the
current poll loops in walreceiver and walsender to, well, not poll.
That's a requirement for synchronous replication, is very
Jesper Krogh wrote:
> On 2010-05-18 20:52, Bruce Momjian wrote:
> > This line above looks very odd because I didn't think the template0
> > datfrozenxid could be advanced. Can I see the output of this query:
> >
> > SELECT datname, datfrozenxid, datallowconn FROM pg_database;
> >
> >
>
>
On 2010-05-18 20:52, Bruce Momjian wrote:
This line above looks very odd because I didn't think the template0
datfrozenxid could be advanced. Can I see the output of this query:
SELECT datname, datfrozenxid, datallowconn FROM pg_database;
Only from the "old" database:
data=# SELE
On Tue, May 18, 2010 at 2:46 PM, Stephen Frost wrote:
> * Magnus Hagander (mag...@hagander.net) wrote:
>> That definitely looks wrong. How about this?
>
> Looks good to me, but I'd add a link to the Username Maps page.
Done and applied.
--
Magnus Hagander
Me: http://www.hagander.net/
Work: h
jes...@krogh.cc wrote:
> > on the old and new servers, but if you can only provide these values on
> > one of the two servers, it is still useful. Thanks.
>
> Hi Bruce, thanks for your prompt response.
>
> First the new one..
Great.
> j...@pal:~$ psql -p 5433
> psql (9.0beta1)
> Type "help" fo
* Magnus Hagander (mag...@hagander.net) wrote:
> That definitely looks wrong. How about this?
Looks good to me, but I'd add a link to the Username Maps page.
Thanks!
Stephen
signature.asc
Description: Digital signature
On Tue, May 18, 2010 at 12:49 PM, Stephen Frost wrote:
> Greetings,
>
> Under:
>
> http://developer.postgresql.org/pgdocs/postgres/runtime-config-file-locations.html
>
> We have:
>
> ident_file (string)
>
> Specifies the configuration file for ident authentication
> (customarily called p
On 05/18/2010 09:22 AM, Simon Riggs wrote:
> On Tue, 2010-05-18 at 07:32 -0400, Andrew Dunstan wrote:
>>
>> Simon Riggs wrote:
>>> That puts a fairly large hole in recommending that people visit
>>> pgFoundry. That either needs to fixed or users will no longer be able to
>>> trust PgFoundry.
>>>
>
Hello everyone,
We are seeing the following error message occasionally in the postgres logs:
2010-05-13 23:49:03 PDT ERROR: unexpected data beyond EOF in block 4106698 of
relation "custom_discoveryprofile"
2010-05-13 23:49:03 PDT HINT: This has been seen to occur with buggy kernels;
consider up
> jes...@krogh.cc wrote:
>> Hi
>>
>> I tried running pg_upgrade from the current snapshot of postgresql and
>> upgrading from 8.4.4 to the snapshot version. Everything seem to look
>> fine
>> in the process and all that came out was only "ok's" but when I tried a
>> simple query on the databse it k
jes...@krogh.cc wrote:
> Hi
>
> I tried running pg_upgrade from the current snapshot of postgresql and
> upgrading from 8.4.4 to the snapshot version. Everything seem to look fine
> in the process and all that came out was only "ok's" but when I tried a
> simple query on the databse it keeps throw
Greetings,
Under:
http://developer.postgresql.org/pgdocs/postgres/runtime-config-file-locations.html
We have:
ident_file (string)
Specifies the configuration file for ident authentication
(customarily called pg_ident.conf). This parameter can only be set
at server start.
T
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Stephen Frost writes:
> > This doesn't seem right to me:
>
> > postgres=# select
> > postgres-# string_agg(column1::text order by column1 asc,',')
> > postgres-# from (values (3),(4),(1),(2)) a;
> > string_agg
> >
> > 1234
> > (1 row)
>
On 18 May 2010 16:37, Stephen Frost wrote:
> Greetings,
>
> This doesn't seem right to me:
>
> postgres=# select
> postgres-# string_agg(column1::text order by column1 asc,',')
> postgres-# from (values (3),(4),(1),(2)) a;
> string_agg
>
> 1234
> (1 row)
>
> I'm thinking we should
Stephen Frost writes:
> This doesn't seem right to me:
> postgres=# select
> postgres-# string_agg(column1::text order by column1 asc,',')
> postgres-# from (values (3),(4),(1),(2)) a;
> string_agg
>
> 1234
> (1 row)
Looks fine to me: you have two ordering columns (the second r
Greetings,
This doesn't seem right to me:
postgres=# select
postgres-# string_agg(column1::text order by column1 asc,',')
postgres-# from (values (3),(4),(1),(2)) a;
string_agg
1234
(1 row)
I'm thinking we should toss a syntax error here and force the 'order
by' to be at th
On Tue, 2010-05-18 at 07:32 -0400, Andrew Dunstan wrote:
>
> Simon Riggs wrote:
> > That puts a fairly large hole in recommending that people visit
> > pgFoundry. That either needs to fixed or users will no longer be able to
> > trust PgFoundry.
> >
> pgFoundry is a resource we provide the commun
On 05/18/2010 07:32 AM, Andrew Dunstan wrote:
>
>
> Simon Riggs wrote:
>> That puts a fairly large hole in recommending that people visit
>> pgFoundry. That either needs to fixed or users will no longer be able to
>> trust PgFoundry.
>>
>>
>
> pgFoundry is a resource we provide the community.
Hi
I tried running pg_upgrade from the current snapshot of postgresql and
upgrading from 8.4.4 to the snapshot version. Everything seem to look fine
in the process and all that came out was only "ok's" but when I tried a
simple query on the databse it keeps throwing these message out of the back
s
On Sat, May 15, 2010 at 4:59 PM, Heikki Linnakangas
wrote:
> BTW, What I'd like to see as a very first patch first is to change the
> current poll loops in walreceiver and walsender to, well, not poll.
> That's a requirement for synchronous replication, is very useful on its
> own, and requires a
On Mon, May 17, 2010 at 10:40 PM, Fujii Masao wrote:
> On Mon, May 17, 2010 at 10:20 PM, Robert Haas wrote:
>> OK, I think I understand now. But, the SIGTERM sent by the postmaster
>> doesn't kill the recovery process unconditionally. It will invoke
>> StartupProcShutdownHandler(), which will s
Simon Riggs wrote:
That puts a fairly large hole in recommending that people visit
pgFoundry. That either needs to fixed or users will no longer be able to
trust PgFoundry.
pgFoundry is a resource we provide the community. The projects there are
the responsibility of their individual own
Thanks for your reply!
On Fri, May 14, 2010 at 10:33 PM, Boszormenyi Zoltan wrote:
>> In your design, the transaction commit on the master waits for its XID
>> to be read from the XLOG_XACT_COMMIT record and replied by the standby.
>> Right? This design seems not to be extensible to #2 and #3 sin
> That is the case for *anything*. We could change the PostgreSQL
> licence if we wanted, but it would take a huge amount of effort and
> approval of every contributor ever whose work could be considered an
> artistic contribution.
I doubt it. Do you think that every single contributor is contacta
On Tue, 2010-05-18 at 06:32 -0400, Greg Stark wrote:
> On Tue, May 18, 2010 at 4:06 AM, Simon Riggs wrote:
> > If, as you say, the licence is unclear then whether-or-not it is an open
> > source licence must also be unclear.
>
> I would suggest you, or anyone else who notices, open bugs on any
>
On Tue, May 18, 2010 at 9:59 AM, Simon Riggs wrote:
> Dave, this is important and so this thread must have a clear resolution,
> so we must stick to a single point and be clear about our logic and our
> statements.
OK. I thought you were talking about copyright and licences though.
> You're sayi
On Tue, May 18, 2010 at 4:06 AM, Simon Riggs wrote:
> If, as you say, the licence is unclear then whether-or-not it is an open
> source licence must also be unclear.
I would suggest you, or anyone else who notices, open bugs on any
packages you want to use for which you find no LICENSE file match
On Thu, May 6, 2010 at 10:38 AM, Tom Lane wrote:
> * the index grows as the size of the total data set, it's not limited
> by partition size
>
> * can't cheaply drop one partition any more, you have to vacuum the
> (big) index first
So I wholeheartedly agree with the general sentiment that if you
On Tue, 2010-05-18 at 09:33 +0100, Dave Page wrote:
> >> No - pgFoundry projects are licenced and copyright-attributed as their
> >> authors see fit (as long as it's an open source licence of course).
> >
> > Yes, are they open source licences?
>
> All the options on pgFoundry are, yes.
>
> >> T
On Tue, May 18, 2010 at 5:10 PM, Simon Riggs wrote:
> On Tue, 2010-05-18 at 16:05 +0900, Fujii Masao wrote:
>> >>> >> ISTM that we can use XLogCtl->SharedRecoveryInProgress for that.
>> >>> >> Is this OK?
>> >>> >
>> >>> > That can change state at any time. Would that work?
>> >>>
>> >>> Yes. XLog
On Tue, May 18, 2010 at 9:06 AM, Simon Riggs wrote:
> On Tue, 2010-05-18 at 07:53 +0100, Dave Page wrote:
>
>> > For example, pg_batch is clearly marked "BSD licence", yet the docs and
>> > many of the files are marked "Copyright (c) 2010, NIPPON TELEGRAPH AND
>> > TELEPHONE CORPORATION".
>>
>> Do
On Tue, 2010-05-18 at 16:05 +0900, Fujii Masao wrote:
> >>> >> ISTM that we can use XLogCtl->SharedRecoveryInProgress for that.
> >>> >> Is this OK?
> >>> >
> >>> > That can change state at any time. Would that work?
> >>>
> >>> Yes. XLogCtl->SharedRecoveryInProgress is set to TRUE only when
> >>>
On Tue, 2010-05-18 at 07:53 +0100, Dave Page wrote:
> > For example, pg_batch is clearly marked "BSD licence", yet the docs and
> > many of the files are marked "Copyright (c) 2010, NIPPON TELEGRAPH AND
> > TELEPHONE CORPORATION".
>
> Don't mix up copyright and licence. They are not the same thin
On Tue, May 18, 2010 at 3:45 PM, Fujii Masao wrote:
> On Tue, May 18, 2010 at 3:24 PM, Simon Riggs wrote:
>> On Tue, 2010-05-18 at 15:09 +0900, Fujii Masao wrote:
>>> On Tue, May 18, 2010 at 2:26 PM, Simon Riggs wrote:
>>> > On Tue, 2010-05-18 at 12:02 +0900, Fujii Masao wrote:
>>> >> On Mon, Ma
64 matches
Mail list logo
