Hi Robert,
Can we get that commitfest renamed? And if I should know how to do
that, can you inform me how?
Thanks!
-selene
--
http://chesnok.com/daily - me
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mai
On Wed, May 19, 2010 at 9:58 PM, Boszormenyi Zoltan wrote:
>> In the patch, PQputCopyData() checks the newly-introduced pg_conn field
>> "duplexCopy". Instead, how about checking the existing field "replication"?
>
> I didn't see there was such a new field. (looking...) I can see now,
> it was add
Hajimemashite Takahiro,
Thanks for your feedback.
I applied all the changes on 9.0beta manually and then it compiled without
any assertion failures.
I also changed the oids to a different unused range, since the ones I used
before had been taken in 9.0beta1.
There are still some problems though
On Wed, May 19, 2010 at 10:03 PM, Robert Haas wrote:
> On Wed, May 19, 2010 at 8:49 AM, Simon Riggs wrote:
>> On Wed, 2010-05-19 at 08:21 -0400, Tom Lane wrote:
>>> Robert Haas writes:
>>> > On Wed, May 19, 2010 at 1:47 AM, Fujii Masao
>>> > wrote:
>>> >> Yes, but I prefer XLogCtl->SharedRecov
Andres Freund wrote:
> On Wednesday 19 May 2010 22:39:32 Bruce Momjian wrote:
> > There are some limitations when migrating from 8.3 to 8.4, but not when
> > migrating from 8.3 to 9.0, because we added a feature to 9.0. Can you
> > give a specific example?
> Didnt the 'name' alignment change?
Uh,
On Wednesday 19 May 2010 22:39:32 Bruce Momjian wrote:
> There are some limitations when migrating from 8.3 to 8.4, but not when
> migrating from 8.3 to 9.0, because we added a feature to 9.0. Can you
> give a specific example?
Didnt the 'name' alignment change?
Andres
--
Sent via pgsql-hacker
Alvaro Herrera wrote:
> Excerpts from Stefan Kaltenbrunner's message of mi?? may 19 15:53:18 -0400
> 2010:
> > While looking at the docs for pg_upgrade I noticed some stuff that the
> > following patch attempts to at least partly address.
>
> Surely this para can be removed?
>
>
> If
Stefan Kaltenbrunner wrote:
> While looking at the docs for pg_upgrade I noticed some stuff that the
> following patch attempts to at least partly address.
> There is quite some confusion going on between using "Postgres" and
> PostgreSQL, I changed that to the later because that is how we spell th
Excerpts from Stefan Kaltenbrunner's message of mié may 19 15:53:18 -0400 2010:
> While looking at the docs for pg_upgrade I noticed some stuff that the
> following patch attempts to at least partly address.
Surely this para can be removed?
If you are using tablespaces and migrating t
While looking at the docs for pg_upgrade I noticed some stuff that the
following patch attempts to at least partly address.
There is quite some confusion going on between using "Postgres" and
PostgreSQL, I changed that to the later because that is how we spell the
productname in all the other parts
Hi.
I am working on getting full-text-search to work and have
come across something I think look a bit strange.
The document base is arount 350.000 documents and
I have set the statistics target on the tsvector column
to 1000 since the 100 seems way of.
# ANALYZE verbose reference (document_tsv
Jesper Krogh wrote:
> On 2010-05-18 18:57, Bruce Momjian wrote:
> > 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 tha
Bruce Momjian wrote:
> > This is the "production system". I have absolutely no indications that
> > anything should be wrong in there. It has run rock-solid since it got
> > migrated (dump/restore) to 8.4 for about 7 months now. So I am a bit
> > scared about you telling that it seems wrong. (but t
Bogdan Vlad writes:
> How can I determine the pg_class oid of the argument type in a
> polymorphic C function when it's called with a table row?
You're confusing pg_class oid with pg_type oid. The type oid
of the function argument is necessarily going to be a *type* oid.
You can look at the pg_
"BRUSSER Michael" writes:
> I looked at the release notes but could not figure out at which point
> Postgres gave the option of building the 64-bit binaries.
Quite a long time ago. Any reasonably current release should be OK.
> One feature that we'll be missing terribly is the client TCL api, i
On Wed, May 19, 2010 1:31 pm, Tom Lane wrote:
> BTW, standard_conforming_strings is really a different case because of
> the SQL-injection security hazards with non-scs-aware client code.
> I don't see any comparable risk for bytea format.
>
Yeah, and the impact of this will be much more limited.
Hello
How can I determine the pg_class oid of the argument type in a
polymorphic C function when it's called with a table row?
PG_FUNCTION_INFO_V1(myfunc);
Datum myfunc(PG_FUNCTION_ARGS)
{
Oid arg_type = get_fn_expr_argtype(fcinfo->flinfo, 0);
elog(ERROR, "arg_type %d", arg_type);
PG_RETURN_NU
We adding support for Solaris x86 and this pushes us to upgrade the from
the old-old version of Postgres we've been using for years.
(The requirement is to have the 64-bit exec and libs)
I looked at the release notes but could not figure out at which point
Postgres gave the option of building the
Magnus Hagander writes:
> On Wed, May 19, 2010 at 11:11 AM, Robert Haas wrote:
>> Yeah, that's what I'm worried about. I remember going through this
>> with E'' quoting. It wasn't fun.
> Right. So do we know what the policy is? As long as DBD::Pg is
> released before pg 9.0 we'd be fine, *prov
On 2010-05-18 18:57, Bruce Momjian wrote:
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
simpl
On May 19, 2010, at 18:32 , Robert Haas wrote:
> On Wed, May 19, 2010 at 12:16 PM, Stefan Kaltenbrunner
> wrote:
>>> I think it just depends on whether we're likely to get releases from
>>> Linux vendors that include PG 9.0 but not the updated drivers. I'm
>>> not sure their schedule will be affe
On 05/19/2010 12:32 PM, Robert Haas wrote:
> On Wed, May 19, 2010 at 12:16 PM, Stefan Kaltenbrunner
> wrote:
>>> I think it just depends on whether we're likely to get releases from
>>> Linux vendors that include PG 9.0 but not the updated drivers. I'm
>>> not sure their schedule will be affected
On Wed, May 19, 2010 at 12:16 PM, Stefan Kaltenbrunner
wrote:
>> I think it just depends on whether we're likely to get releases from
>> Linux vendors that include PG 9.0 but not the updated drivers. I'm
>> not sure their schedule will be affected by whether we call it 8.5 or
>> 9.0.
>
> that's a
On 05/19/2010 11:19 AM, Magnus Hagander wrote:
> On Wed, May 19, 2010 at 11:11 AM, Robert Haas wrote:
>> On Wed, May 19, 2010 at 11:07 AM, Magnus Hagander
>> wrote:
>>> On Wed, May 19, 2010 at 11:06 AM, Greg Sabino Mullane
>>> wrote:
>> given how much faster the new format is (or rath
On 05/19/2010 11:45 AM, Robert Haas wrote:
> On Wed, May 19, 2010 at 11:31 AM, Alex Hunsaker wrote:
>> On Wed, May 19, 2010 at 09:05, Robert Haas wrote:
>>> On Wed, May 19, 2010 at 11:00 AM, Kenneth Marshall wrote:
Changing something like that within the minor release arc is
not a good
On Wed, May 19, 2010 at 11:31 AM, Alex Hunsaker wrote:
> On Wed, May 19, 2010 at 09:05, Robert Haas wrote:
>> On Wed, May 19, 2010 at 11:00 AM, Kenneth Marshall wrote:
>>> Changing something like that within the minor release arc is
>>> not a good idea. It would be better to have it on by defaul
On Wed, May 19, 2010 at 09:05, Robert Haas wrote:
> On Wed, May 19, 2010 at 11:00 AM, Kenneth Marshall wrote:
>> Changing something like that within the minor release arc is
>> not a good idea. It would be better to have it on by default and
>> if the driver developers are not up to use it, they
On Wed, May 19, 2010 at 11:11 AM, Robert Haas wrote:
> On Wed, May 19, 2010 at 11:07 AM, Magnus Hagander wrote:
>> On Wed, May 19, 2010 at 11:06 AM, Greg Sabino Mullane
>> wrote:
>>>
> given how much faster the new format is (or rather how slow the old one
> was) and the number of peopl
* Magnus Hagander [100519 11:08]:
> How do the distros generaly deal with that? E.g. do we have to wait
> for RHEL7 for it to actually show up in redhat?
Don't worry, 9.0 won't show up in redhat for a while yet either...
;-)
--
Aidan Van Dyk Create
On Wed, May 19, 2010 at 11:07 AM, Magnus Hagander wrote:
> On Wed, May 19, 2010 at 11:06 AM, Greg Sabino Mullane
> wrote:
>>
given how much faster the new format is (or rather how slow the old one
was) and the number of people I have seen complaining "why is bytea so
slow) I would
On Wed, May 19, 2010 at 11:06 AM, Greg Sabino Mullane wrote:
>
>>> given how much faster the new format is (or rather how slow the old one
>>> was) and the number of people I have seen complaining "why is bytea so
>>> slow) I would like to see it staying turned on by default. However this
>>> also
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
>> given how much faster the new format is (or rather how slow the old one
>> was) and the number of people I have seen complaining "why is bytea so
>> slow) I would like to see it staying turned on by default. However this
>> also depends on ho
On Wed, May 19, 2010 at 11:00 AM, Kenneth Marshall wrote:
> On Wed, May 19, 2010 at 10:54:01AM -0400, Robert Haas wrote:
>> On Wed, May 19, 2010 at 10:17 AM, Stefan Kaltenbrunner
>> wrote:
>> > On 05/19/2010 08:13 AM, Tom Lane wrote:
>> >> Bernd Helmle writes:
>> >>> --On 18. Mai 2010 23:20:26 +
On Wed, May 19, 2010 at 10:54:01AM -0400, Robert Haas wrote:
> On Wed, May 19, 2010 at 10:17 AM, Stefan Kaltenbrunner
> wrote:
> > On 05/19/2010 08:13 AM, Tom Lane wrote:
> >> Bernd Helmle writes:
> >>> --On 18. Mai 2010 23:20:26 +0200 Jesper Krogh wrote:
> May I ask whats the reason is for
On Wed, May 19, 2010 at 10:17 AM, Stefan Kaltenbrunner
wrote:
> On 05/19/2010 08:13 AM, Tom Lane wrote:
>> Bernd Helmle writes:
>>> --On 18. Mai 2010 23:20:26 +0200 Jesper Krogh wrote:
May I ask whats the reason is for "breaking" the compatibillity?
>>
>>> "Efficency", if i am allowed to ca
On 05/19/2010 08:13 AM, Tom Lane wrote:
> Bernd Helmle writes:
>> --On 18. Mai 2010 23:20:26 +0200 Jesper Krogh wrote:
>>> 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 should be more efficie
On Wed, May 19, 2010 at 8:49 AM, Simon Riggs wrote:
> On Wed, 2010-05-19 at 08:21 -0400, Tom Lane wrote:
>> Robert Haas writes:
>> > On Wed, May 19, 2010 at 1:47 AM, Fujii Masao wrote:
>> >> Yes, but I prefer XLogCtl->SharedRecoveryInProgress, which is the almost
>> >> same indicator as the bool
Fujii Masao írta:
> On Wed, May 19, 2010 at 5:41 PM, Boszormenyi Zoltan wrote:
>
>>> Isn't reading the same WAL twice (by walreceiver and startup process)
>>> inefficient?
>>>
>> Yes, and I didn't implement that because it's inefficient.
>>
>
> So I'd like to propose to use LSN inst
Hi,
I'm going to start work on another XML todo item:
"Add XML Schema validation and xmlvalidate function (SQL:2008)"
The standard identifies XMLVALIDATE as:
::=
XMLVALIDATE
[ ]
so I've got something quite clear to work too. libxml has the required
support for
On Wed, 2010-05-19 at 08:21 -0400, Tom Lane wrote:
> Robert Haas writes:
> > On Wed, May 19, 2010 at 1:47 AM, Fujii Masao wrote:
> >> Yes, but I prefer XLogCtl->SharedRecoveryInProgress, which is the almost
> >> same indicator as the boolean you suggested. Thought?
>
> > It feels cleaner and sim
Robert Haas writes:
> On Wed, May 19, 2010 at 1:47 AM, Fujii Masao wrote:
>> Yes, but I prefer XLogCtl->SharedRecoveryInProgress, which is the almost
>> same indicator as the boolean you suggested. Thought?
> It feels cleaner and simpler to me to use the information that the
> postmaster already
Bernd Helmle writes:
> --On 18. Mai 2010 23:20:26 +0200 Jesper Krogh wrote:
>> 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 should be more efficient to retrieve and to handle than the
> old one
On Wed, May 19, 2010 at 1:47 AM, Fujii Masao wrote:
> 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 t
On Wed, May 19, 2010 at 5:41 PM, Boszormenyi Zoltan wrote:
>> Isn't reading the same WAL twice (by walreceiver and startup process)
>> inefficient?
>
> Yes, and I didn't implement that because it's inefficient.
So I'd like to propose to use LSN instead of XID since LSN can
be easily handled by bo
2010/5/19 Mike Fowler :
> Pavel Stehule wrote:
>>
>> 2010/5/19 Mike Fowler :
>>
>>>
>>> Pavel Stehule wrote:
>>>
see google: lateral sql injection oracle NLS_DATE_FORMAT
I would to like this functionality too - and technically I don't see a
problem - It's less than 100 line
Pavel Stehule wrote:
2010/5/19 Mike Fowler :
Pavel Stehule wrote:
see google: lateral sql injection oracle NLS_DATE_FORMAT
I would to like this functionality too - and technically I don't see a
problem - It's less than 100 lines, but I don't need a new security
problem. So my proposal
2010/5/19 Mike Fowler :
> Pavel Stehule wrote:
>>
>> see google: lateral sql injection oracle NLS_DATE_FORMAT
>>
>> I would to like this functionality too - and technically I don't see a
>> problem - It's less than 100 lines, but I don't need a new security
>> problem. So my proposal is change noth
Pavel Stehule wrote:
see google: lateral sql injection oracle NLS_DATE_FORMAT
I would to like this functionality too - and technically I don't see a
problem - It's less than 100 lines, but I don't need a new security
problem. So my proposal is change nothing on this integrated
functionality and
2010/5/19 Mike Fowler :
> Pavel Stehule wrote:
>>
>> 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
interop
Fujii Masao írta:
> 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
Pavel Stehule wrote:
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
51 matches
Mail list logo
