I wrote:
it might be that the only machines that actually spit up on the hint bit
(rather than ignore it) were 32-bit, in which case this would be a
usable heuristic. Not sure how we can research that ... do we want to
just assume the kernel guys know what they're doing?
I did a bit of
-TAS_SPIN-20120101.diff
Description: Binary data
BTW, while reading the ISA document I couldn't help noticing that LWARX
is clearly specified to operate on 4-byte quantities (there's LDARX if
you want to use 8-byte). Which seems to mean that this bit in s_lock.h
just represents bogus waste of space
Hello all
here is new version of CHECK FUNCTION patch
I changed implementation of interface:
* checked functions returns table instead raising exceptions - it
necessary for describing more issues inside one function - and it
allow to use better structured data then ExceptionData
postgres=#
On 30.12.2011 02:40, Daniel Farina wrote:
How about this revised protocol (names and adjustments welcome), to
enable a less-terrible approach? Not only is that workaround
incorrect (it has a small window where the system will not be able to
restart), but it's pretty inconvenient.
New concepts:
On Sun, Jan 1, 2012 at 14:18, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
On 30.12.2011 02:40, Daniel Farina wrote:
How about this revised protocol (names and adjustments welcome), to
enable a less-terrible approach? Not only is that workaround
incorrect (it has a small
On 12/31/2011 04:26 PM, Aidan Van Dyk wrote:
On Sat, Dec 31, 2011 at 3:17 PM, Alvaro Herrera
alvhe...@commandprompt.com wrote:
Excerpts from Andrew Dunstan's message of sáb dic 31 12:52:02 -0300 2011:
It's not a big thing, but I just found myself in a shared environment
wanting to be able
On Sun, Jan 1, 2012 at 5:18 AM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
That's awfully complicated. If we're going to require co-operation from the
backup/archiving software, we might as well just change the procedure so
that backup_label is not stored in the data
On Sun, Jan 1, 2012 at 6:13 AM, Magnus Hagander mag...@hagander.net wrote:
It also doesn't affect backups taken through pg_basebackup - but I
guess you have good reasons for not being able to use that?
Parallel archiving/de-archiving and segmentation of the backup into
pieces and rate limiting
On 12/31/2011 06:10 PM, Brar Piening wrote:
Brar Piening wrote:
Andrew Dunstan wrote:
Can you narrow down exactly what in that commit broke VS 2010? Are
there any compiler warnings?
I was able to nail down the problem.
In the absence of reaction, to keep my promise, I'm sending the
I think I would like to have a set of GUC parameters to control the
location of the server-side SSL files. In a setup that has all the
other configuration files under /etc, the SSL files ought to go there as
well. (For comparison, most email and web servers keep them there.)
Having them in the
On mån, 2011-02-28 at 19:07 +0200, Peter Eisentraut wrote:
PL/pgSQL trigger functions currently require a value to be returned,
even though that value is not used for anything in case of a trigger
fired AFTER. I was wondering if we could relax that. It would make
things a bit more robust and
On sön, 2011-11-27 at 17:29 -0500, Tom Lane wrote:
Peter Eisentraut pete...@gmx.net writes:
This ought to show EXECUTE privilege on the new function, but it
doesn't, because proacl is null, and nothing in the information schema
handles that specially.
I've pondered some ways to fix
Currently, pg_dump sorts operators by name, but operators with the same
name come out in random order. A few releases ago we adjusted this for
functions, so that they are in increasing number of arguments order.
I'd like to do this for operators as well, so that they come out in
order, say,
2012/1/2 Peter Eisentraut pete...@gmx.net:
On mån, 2011-02-28 at 19:07 +0200, Peter Eisentraut wrote:
PL/pgSQL trigger functions currently require a value to be returned,
even though that value is not used for anything in case of a trigger
fired AFTER. I was wondering if we could relax that.
Manabu Ori manabu@gmail.com writes:
I recreated the patch as you advised.
Hmm, guess I wasn't clear --- we still need a configure test, since even
if we are on PPC64 there's no guarantee that the assembler will accept
the hint bit.
I revised the patch to include a configure test and
I ported the entire schema to my test DB server and could not reproduce
the error there. Note that probably recreating the view solves this
issue. Given this, how should I proceed to create a test case? Any
tutorial on this? (I'm not too familiar with all this yet.)
It's possibly
16 matches
Mail list logo
