Hello
2012/12/29 Stephen Frost :
> * Pavel Stehule (pavel.steh...@gmail.com) wrote:
>> it is a problem of this patch or not consistent constraints implementation ?
>
> Not sure, but I don't think it matters. You can blame the constraint
> implementation, but that doesn't change my feelings about
On 12/19/12 6:30 PM, Jeff Davis wrote:
The idea is to prevent interference from the bgwriter or autovacuum.
Also, I turn of fsync so that it's measuring the calculation overhead,
not the effort of actually writing to disk.
With my test server issues sorted, what I did was setup a single 7200RPM
On 12/26/12 7:23 PM, Greg Stark wrote:
It's also possible it's a bad cpu, not bad memory. If it affects
decrement or increment in particular it's possible that the pattern of
usage on LocalRefCount is particularly prone to triggering it.
This looks to be the winning answer. It turns out that u
On Sunday, January 13, 2013 12:41 AM Tom Lane wrote:
Boszormenyi Zoltan writes:
>> No, I mean the reaper(SIGNAL_ARGS) function in
>> src/backend/postmaster/postmaster.c where your patch has this:
>> *** a/src/backend/postmaster/postmaster.c
>> --- b/src/backend/postmaster/postmaster.c
>>
Heikki Linnakangas writes:
> When I compile with gcc -O0, I get one warning with this:
> datetime.c: In function DateTimeParseError:
> datetime.c:3575:1: warning: noreturn function does return [enabled by
> default]
> That suggests that the compiler didn't correctly deduce that
> ereport(E
[Catching up on old threads.]
On Sat, Nov 17, 2012 at 03:40:49PM +0100, Hannu Krosing wrote:
> On 11/17/2012 03:00 PM, Markus Wanner wrote:
>> On 11/17/2012 02:30 PM, Hannu Krosing wrote:
>>> Is it possible to replicate UPDATEs and DELETEs without a primary key in
>>> PostgreSQL-R
>> No. There mus
I have received several earnest requests over the years for LaTeX
'longtable' output, and I have just implemented it based on a sample
LaTeX longtable output file.
I have called it 'latex-longtable' and implemented all the behaviors of
ordinary latex mode. One feature is that in latex-longtable
Andres Freund writes:
> On 2013-01-12 13:16:56 -0500, Tom Lane wrote:
>> However, using a do-block with a local variable is definitely something
>> worth considering. I'm getting less enamored of the __builtin_constant_p
>> idea after finding out that the gcc boys seem to have curious ideas
>> ab
Andrew Dunstan writes:
> On 01/12/2013 04:07 PM, Tom Lane wrote:
>> ... I would
>> definitely advise that you not run the buildfarm under the same userid
>> as any live server, so that no accidental damage is possible.)
> No, I'm never going to make it unsafe to run the buildfarm alongside a
> l
On 01/12/2013 04:07 PM, Tom Lane wrote:
"Mark Hellegers" writes:
I have only one server available running Haiku. Can I also run a normal
Postgresql installation on that same machine? If so, I will be able to
run the build multiple times a day.
I believe that works at the moment, although ther
Andres Freund writes:
>>> It does *not* combine elog_start and elog_finish into one function if
>>> varargs are available although that brings a rather measurable
>>> size/performance benefit.
>> Since you've apparently already done the measurement: how much?
>> It would be a bit tedious to suppo
On 01/12/2013 10:07 PM, Tom Lane wrote:
> "Mark Hellegers" writes:
>> I have only one server available running Haiku. Can I also run a normal
>> Postgresql installation on that same machine? If so, I will be able to
>> run the build multiple times a day.
>
> I believe that works at the moment,
"Mark Hellegers" writes:
> I have only one server available running Haiku. Can I also run a normal
> Postgresql installation on that same machine? If so, I will be able to
> run the build multiple times a day.
I believe that works at the moment, although there were discussions just
yesterday ab
> "Mark Hellegers" writes:
> >> You might want to look into whether you can get the buildfarm
> > > script
> >> to run before you go too far.
>
> > I will check that this weekend. Thanks.
> > Does this buildfarm member need to run continuously?
>
> Once a day is sufficient if that's all you can
Heikki Linnakangas writes:
> On 12.01.2013 20:42, Andres Freund wrote:
>>> I don't care for that too much in detail -- if errstart were to return
>>> false (it shouldn't, but if it did) this would be utterly broken,
> With the current ereport(), we'll call abort() if errstart returns false
> and
On Tue, Oct 23, 2012 at 12:29:11PM -0400, Robert Haas wrote:
> On Tue, Oct 23, 2012 at 6:39 AM, Dhruv Ahuja wrote:
> > The "pg_ctl promote" command returns an exit code of 1 when the server
> > is not in standby mode, and the same exit code of 1 when the server
> > isn't started at all. The only d
On 12.01.2013 20:42, Andres Freund wrote:
On 2013-01-12 13:16:56 -0500, Tom Lane wrote:
Heikki Linnakangas writes:
Here's one more construct to consider:
#define ereport_domain(elevel, domain, rest) \
do { \
const int elevel_ = elevel; \
if (errst
Amit Kapila wrote:
> On Thursday, January 10, 2013 6:09 AM Josh Berkus wrote:
>> Surely VACUUM FULL should rebuild the visibility map, and make
>> tuples in the new relation all-visible, no?
Certainly it seems odd to me that VACUUM FULL leaves the the table
in a less-well maintained state in term
Boszormenyi Zoltan writes:
> No, I mean the reaper(SIGNAL_ARGS) function in
> src/backend/postmaster/postmaster.c where your patch has this:
> *** a/src/backend/postmaster/postmaster.c
> --- b/src/backend/postmaster/postmaster.c
> ***
> *** 2552,2557 reaper(SIGNAL_ARGS)
> --- 255
On 2013-01-12 13:16:56 -0500, Tom Lane wrote:
> Heikki Linnakangas writes:
> > On 11.01.2013 23:49, Tom Lane wrote:
> >> Hm ... well, that's a point. I may be putting too much weight on the
> >> fact that any such bug for elevel would be a new one that never existed
> >> before. What do others t
Heikki Linnakangas writes:
> On 11.01.2013 23:49, Tom Lane wrote:
>> Hm ... well, that's a point. I may be putting too much weight on the
>> fact that any such bug for elevel would be a new one that never existed
>> before. What do others think?
> It sure would be nice to avoid multiple evaluat
On 2013-01-12 12:26:37 +0200, Heikki Linnakangas wrote:
> On 11.01.2013 23:49, Tom Lane wrote:
> >Andres Freund writes:
> >>On 2013-01-11 16:28:13 -0500, Tom Lane wrote:
> >>>I'm not very satisfied with that answer. Right now, Peter's
> >>>patch has added a class of bugs that never existed before
Lock code says it calculates "hash value once and then pass around as needed".
But it actually calculates it twice for new locks.
Trivial patch attached to make it follow the comments in
LockTagHashCode and save a few cycles.
--
Simon Riggs http://www.2ndQuadrant.com/
Postgr
On Saturday, January 12, 2013 4:36 PM Simon Riggs wrote:
On 11 January 2013 15:57, Simon Riggs wrote:
I've moved this to the next CF. I'm planning to review this one first.
>>
>>> Thank you.
>
>> Just reviewing the patch now, making more sense with comments added.
> Making more sense, but
On Saturday, January 12, 2013 3:45 PM Simon Riggs wrote:
On 12 January 2013 03:50, Amit kapila wrote:
> On Saturday, January 12, 2013 12:23 AM Simon Riggs wrote:
> On 11 January 2013 18:11, Amit kapila wrote:
>
> Can we identify which columns have changed? i.e. 1st, 3rd and 12th
> column
Hi,
Here's a trivial patch that fixes a comment in execProcNode.c
For archeological interest, that comment dates back to when it was
written in POSTQUEL... The cleanup in
a9b1ff4c1d699c8aa615397d47bb3071275c64ef changed RETRIEVE to SELECT, but
forgot to add a FROM clause :)
Cheers,
Jan
diff
On 11 January 2013 15:57, Simon Riggs wrote:
>>> I've moved this to the next CF. I'm planning to review this one first.
>>
>> Thank you.
>
> Just reviewing the patch now, making more sense with comments added.
Making more sense, but not yet making complete sense.
I'd like you to revisit the pat
On 11.01.2013 23:49, Tom Lane wrote:
Andres Freund writes:
On 2013-01-11 16:28:13 -0500, Tom Lane wrote:
I'm not very satisfied with that answer. Right now, Peter's
patch has added a class of bugs that never existed before 9.3, and yours
would add more. It might well be that those classes ar
On 12 January 2013 03:50, Amit kapila wrote:
> On Saturday, January 12, 2013 12:23 AM Simon Riggs wrote:
> On 11 January 2013 18:11, Amit kapila wrote:
>
Can we identify which columns have changed? i.e. 1st, 3rd and 12th columns?
>>> As per current algorithm, we can't as it is based on off
29 matches
Mail list logo
