As reported in pgsql-bugs, in 9, a set returning function will raise an
error "Returned type .. does not match expected type .." when the
source type does not exactly match the target type. For example
VARCHAR(3) to VARCHAR(4) or NUMERIC(4,2) to NUMERIC(5,2). Previously,
this was not an issue.
It
> Why isn't vacuum_defer_cleanup_age listed on postgresql.conf.sample?
> Though I also tried to test the effect of it, I was unable to find it
> in the conf file.
Using it has some bugs we need to clean up, apparently.
--Josh Berkus
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgr
Awhile back I wrote:
> * I'm not too satisfied with the behavior of psql's \d:
> regression=# create table foo (f1 int primary key using index tablespace ts1,
> regression(# f2 int, EXCLUDE USING btree (f2 WITH =) using index tablespace
> ts1,
> regression(# f3 int, EXCLUDE USING btree (f3 WITH =
Fujii Masao wrote:
> On Wed, Mar 10, 2010 at 3:29 PM, Josh Berkus wrote:
> > I've been playing with vacuum_defer_cleanup_age in reference to the
> > query cancel problem. ?It really seems to me that this is the way
> > forward in terms of dealing with query cancel for normal operation
> > rather t
Tom Lane wrote:
> Bruce Momjian writes:
> > Tom Lane wrote:
> >> I'm inclined to think that maybe we should make the server return a
> >> distinct SQLSTATE for "bad password", and have libpq check for that
> >> rather than just assuming that the failure must be bad password.
>
> > Modifying the b
Bruce Momjian writes:
> Tom Lane wrote:
>> I'm inclined to think that maybe we should make the server return a
>> distinct SQLSTATE for "bad password", and have libpq check for that
>> rather than just assuming that the failure must be bad password.
> Modifying the backend to issue this hint seem
Tom Lane wrote:
> Bruce Momjian writes:
> > The attached patch reports the fact that .pgpass was used if the libpq
> > connection fails:
>
> The test is in a very inappropriate place --- it will be missed by
> several fully-supported code paths.
Agreed. I moved it to the error return label ("er
On Wed, Mar 10, 2010 at 3:29 PM, Josh Berkus wrote:
> I've been playing with vacuum_defer_cleanup_age in reference to the
> query cancel problem. It really seems to me that this is the way
> forward in terms of dealing with query cancel for normal operation
> rather than wal_standby_delay, or may
(2010/03/11 0:54), Robert Haas wrote:
> On Wed, Mar 3, 2010 at 7:16 PM, Robert Haas wrote:
>> 2010/3/3 KaiGai Kohei:
>>> (2010/03/03 22:42), Robert Haas wrote:
2010/3/3 KaiGai Kohei:
> (2010/03/03 14:26), Robert Haas wrote:
>> 2010/3/2 KaiGai Kohei:
>>> Is it an expected behavior?
Since the buildfarm is mostly green these days, I took some time to look
into the few remaining consistent failures. One is that gothic_moth and
codlin_moth fail on contrib/tsearch2 in the 8.2 branch, with a
regression diff like this:
*** 2453,2459
Sea view wow foo bar qq
http://ww
"Kevin Flanagan" writes:
> Aha. I'd read that the build process for the contrib modules involved
> generating a .DEF file for the necessary exports. I had the impression that
> defining BUILDING_DLL was an alternative, addressing (part) of the issue
> (that is, PG_FUNCTION_INFO_V1 declares functio
Aha. I'd read that the build process for the contrib modules involved
generating a .DEF file for the necessary exports. I had the impression that
defining BUILDING_DLL was an alternative, addressing (part) of the issue
(that is, PG_FUNCTION_INFO_V1 declares functions as 'extern PGDLLIMPORT',
and if
On 3/10/10 3:38 AM, Greg Stark wrote:
> I think that means that a
> vacuum_defer_cleanup of up to about 100 or so (it depends on the width
> of your counter record) might be reasonable as a general suggestion
> but anything higher will depend on understanding the specific system.
100 wouldn't be u
"Kevin Flanagan" writes:
>>> Hard to tell without seeing the actual code and a stack trace, but I'd
>>> bet that you haven't fully resolved the build process problems you
>>> mentioned earlier.
> I've attached a zip of the (tiny) project, and a text file with the contents
> of the module contai
On Wed, Mar 10, 2010 at 01:28:55PM -0500, Tom Lane wrote:
> =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= writes:
> > Tom Lane writes:
> >> It builds for everybody else (and we do have multiple mingw
> >> machines in the buildfarm, so it's not like this doesn't get
> >> tested). I think there is some oth
=?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= writes:
> Tom Lane writes:
>> It builds for everybody else (and we do have multiple mingw machines in
>> the buildfarm, so it's not like this doesn't get tested). I think there
>> is some other factor involved here, and you need to identify what that
>> is.
Tom Lane writes:
> "Dag-Erling Smørgrav" writes:
> > Without this patch, pg_ctl fails to build...
> It builds for everybody else (and we do have multiple mingw machines in
> the buildfarm, so it's not like this doesn't get tested). I think there
> is some other factor involved here, and you need
=?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= writes:
> Magnus Hagander writes:
>> But the fix seems wrong. If you are using a static libpq, the library
>> should be added whenever you link that library into your client
>> application. Not for every single EXE and DLL that postgres produces.
> Without th
Tom Lane writes:
> We don't support linking the backend into other applications.
libpq uses this as well.
> If you're complaining about libpq, the right thing for that is to use
> a platform that can suppress non-exported symbols from a shared
> library. Maybe what we need to do is teach the mi
Magnus Hagander writes:
> Dag-Erling Smørgrav writes:
> > Your users might need to link with both. I'm working on an
> > application that generates animations (specifically, animated
> > weather forecasts) based on data retrieved from a PostgreSQL
> > database.
> This shows up only with static
=?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= writes:
> Tom Lane writes:
>> "Dag-Erling Smørgrav" writes:
>>> 1. PostgreSQL's private versions of inet_aton etc. can conflict with
>>> similar functions in other libraries (in my case, PostgreSQL's
>>> inet_aton conflicts with libavformat's).
>> So what?
2010/3/10 Dag-Erling Smørgrav :
> Tom Lane writes:
>> "Dag-Erling Smørgrav" writes:
>> > 1. PostgreSQL's private versions of inet_aton etc. can conflict with
>> > similar functions in other libraries (in my case, PostgreSQL's
>> > inet_aton conflicts with libavformat's).
>> So what? We
Tom Lane writes:
> "Dag-Erling Smørgrav" writes:
> > 1. PostgreSQL's private versions of inet_aton etc. can conflict with
> > similar functions in other libraries (in my case, PostgreSQL's
> > inet_aton conflicts with libavformat's).
> So what? We don't link with those libraries.
Your
On Wed, Mar 3, 2010 at 7:16 PM, Robert Haas wrote:
> 2010/3/3 KaiGai Kohei :
>> (2010/03/03 22:42), Robert Haas wrote:
>>> 2010/3/3 KaiGai Kohei:
(2010/03/03 14:26), Robert Haas wrote:
> 2010/3/2 KaiGai Kohei:
>> Is it an expected behavior?
>>
>> postgres=> CREATE SEQUEN
=?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= writes:
> I've run across a couple of stumbling blocks when building on Win32
> (specifically, XP + MinGW):
> 1. PostgreSQL's private versions of inet_aton etc. can conflict with
> similar functions in other libraries (in my case, PostgreSQL's
> inet_
I've run across a couple of stumbling blocks when building on Win32
(specifically, XP + MinGW):
1. PostgreSQL's private versions of inet_aton etc. can conflict with
similar functions in other libraries (in my case, PostgreSQL's
inet_aton conflicts with libavformat's).
2. On Win32, Postg
hubert depesz lubaczewski wrote:
On Tue, Mar 09, 2010 at 06:59:31PM +0100, Pavel Stehule wrote:
2010/3/9 strk :
How can a pl/pgsql trigger change the
values of dynamic fields in NEW record ?
By "dynamic" I mean that the field name
is a variable in the trigger context.
I've been told
On Wed, Mar 10, 2010 at 6:29 AM, Josh Berkus wrote:
> Then I increased vacuum_defer_cleanup_age to 10, which represents
> about 5 minutes of transactions on the test system. This eliminated all
> query cancels for the reporting query, which takes an average of 10s.
>
> Next is a database bloa
On Tue, Mar 09, 2010 at 06:59:31PM +0100, Pavel Stehule wrote:
> 2010/3/9 strk :
> > How can a pl/pgsql trigger change the
> > values of dynamic fields in NEW record ?
> >
> > By "dynamic" I mean that the field name
> > is a variable in the trigger context.
> >
> > I've been told it's easy to do wi
Hi,
http://archives.postgresql.org/pgsql-hackers/2010-01/msg01672.php
On win32, the blocking libpq functions like PQconnectdb() and
PQexec() are uninterruptible since they use the vanilla select()
instead of our signal emulation layer compatible select().
Nevertheless, currently walreceiver uses t
30 matches
Mail list logo
