On Fri, Jan 6, 2012 at 08:28:48AM -0500, Michael Beattie wrote:
> On Fri, Jan 6, 2012 at 6:13 AM, Magnus Hagander wrote:
>
> On Thu, Jan 5, 2012 at 23:19, Tom Lane wrote:
> > Magnus Hagander writes:
> >> On Thu, Jan 5, 2012 at 17:13, Tom Lane wrote:
> >>> I think link(2) would
Tatsuo Ishii 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 in fact using
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 t
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 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 than me
> >
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 debatabl
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 wo
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
>> 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
> Tatsuo Ishii 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 though.
Tatsuo Ishii 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 though.
> Anyway this
Tatsuo Ishii 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,
> lowrite64(explained later). I
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.
> 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)
lo_i
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
Andrew Dunstan 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 admin user is a ver
On 08/24/2012 10:10 AM, Tom Lane wrote:
Magnus Hagander writes:
On Fri, Aug 24, 2012 at 1:06 AM, Andrew Dunstan 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.
While I haven't looked at the code specific
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 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 Saturday, August 25, 2012 06:38:09 AM Tom Lane wrote:
> Andres Freund 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 breaking ours?
On Thu, Dec 29, 2011 at 10:40:19PM -0500, Tom Lane wrote:
> Merlin Moncure 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 IMMUTAB
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
20 matches
Mail list logo
