Re: [HACKERS] about some parameters

Tom Lane wrote: > Jaime Casanova 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 postgresql.conf

Re: [HACKERS] Win64 warnings about size_t

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 h

[HACKERS] Testing with concurrent sessions

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 con

Re: [HACKERS] Change to config.pl processing in the msvc build environment

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 an

Re: [HACKERS] Cancelling idle in transaction state

On Fri, Jan 1, 2010 at 10:45 PM, Simon Riggs 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 infrastructure to

Re: [HACKERS] PATCH: Add hstore_to_json()

Andrew Dunstan 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 far out of our

Re: [HACKERS] PATCH: Add hstore_to_json()

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 an

Re: [HACKERS] Cancelling idle in transaction state

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

Re: [HACKERS] Cancelling idle in transaction state

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 regar

Re: [HACKERS] Serializable Isolation without blocking

"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 snaps

Re: [HACKERS] win32 socket definition

On Fri, Jan 1, 2010 at 20:41, Tom Lane wrote: > Magnus Hagander 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 defin

Re: [HACKERS] IntArray in c.h

On tor, 2009-12-31 at 11:28 -0500, Tom Lane wrote: > Peter Eisentraut 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 regproc, tran

Re: [HACKERS] Win64 warnings about size_t

On Fri, Jan 1, 2010 at 20:33, Tom Lane wrote: > Magnus Hagander writes: >> On Fri, Jan 1, 2010 at 20:12, Peter Eisentraut 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 << ... w

Re: [HACKERS] [PATCH] Windows x64 [repost]

On Fri, Dec 4, 2009 at 11:42, Tsutomu Yamada 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 __nop: http://msdn.mic

Re: [HACKERS] win32 socket definition

Magnus Hagander 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 > anything there, j

Re: [HACKERS] Win64 warnings about size_t

Magnus Hagander writes: > On Fri, Jan 1, 2010 at 20:12, Peter Eisentraut 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 fix it. 1LL did, however.

Re: [HACKERS] Win64 warnings about size_t

On Fri, Jan 1, 2010 at 20:12, Peter Eisentraut 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?) >>   .\src\backend\utils\mmgr

[HACKERS] win32 socket definition

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 appl

Re: [HACKERS] Win64 warnings about size_t

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

Re: [HACKERS] PATCH: Add hstore_to_json()

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 in

Re: [HACKERS] Win64 warnings about size_t

On Fri, Jan 1, 2010 at 18:59, Tom Lane wrote: > Magnus Hagander writes: >> On Fri, Jan 1, 2010 at 18:47, Tom Lane 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. Accordin

Re: [HACKERS] uintptr_t for Datum

On tor, 2009-12-31 at 13:44 -0500, Bruce Momjian wrote: > Tom Lane wrote: > > Bruce Momjian 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

Re: [HACKERS] Thoughts on statistics for continuously advancing columns

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 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 > > > the te

Re: [HACKERS] Cancelling idle in transaction state

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 fro

Re: [HACKERS] Serializable Isolation without blocking

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 tracki

Re: [HACKERS] Cancelling idle in transaction state

On Jan 1, 2010, at 9:42 AM, Simon Riggs 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 there are any such cases.

Re: [HACKERS] Win64 warnings about size_t

Magnus Hagander writes: > On Fri, Jan 1, 2010 at 18:47, Tom Lane 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 > http://msdn.microsoft.com/en-us/library/6kck0s9

Re: [HACKERS] Win64 warnings about size_t

On Fri, Jan 1, 2010 at 18:47, Tom Lane wrote: > Magnus Hagander 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.  Getti

Re: [HACKERS] Win64 warnings about size_t

Magnus Hagander 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 impractical I think, and p

Re: [HACKERS] Cancelling idle in transaction state

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, deadlo

Re: [HACKERS] Cancelling idle in transaction state

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

[HACKERS] Win64 warnings about size_t

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 assign

Re: [HACKERS] Cancelling idle in transaction state

On Jan 1, 2010, at 8:30 AM, Simon Riggs wrote: On Fri, 2010-01-01 at 07:08 -0800, Robert Haas wrote: On Jan 1, 2010, at 6:48 AM, Simon Riggs w We could either endlessly repeat this ERROR: current transaction is aborted because of conflict with recovery, commands ignored until end of transac

Re: [HACKERS] about some parameters

Jaime Casanova 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 postgresql.conf where it's so > vulne

Re: [HACKERS] Cancelling idle in transaction state

On Fri, 2010-01-01 at 07:08 -0800, Robert Haas wrote: > On Jan 1, 2010, at 6:48 AM, Simon Riggs 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.

Re: [HACKERS] Cancelling idle in transaction state

On Fri, Jan 1, 2010 at 8:38 PM, Robert Haas wrote: > On Jan 1, 2010, at 6:48 AM, Simon Riggs 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.

[HACKERS] Change to config.pl processing in the msvc build environment

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 mi

Re: [HACKERS] Cancelling idle in transaction state

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 requ

Re: [HACKERS] Cancelling idle in transaction state

On Jan 1, 2010, at 6:48 AM, Simon Riggs 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 out Hot Standby to gene

Re: [HACKERS] krb_server_keyfile setting doesn't work on Windows

On Thu, Dec 31, 2009 at 00:57, Magnus Hagander wrote: > 2009/12/31 Hiroshi Inoue : >> Magnus Hagander wrote: >>> >>> 2009/12/30 Hiroshi Inoue : Hi, As far as I tested, the krb_server_keyfile setting in postgres.conf doesn't work on Windows. Because gssapi32.dll(k

Re: [HACKERS] Cancelling idle in transaction state

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 AbortTransactionAndAn

Re: [HACKERS] Cancelling idle in transaction state

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

Re: [HACKERS] PATCH: Add hstore_to_json()

Andrew Dunstan writes: >> Does anyone have any real-world experience with any of the JSON C libraries? > > I do not, but I see that YAJL is now in > Fedora, and has a BSDish license It's there in debian too, unstable and testing, and should be there on the next sta