Andrew Dunstan wrote:
Not to my knowledge, but I have no method of testing what's going on,
and I hate guessing like this - in fact this is what has worried me all
along about supporting MSVC builds - we always said we didn't want to
have to have 2 build environments, but now we have two and
Hiroshi Inoue wrote:
Concurrently updating an updatable view seems to cause
an unexpected result. Is it a known issue?
Looks right to me. What did you expect?
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
---(end of
Heikki Linnakangas wrote:
Hiroshi Inoue wrote:
Concurrently updating an updatable view seems to cause
an unexpected result. Is it a known issue?
Looks right to me. What did you expect?
Shouldn't the last response
(session-2)
UPDATE 1
be
(seesion-2)
UPDATE 0
?
Hiroshi Inoue wrote:
Heikki Linnakangas wrote:
Hiroshi Inoue wrote:
Concurrently updating an updatable view seems to cause
an unexpected result. Is it a known issue?
Looks right to me. What did you expect?
Shouldn't the last response
(session-2)
UPDATE 1
be
(seesion-2)
Tom Lane wrote:
So I now state fairly confidently that baiji is failing to overwrite
*any* of the installation tree, /share and /bin both, and instead is
testing an installation dating from sometime between May 1 and May 11.
Close. There was an Msys build from the 9th running on port 5432.
Heikki Linnakangas wrote:
The problem is that the new tuple version is checked only against the
condition in the update rule, id=OLD.id, but not the condition in the
original update-claus, dt='a'.
Yeah, that's confusing :(.
Bit more than just normal rule confusion I'd say. Try the following
Close. There was an Msys build from the 9th running on port 5432.
2) VC++ and Msys builds will both happily start on the same
port at the same time. The first one to start listens on 5432
until it shuts down, at which point the second server takes
over seamlessly! It doesn't matter which
Heikki Linnakangas napsal(a):
Jim C. Nasby wrote:
There is two counters for checkpoints in pgstats, the number of timed
(triggered by checkpoint_timeout) and requested (triggered by
checkpoint_segments) checkpoints.
Maybe we should improve the stats system so that we can collect events
Simon Riggs wrote:
On Fri, 2007-05-11 at 22:59 +0100, Heikki Linnakangas wrote:
For comparison, here's the test results with vanilla CVS HEAD:
copy-head | 00:06:21.533137
copy-head | 00:05:54.141285
I'm slightly worried that the results for COPY aren't anywhere near as
Zeugswetter Andreas ADI SD wrote:
Close. There was an Msys build from the 9th running on port 5432.
2) VC++ and Msys builds will both happily start on the same
port at the same time. The first one to start listens on 5432
until it shuts down, at which point the second server takes
over
Dave Page wrote:
Tom Lane wrote:
So I now state fairly confidently that baiji is failing to overwrite
*any* of the installation tree, /share and /bin both, and instead is
testing an installation dating from sometime between May 1 and May 11.
Close. There was an Msys build from the
Dave Page [EMAIL PROTECTED] writes:
2) VC++ and Msys builds will both happily start on the same port at the
same time. The first one to start listens on 5432 until it shuts down,
at which point the second server takes over seamlessly!
Uh ... so the lock-file stuff is completely broken on
Andrew Dunstan wrote:
I'll look at the port mess.
Are you running 2 buildfarm members on the same machine? If so, you
should look at using the multi-root factility which is explicitly
designed to avoid clashes of this sort.
Yes, I've got VC++ and Mingw/Msys animals on each of two
I wrote:
Uh ... so the lock-file stuff is completely broken on Windows?
Not so much broken as commented out ... on looking at the code, it's
blindingly obvious that we don't even try to create a socket lock file
if not HAVE_UNIX_SOCKETS. Sigh.
There is a related risk even on Unix machines: two
On Mon, May 14, 2007 at 08:50:54AM -0400, Tom Lane wrote:
I wrote:
Uh ... so the lock-file stuff is completely broken on Windows?
Not so much broken as commented out ... on looking at the code, it's
blindingly obvious that we don't even try to create a socket lock file
if not
Magnus Hagander [EMAIL PROTECTED] writes:
If all we want to do is add a check that prevents two servers to start on
the same port, we could do that trivially in a win32 specific way (since
we'll never have unix sockets there). Just create an object in the global
namespace named
* Tom Lane ([EMAIL PROTECTED]) wrote:
There is a related risk even on Unix machines: two postmasters can be
started on the same port number if they have different settings of
unix_socket_directory, and then it's indeterminate which one you will
contact if you connect to the TCP port. I seem
Stephen Frost wrote:
* Tom Lane ([EMAIL PROTECTED]) wrote:
There is a related risk even on Unix machines: two postmasters can be
started on the same port number if they have different settings of
unix_socket_directory, and then it's indeterminate which one you will
contact if you connect to
Tom Lane [EMAIL PROTECTED] writes:
I wrote:
Uh ... so the lock-file stuff is completely broken on Windows?
Not so much broken as commented out ... on looking at the code, it's
blindingly obvious that we don't even try to create a socket lock file
if not HAVE_UNIX_SOCKETS. Sigh.
Isn't the
On Mon, May 14, 2007 at 09:02:10AM -0400, Tom Lane wrote:
Magnus Hagander [EMAIL PROTECTED] writes:
If all we want to do is add a check that prevents two servers to start on
the same port, we could do that trivially in a win32 specific way (since
we'll never have unix sockets there). Just
Magnus Hagander wrote:
On Mon, May 14, 2007 at 09:02:10AM -0400, Tom Lane wrote:
Magnus Hagander [EMAIL PROTECTED] writes:
If all we want to do is add a check that prevents two servers to start on
the same port, we could do that trivially in a win32 specific way (since
we'll never
Dave Page [EMAIL PROTECTED] writes:
Stephen Frost wrote:
I'm curious as to which Unix systems allow multiple processes to listen
on the same port at the same time.. On Linux, and I thought on most,
you get an EADDRINUSE on the listen() call (which the postmaster should
pick up on and bomb
Tom Lane wrote:
Setting the SO_REUSEADDR option allows the local socket address to be
reused in subsequent calls to bind(). This permits multiple
SOCK_STREAM sockets to be bound to the same local address, as long as
all existing sockets with the desired local address are
Tom Lane wrote:
Windows seems to treat SO_REUSEADDR in the same
way as SO_REUSEPORT which just seems wrong.
Well, Microsoft getting standards wrong is no surprise. So what do we
want to do about it?
Microsoft did lift that code from BSD many moons ago, so it might be
worth checking if the
Andrew Dunstan wrote:
Magnus Hagander wrote:
On Mon, May 14, 2007 at 09:02:10AM -0400, Tom Lane wrote:
Magnus Hagander [EMAIL PROTECTED] writes:
If all we want to do is add a check that prevents two servers to start on
the same port, we could do that trivially in a win32
Andrew Dunstan [EMAIL PROTECTED] writes:
Magnus Hagander wrote:
If all we want to do is add a check that prevents two servers to start on
the same port, we could do that trivially in a win32 specific way (since
we'll never have unix sockets there). Just create an object in the global
On Mon, May 14, 2007 at 09:49:47AM -0400, Tom Lane wrote:
Andrew Dunstan [EMAIL PROTECTED] writes:
Magnus Hagander wrote:
If all we want to do is add a check that prevents two servers to start on
the same port, we could do that trivially in a win32 specific way (since
we'll never have
On Mon, May 14, 2007 at 09:34:05AM -0400, Andrew Dunstan wrote:
Magnus Hagander wrote:
On Mon, May 14, 2007 at 09:02:10AM -0400, Tom Lane wrote:
Magnus Hagander [EMAIL PROTECTED] writes:
If all we want to do is add a check that prevents two servers to start on
the same port, we
Tom Lane [EMAIL PROTECTED] writes:
What happens if we just #ifndef WIN32 the setsockopt(SO_REUSEADDR)
call? I believe the reason that's in there is that some platforms will
reject bind() to a previously-used address for a TCP timeout delay after
a previous postmaster quit, but if that
Gregory Stark [EMAIL PROTECTED] writes:
Tom Lane [EMAIL PROTECTED] writes:
What happens if we just #ifndef WIN32 the setsockopt(SO_REUSEADDR)
call? I believe the reason that's in there is that some platforms will
reject bind() to a previously-used address for a TCP timeout delay after
a
Aidan Van Dyk [EMAIL PROTECTED] writes:
* Tom Lane [EMAIL PROTECTED] [070514 10:24]:
This is not a behavior required by the TCP spec AFAICS. Also, in a
quick test neither Linux nor HPUX appear to need SO_REUSEADDR --- on
both, I can restart the postmaster immediately without it.
Did you
* Tom Lane [EMAIL PROTECTED] [070514 10:24]:
This is not a behavior required by the TCP spec AFAICS. Also, in a
quick test neither Linux nor HPUX appear to need SO_REUSEADDR --- on
both, I can restart the postmaster immediately without it.
Did you have an active connection before
Tom Lane [EMAIL PROTECTED] writes:
Gregory Stark [EMAIL PROTECTED] writes:
Tom Lane [EMAIL PROTECTED] writes:
What happens if we just #ifndef WIN32 the setsockopt(SO_REUSEADDR)
call? I believe the reason that's in there is that some platforms will
reject bind() to a previously-used address
Magnus Hagander [EMAIL PROTECTED] writes:
+ sprintf(mutexName,postgresql.interlock.%i, portNumber);
That won't do; it should be legal for two postmasters to listen on
different IP addresses using the same port number. So you need to
include some representation of the IP address
Tom Lane [EMAIL PROTECTED] writes:
Um, you're right, I hadn't done the test properly. If I have an open
psql session across TCP and do pg_ctl stop -m fast, then I can't
start a new postmaster until the socket goes out of CLOSE_WAIT state.
Which, if I just leave the psql session sit there,
Gregory Stark [EMAIL PROTECTED] writes:
Tom Lane [EMAIL PROTECTED] writes:
Um, you're right, I hadn't done the test properly. If I have an open
psql session across TCP and do pg_ctl stop -m fast, then I can't
start a new postmaster until the socket goes out of CLOSE_WAIT state.
Which, if I
Dave Page wrote:
Where can I find out about multi-root? I can't see anything in the
config file, or in PGBuildFarm-HOWTO.txt
It's a hack I want to get rid of. It's a command-line option:
--multiroot = allow several members to use same build root
Of course, at least
On 5/12/2007 4:53 PM, Jan Wieck wrote:
Either calling pg_plan_queries() with needSnapshot=false or saving and
restoring ActiveSnapshot will prevent the backend from dumping core in
the mentioned example, but I am not entirely sure as to which one is the
right solution.
Attached is a self
On 2007-05-14, Tom Lane [EMAIL PROTECTED] wrote:
Aidan Van Dyk [EMAIL PROTECTED] writes:
* Tom Lane [EMAIL PROTECTED] [070514 10:24]:
This is not a behavior required by the TCP spec AFAICS. Also, in a
quick test neither Linux nor HPUX appear to need SO_REUSEADDR --- on
both, I can restart
Jan Wieck [EMAIL PROTECTED] writes:
The comment for the call of pg_plan_queries in util/cache/plancache.c
line 469 for example is fatally wrong. Not only should the snapshot be
set by all callers at this point, but if the call actually does replan
the queries, the existing ActiveSnapshot is
Is this a TODO?
---
Tom Lane wrote:
Neil Conway [EMAIL PROTECTED] writes:
When planning queries with a large IN expression in the WHERE clause,
the planner transforms the IN list into a scalar array expression. In
On May 11, 1:16 pm, Erik 2.0 [EMAIL PROTECTED] wrote:
Is pg_comparator the only project out there that does what it does? I
tried patching it, and it seems OK, but I'm not terribly confident in
my patch. I'm hoping someone will tell me there's a great table-
driven rsync out there that
Richard Huxton wrote:
Heikki Linnakangas wrote:
The problem is that the new tuple version is checked only against the
condition in the update rule, id=OLD.id, but not the condition in the
original update-claus, dt='a'.
Yeah, that's confusing :(.
Bit more than just normal rule confusion I'd
Richard Huxton wrote:
Richard Huxton wrote:
Heikki Linnakangas wrote:
The problem is that the new tuple version is checked only against the
condition in the update rule, id=OLD.id, but not the condition in the
original update-claus, dt='a'.
Yeah, that's confusing :(.
Bit more than just
hello
I didn't test it, but maybe it is what you are finding
http://pgfoundry.org/projects/apgdiff
regards
Pavel Stehule
14 May 2007 11:11:08 -0700, Andrew Hammond [EMAIL PROTECTED]:
On May 11, 1:16 pm, Erik 2.0 [EMAIL PROTECTED] wrote:
Is pg_comparator the only project out there that
Jan Wieck [EMAIL PROTECTED] writes:
The only problem with that is that there are code paths that set
ActiveSnapshot to palloc()'d memory that is released due to a
MemoryContextDelete() without resetting ActiveSnapshot to NULL.
Only at the very end of a transaction (where ActiveSnapshot *is*
On 5/14/2007 1:29 PM, Tom Lane wrote:
Jan Wieck [EMAIL PROTECTED] writes:
The comment for the call of pg_plan_queries in util/cache/plancache.c
line 469 for example is fatally wrong. Not only should the snapshot be
set by all callers at this point, but if the call actually does replan
the
Andrew Dunstan wrote:
Dave Page wrote:
Where can I find out about multi-root? I can't see anything in the
config file, or in PGBuildFarm-HOWTO.txt
It's a hack I want to get rid of. It's a command-line option:
--multiroot = allow several members to use same build root
On 5/14/2007 3:35 PM, Tom Lane wrote:
Jan Wieck [EMAIL PROTECTED] writes:
The only problem with that is that there are code paths that set
ActiveSnapshot to palloc()'d memory that is released due to a
MemoryContextDelete() without resetting ActiveSnapshot to NULL.
Only at the very end of a
Jan Wieck [EMAIL PROTECTED] writes:
Which means that the 8.3 fix for the reproducible backend crash, I
posted earlier, is to have SPI_cursor_open() save and restore
ActiveSnapshot while calling RevalidateCachedPlan(). I'll cross check
that this fixes this symptom and commit later today.
On 5/14/2007 4:26 PM, Tom Lane wrote:
Jan Wieck [EMAIL PROTECTED] writes:
Which means that the 8.3 fix for the reproducible backend crash, I
posted earlier, is to have SPI_cursor_open() save and restore
ActiveSnapshot while calling RevalidateCachedPlan(). I'll cross check
that this fixes this
Richard Huxton wrote:
Heikki Linnakangas wrote:
The problem is that the new tuple version is checked only against the
condition in the update rule, id=OLD.id, but not the condition in the
original update-claus, dt='a'.
Yeah, that's confusing :(.
Bit more than just normal rule confusion I'd
Hiroshi Inoue wrote:
Richard Huxton wrote:
Heikki Linnakangas wrote:
The problem is that the new tuple version is checked only against the
condition in the update rule, id=OLD.id, but not the condition in the
original update-claus, dt='a'.
Yeah, that's confusing :(.
Bit more than just
Alvaro Herrera wrote:
2. decide that the standard is braindead and just omit dumping the
grantor when it's no longer available, but don't remove
pg_auth_members.grantor
Which do people feel should be implemented? I can do whatever we
decide; if no one has a strong opinion on the
Dave Page wrote:
1) There appears to be no way to specify the default port number in the
MSVC build. The buildfarm passes it to configure for regular builds,
which obviously isn't run in VC++ mode, thus leaving the build on 5432.
I have committed fixes to both pgsql and buildfarm that
mastodon and skylark just failed at the make stage due to a thinko on my
part (now fixed). However, this is not correctly caught by the buildfarm
script, meaning that the process invoked at this stage ('build 21') is
not exiting properly with a non-zero status on error. That needs to be
URL added to TODO item. Patch rejected for 8.3.
---
Tom Lane wrote:
I've been studying the SQL spec in a bit more detail and I'm suddenly
thinking that we've got the behavior all wrong in the current
GENERATED/IDENTITY
Florian G. Pflug wrote:
Richard Huxton wrote:
Richard Huxton wrote:
Heikki Linnakangas wrote:
snip
Bit more than just normal rule confusion I'd say. Try the following
two statements in parallel (assuming you've just run the previous):
UPDATE test SET dt='c';
UPDATE test SET dt='x' FROM
58 matches
Mail list logo