Andrew Dunstan and...@dunslane.net writes:
Does anyone have any real-world experience with any of the JSON C libraries?
I do not, but I see that YAJL http://lloyd.github.com/yajl/ is now in
Fedora, and has a BSDish license
It's there in debian too, unstable and testing, and should be there on
Simon Riggs wrote:
Attached is the patch I intend to commit, barring objections.
This patch extends SIGINT to allow cancellation of transactions while
idle in both HS and normal mode.
How does AbortTransactionAndAnySubtransactions() differ from
AbortOutOfAnyTransaction()? Having followed the
On Fri, 2010-01-01 at 12:53 +0200, Heikki Linnakangas wrote:
Simon Riggs wrote:
Attached is the patch I intend to commit, barring objections.
This patch extends SIGINT to allow cancellation of transactions while
idle in both HS and normal mode.
How does
On Thu, Dec 31, 2009 at 00:57, Magnus Hagander mag...@hagander.net wrote:
2009/12/31 Hiroshi Inoue in...@tpf.co.jp:
Magnus Hagander wrote:
2009/12/30 Hiroshi Inoue in...@tpf.co.jp:
Hi,
As far as I tested, the krb_server_keyfile setting
in postgres.conf doesn't work on Windows.
Because
On Jan 1, 2010, at 6:48 AM, Simon Riggs si...@2ndquadrant.com w
We could either endlessly repeat this
ERROR: current transaction is aborted because of conflict with
recovery, commands ignored until end of transaction block
+1 for this option.
I'm also not sure why we would want to single
Simon Riggs wrote:
On Fri, 2010-01-01 at 12:53 +0200, Heikki Linnakangas wrote:
I agree with Joachim's comments upthread that we should have a different
function for forcefully aborting the whole transaction, and leave the
current pg_cancel_backend() behavior alone.
That would require
I'd like to apply the attached patch to the msvc build environment,
which changes how config.pl is handled. (For the unenlightened, this
is the replacement stuff we have for autoconf)
Today, there is one config.pl. We ship it with a couple of defaults
(which points to a very old installation of
On Fri, Jan 1, 2010 at 8:38 PM, Robert Haas robertmh...@gmail.com wrote:
On Jan 1, 2010, at 6:48 AM, Simon Riggs si...@2ndquadrant.com w
We could either endlessly repeat this
ERROR: current transaction is aborted because of conflict with
recovery, commands ignored until end of transaction
On Fri, 2010-01-01 at 07:08 -0800, Robert Haas wrote:
On Jan 1, 2010, at 6:48 AM, Simon Riggs si...@2ndquadrant.com w
We could either endlessly repeat this
ERROR: current transaction is aborted because of conflict with
recovery, commands ignored until end of transaction block
+1 for
Jaime Casanova jcasa...@systemguards.com.ec writes:
Every time i explain what is the fsync parameter for, the next thing i
always say is: never turn it off, and now that we have
synchronous_commit there is no good reason for turn fsync off... so
why are we still let it be in the
On Jan 1, 2010, at 8:30 AM, Simon Riggs si...@2ndquadrant.com wrote:
On Fri, 2010-01-01 at 07:08 -0800, Robert Haas wrote:
On Jan 1, 2010, at 6:48 AM, Simon Riggs si...@2ndquadrant.com w
We could either endlessly repeat this
ERROR: current transaction is aborted because of conflict with
I have adapted the win64 patches a bit, and now have a working build.
As in it runs the regression tests fine. However, I have well over a
thousand warnings of the type:
conversion from 'size_t' to 'int', possible loss of data
My first 5-6 checks of where these happen are all cases where we
On Fri, 2010-01-01 at 17:14 +0200, Heikki Linnakangas wrote:
Which amounts to rejecting this patch, since *this* patch changes the
behaviour of SIGINT for all senders, which is what I understood people
desired, i.e. not just a change for Hot Standby. I assumed Joachim did
not mean to veto
On Fri, 2010-01-01 at 09:24 -0800, Robert Haas wrote:
If we have other events that can asynchronously roll back a
transaction, I would think they would deserve similar handling. Off
the top of my head, I'm not sure if there are any such cases.
Serialization failures, deadlocks,
Magnus Hagander mag...@hagander.net writes:
My first 5-6 checks of where these happen are all cases where we
assign the result of strlen() something to an int, or call a function
taking an int as parameter with the result of strlen() in there.
Yeah. Getting rid of all those cases is
On Fri, Jan 1, 2010 at 18:47, Tom Lane t...@sss.pgh.pa.us wrote:
Magnus Hagander mag...@hagander.net writes:
My first 5-6 checks of where these happen are all cases where we
assign the result of strlen() something to an int, or call a function
taking an int as parameter with the result of
Magnus Hagander mag...@hagander.net writes:
On Fri, Jan 1, 2010 at 18:47, Tom Lane t...@sss.pgh.pa.us wrote:
I think MSVC is just complaining about something gcc doesn't. If you
can disable this specific warning it'd be a good plan.
Yeah, that should be doable. According to
On Jan 1, 2010, at 9:42 AM, Simon Riggs si...@2ndquadrant.com wrote:
On Fri, 2010-01-01 at 09:24 -0800, Robert Haas wrote:
If we have other events that can asynchronously roll back a
transaction, I would think they would deserve similar handling.
Off
the top of my head, I'm not sure if
Kevin Grittner wrote:
It seems to me that the hard part of this problem is to describe
the general mechanism by which conflicts will be detected, with
specific references to the types of data structures that will be
used to hold that information.
Well, the general approach to tracking SIREAD
On Fri, 2010-01-01 at 10:15 -0800, Robert Haas wrote:
Hmm. I don't think I can get a serialization failure, deadlock, or
out
of memory error while my session is idle.
Agreed. As a point of note, now that we can cancel idle transactions
there isn't any future blocker from making
On Thu, 2009-12-31 at 21:29 +, Simon Riggs wrote:
On Thu, 2009-12-31 at 15:18 -0500, Tom Lane wrote:
Simon Riggs si...@2ndquadrant.com writes:
Why not get both max() and min(), then rebase the histogram according to
those values. That way the histogram can still move significantly and
On tor, 2009-12-31 at 13:44 -0500, Bruce Momjian wrote:
Tom Lane wrote:
Bruce Momjian br...@momjian.us writes:
Tom Lane wrote:
BTW, it looks like the patch is showing a manual change to
pg_config.h.in. Don't do that. Run autoheader.
I wasn't aware autoheader existed. Is that
On Fri, Jan 1, 2010 at 18:59, Tom Lane t...@sss.pgh.pa.us wrote:
Magnus Hagander mag...@hagander.net writes:
On Fri, Jan 1, 2010 at 18:47, Tom Lane t...@sss.pgh.pa.us wrote:
I think MSVC is just complaining about something gcc doesn't. If you
can disable this specific warning it'd be a good
On tor, 2009-12-31 at 11:12 -0500, Andrew Dunstan wrote:
David E. Wheeler wrote:
On Dec 31, 2009, at 1:04 AM, Peter Eisentraut wrote:
I think the primary use will be to load a JSON value into Perl or Python
and process it there. So a json type that doesn't have any interesting
On fre, 2010-01-01 at 20:01 +0100, Magnus Hagander wrote:
.\src\backend\utils\mmgr\aset.c(701): warning C4334: '' : result
of 32-bit shift implicitly converted to 64 bits (was 64-bit shift
intended?)
.\src\backend\utils\mmgr\aset.c(705): warning C4334: '' : result
of 32-bit shift
The win64 port has showed that we have two sockets declared
incorrectly. They are supposed to be declared as SOCKET on win32, but
they are declared as int. See attached patch.
Given that SOCKET is actually defined as int on win32 (no warnings or
anything there, just on win64), I'm inclined to
On Fri, Jan 1, 2010 at 20:12, Peter Eisentraut pete...@gmx.net wrote:
On fre, 2010-01-01 at 20:01 +0100, Magnus Hagander wrote:
.\src\backend\utils\mmgr\aset.c(701): warning C4334: '' : result
of 32-bit shift implicitly converted to 64 bits (was 64-bit shift
intended?)
Magnus Hagander mag...@hagander.net writes:
On Fri, Jan 1, 2010 at 20:12, Peter Eisentraut pete...@gmx.net wrote:
This shouldn't be a problem for the same reason that casting size_t to
int is not a problem in the PostgreSQL backend code, but perhaps writing
1L ... would fix it.
1L didn't
Magnus Hagander mag...@hagander.net writes:
The win64 port has showed that we have two sockets declared
incorrectly. They are supposed to be declared as SOCKET on win32, but
they are declared as int. See attached patch.
Given that SOCKET is actually defined as int on win32 (no warnings or
On Fri, Dec 4, 2009 at 11:42, Tsutomu Yamada tsut...@sraoss.co.jp wrote:
2) use appropriate macro and datatypes for Windows API.
enables more than 32bits shared memory.
Are you sure this one should use __noop, and not __nop?
__noop: http://msdn.microsoft.com/en-us/library/s6btaxcs.aspx
On Fri, Jan 1, 2010 at 20:33, Tom Lane t...@sss.pgh.pa.us wrote:
Magnus Hagander mag...@hagander.net writes:
On Fri, Jan 1, 2010 at 20:12, Peter Eisentraut pete...@gmx.net wrote:
This shouldn't be a problem for the same reason that casting size_t to
int is not a problem in the PostgreSQL
On tor, 2009-12-31 at 11:28 -0500, Tom Lane wrote:
Peter Eisentraut pete...@gmx.net writes:
The definition of c.h is bogus anyway. You might think it contains
includes and defines to set up a portable C environment, which is what
the first half indeed does.
But then things like
On Fri, Jan 1, 2010 at 20:41, Tom Lane t...@sss.pgh.pa.us wrote:
Magnus Hagander mag...@hagander.net writes:
The win64 port has showed that we have two sockets declared
incorrectly. They are supposed to be declared as SOCKET on win32, but
they are declared as int. See attached patch.
Given
Albe Laurenz wrote:
If I remember right, one necessity for the SIREAD lock technique
was that SIREAD locks taken by a transaction have to be kept after
the transaction has ended.
Correct. An SIREAD lock must be held until completion of the last
serializable transaction holding a snapshot
On Thu, 31 Dec 2009, Simon Riggs wrote:
On Thu, 2009-12-31 at 15:41 +0100, Joachim Wieland wrote:
I still think that we should have three transaction cancel modes, one
to cancel an idle transaction, another one to cancel a running query
and a third one that just cancels the transaction
On Fri, 2010-01-01 at 15:31 -0500, Kris Jurka wrote:
On Thu, 31 Dec 2009, Simon Riggs wrote:
On Thu, 2009-12-31 at 15:41 +0100, Joachim Wieland wrote:
I still think that we should have three transaction cancel modes, one
to cancel an idle transaction, another one to cancel a running
Peter Eisentraut wrote:
IMNSHO it's essential. I think Peter's approach of ignoring this
requirement is extremely shortsighted.
Whose requirement is it? I'm not ignoring it, but so far no one has
actually said that it is a requirement and why.
Mine for one :-). Quite apart from
Andrew Dunstan and...@dunslane.net writes:
Peter Eisentraut wrote:
Whose requirement is it? I'm not ignoring it, but so far no one has
actually said that it is a requirement and why.
Mine for one :-).
I think there are a couple of interacting factors here. We are not
likely to want to go
On Fri, Jan 1, 2010 at 10:45 PM, Simon Riggs si...@2ndquadrant.com wrote:
I would recommend we make SIGINT do cancel-anything, and handle
everything else via SIGUSR1, including CancelRequest. I'm not going to
do that; I'm going to make HS conflict resolution work, which means
putting in enough
Magnus Hagander wrote:
I therefor propose that we rename this file to config.pl.default,
and change the scripts to first load config.pl.default, and then load
config.pl if it exists. config.pl then lives completely outside the
source tree (should be in .cvsignore) and won't show up in any
There has been periodic discussion here about allowing psql to deal
with multiple sessions, or possibly creating another tool to allow
this sort of test. Is anyone working on this?
It's very soon going to be critical that I be able to test particular
interleavings of statements in particular
Magnus Hagander wrote:
I have adapted the win64 patches a bit, and now have a working build.
As in it runs the regression tests fine. However, I have well over a
thousand warnings of the type:
conversion from 'size_t' to 'int', possible loss of data
My first 5-6 checks of where these happen
Tom Lane wrote:
Jaime Casanova jcasa...@systemguards.com.ec writes:
Every time i explain what is the fsync parameter for, the next thing i
always say is: never turn it off, and now that we have
synchronous_commit there is no good reason for turn fsync off... so
why are we still let it be in
43 matches
Mail list logo
