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
On Tue, Mar 09, 2010 at 06:59:31PM +0100, Pavel Stehule wrote:
2010/3/9 strk s...@keybit.net:
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
On Wed, Mar 10, 2010 at 6:29 AM, Josh Berkus j...@agliodbs.com 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
hubert depesz lubaczewski wrote:
On Tue, Mar 09, 2010 at 06:59:31PM +0100, Pavel Stehule wrote:
2010/3/9 strk s...@keybit.net:
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 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,
=?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= d...@des.no 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
On Wed, Mar 3, 2010 at 7:16 PM, Robert Haas robertmh...@gmail.com wrote:
2010/3/3 KaiGai Kohei kai...@ak.jp.nec.com:
(2010/03/03 22:42), Robert Haas wrote:
2010/3/3 KaiGai Koheikai...@ak.jp.nec.com:
(2010/03/03 14:26), Robert Haas wrote:
2010/3/2 KaiGai Koheikai...@ak.jp.nec.com:
Is it an
Tom Lane t...@sss.pgh.pa.us writes:
Dag-Erling Smørgrav d...@des.no 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
2010/3/10 Dag-Erling Smørgrav d...@des.no:
Tom Lane t...@sss.pgh.pa.us writes:
Dag-Erling Smørgrav d...@des.no 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
=?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= d...@des.no writes:
Tom Lane t...@sss.pgh.pa.us writes:
Dag-Erling Smørgrav d...@des.no 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
Magnus Hagander mag...@hagander.net writes:
Dag-Erling Smørgrav d...@des.no 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
Tom Lane t...@sss.pgh.pa.us 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
=?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= d...@des.no writes:
Magnus Hagander mag...@hagander.net 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
Tom Lane t...@sss.pgh.pa.us writes:
Dag-Erling Smørgrav d...@des.no 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
=?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= d...@des.no writes:
Tom Lane t...@sss.pgh.pa.us 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
On Wed, Mar 10, 2010 at 01:28:55PM -0500, Tom Lane wrote:
=?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= d...@des.no writes:
Tom Lane t...@sss.pgh.pa.us 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
Kevin Flanagan kevi...@linkprior.com 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
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
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
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
body
bSea/b view wow ubfoo/b bar/u
(2010/03/11 0:54), Robert Haas wrote:
On Wed, Mar 3, 2010 at 7:16 PM, Robert Haasrobertmh...@gmail.com wrote:
2010/3/3 KaiGai Koheikai...@ak.jp.nec.com:
(2010/03/03 22:42), Robert Haas wrote:
2010/3/3 KaiGai Koheikai...@ak.jp.nec.com:
(2010/03/03 14:26), Robert Haas wrote:
2010/3/2 KaiGai
On Wed, Mar 10, 2010 at 3:29 PM, Josh Berkus j...@agliodbs.com 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
Tom Lane wrote:
Bruce Momjian br...@momjian.us 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
Bruce Momjian br...@momjian.us 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
Tom Lane wrote:
Bruce Momjian br...@momjian.us 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
Fujii Masao wrote:
On Wed, Mar 10, 2010 at 3:29 PM, Josh Berkus j...@agliodbs.com 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
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 =)
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
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
29 matches
Mail list logo
