On Thu, Dec 29, 2011 at 11:37:22AM +0900, Manabu Ori wrote:
a configure test only proves whether the build machine can deal
with the flag, not whether the machine the executables will
ultimately run on knows what the flag means. We cannot assume that
the build and execution boxes are
On Thu, Dec 29, 2011 at 10:40:19PM -0500, Tom Lane wrote:
Merlin Moncure mmonc...@gmail.com writes:
On Thu, Dec 29, 2011 at 5:10 PM, Jean-Yves F. Barbier 12u...@gmail.com
wrote:
CREATE INDEX tst1m_name_lu_ix ON tst1m(unaccent(name));
ERROR: functions in index expression must be marked
On Saturday, August 25, 2012 06:38:09 AM Tom Lane wrote:
Andres Freund and...@2ndquadrant.com writes:
Doing a pqsignal(SIGFPE, FloatExceptionHandler) after PERL_SYS_INIT3
seems to work. Is that acceptable?
Surely that's breaking perl's expectations, to more or less the same
degree they're
On 26.8.2012 02:48, Tomas Vondra wrote:
On 26.8.2012 00:19, Jeff Janes wrote:
On Fri, Aug 24, 2012 at 2:16 PM, Tomas Vondra t...@fuzzy.cz wrote:
Hi,
attached is a patch that adds support for random sampling in pgbench, when
it's executed with -l flag. You can do for example this:
$
On 08/24/2012 10:10 AM, Tom Lane wrote:
Magnus Hagander mag...@hagander.net writes:
On Fri, Aug 24, 2012 at 1:06 AM, Andrew Dunstan and...@dunslane.net wrote:
TBH I'd rather stick with the less invasive approach of the original patch
at this stage, and see about refactoring for 9.3.
+1.
Andrew Dunstan and...@dunslane.net writes:
I had a brief talk with Magnus the other day, and I have just spent more
time looking over this. This is a fairly narrow failure case, with a not
so narrow proposed solution. Making pg_ctl re-exec itself whenever we
see that we're running as an
On 08/26/2012 03:15 PM, Tom Lane wrote:
BTW, one idea that occurs to me is to bypass the problem by skipping
the server's no-root-privileges check when the postmaster is given the
-C switch. (This shouldn't pose a security hazard, since reading the
config files is something a root-privileged
Hi,
I found this in the TODO list:
Add API for 64-bit large object access
If this is a still valid TODO item and nobody is working on this, I
would like to work in this.
Here are the list of functions think we need to change.
1) Frontend lo_* libpq functions(fe-lobj.c)
I found following in fe-lobj.c:
/*
* lo_lseek
*change the current read or write location on a large object
* currently, only L_SET is a legal value for whence
*
*/
I don't know where L_SET comes from. Anyway this should be:
* whence must be one of SEEK_SET, SEEK_CUR or SEEK_END.
Tatsuo Ishii is...@postgresql.org writes:
Here are the list of functions think we need to change.
1) Frontend lo_* libpq functions(fe-lobj.c)
lo_initialize() need to get backend 64-bit large object handling
function's oid, namely lo_lseek64, lo_tell64, lo_truncate64, loread64,
Tatsuo Ishii is...@postgresql.org writes:
I found following in fe-lobj.c:
* currently, only L_SET is a legal value for whence
I don't know where L_SET comes from.
Hmm, seems to be that way in the original commit to our CVS (Postgres95).
I don't find this code at all in Postgres v4r2
1) Frontend lo_* libpq functions(fe-lobj.c)
lo_initialize() need to get backend 64-bit large object handling
function's oid, namely lo_lseek64, lo_tell64, lo_truncate64, loread64,
lowrite64(explained later). If they are not available, use older
32-bit backend functions.
I don't
On Mon, Jan 2, 2012 at 11:18:47AM -0500, Andrew Dunstan wrote:
It's worked for things I've wanted, I haven't tried it for psql
stuff
Yeah, but it's a bit hacky. I might well not want $HOME reset.
Here's a small patch that does what I think would suit me and
Alvaro.
On 08/26/2012 10:13 PM, Bruce Momjian wrote:
On Mon, Jan 2, 2012 at 11:18:47AM -0500, Andrew Dunstan wrote:
It's worked for things I've wanted, I haven't tried it for psql
stuff
Yeah, but it's a bit hacky. I might well not want $HOME reset.
Here's a small patch that does what I think
On Fri, 2012-08-24 at 08:19 -0400, Bruce Momjian wrote:
Well, the idea is that the script is running stages, and your system is
mostly useful after the first stage is done. I don't see a keypress as
helping there. I think this is different from the vacuumdb case.
Well, this is all debatable,
On Tue, Jan 3, 2012 at 05:24:06PM -0700, Brad Davis wrote:
On Tue, Jan 03, 2012 at 06:43:52PM -0500, Tom Lane wrote:
Andrew Dunstan and...@dunslane.net writes:
Since I didn't actually tell you that I've made a context diff
for you, and it's attached. I'll let someone with more FBSD-fu
On Sun, Aug 26, 2012 at 11:12:15PM -0400, Peter Eisentraut wrote:
On Fri, 2012-08-24 at 08:19 -0400, Bruce Momjian wrote:
Well, the idea is that the script is running stages, and your system is
mostly useful after the first stage is done. I don't see a keypress as
helping there. I think
Tatsuo Ishii is...@postgresql.org writes:
Agreed. But looking at this brings a thought to mind: our code is
assuming that SEEK_SET, SEEK_CUR, SEEK_END have identical values on the
client and server. The lack of complaints over the past fifteen years
suggests that every Unix-oid platform is
On Fri, Jan 6, 2012 at 08:28:48AM -0500, Michael Beattie wrote:
On Fri, Jan 6, 2012 at 6:13 AM, Magnus Hagander mag...@hagander.net wrote:
On Thu, Jan 5, 2012 at 23:19, Tom Lane t...@sss.pgh.pa.us wrote:
Magnus Hagander mag...@hagander.net writes:
On Thu, Jan 5, 2012 at 17:13,
19 matches
Mail list logo
