Hi,
On Fri, Jun 5, 2009 at 1:02 AM, Kolb, Harald (NSN - DE/Munich)
wrote:
> Hi,
>
> in case of a serious failure of a backend or an auxiliary process the
> postmaster performs a crash recovery and restarts the db automatically.
>
> Is there a possibility to deactivate the restart and to force the
"David E. Wheeler" writes:
> On Jun 4, 2009, at 3:58 PM, Tom Lane wrote:
>> It seems we have two reasonable possibilities for 8.4: revert that
>> patch and keep contrib/intarray's behavior the same as it was, or leave the
>> patch in and document that there was a behavioral change.
> You can't
Hi Atsushi,
> In my benchmark program, it is a little different performance
> in fls implementation and inline asm implementation.
> However, the result of a pgbench is almost the same improvement.
>
> Here is the result of my benchmark.
Excellent, thank you for getting this extra set of numbers.
Hi,
Also, are you still seeing the same improvement with the __builtin_clz
as your inline asm implementation?
In my benchmark program, it is a little different performance
in fls implementation and inline asm implementation.
However, the result of a pgbench is almost the same improvement.
Her
Move the shift-and-test login into a separate fls() function, which
can use __builtin_clz() if it's available.
This requires a new check for __builtin_clz in the configure script.
Results in a ~2% performance increase on PowerPC.
Signed-off-by: Jeremy Kerr
---
v2: prevent fls(0)
---
configur
On Thu, Jun 4, 2009 at 9:54 PM, Tatsuhito
Kasahara wrote:
> Kevin Grittner wrote:
>>
>> Greg Stark wrote:
>>>
>>> Should this patch be on the commitfest page for 8.5? Or is there a
>>> consensus already that it's a bad idea?
>>>
>>> Personally I actually think this makes a lot of sense to do.
>>
>
Kevin Grittner wrote:
Greg Stark wrote:
Should this patch be on the commitfest page for 8.5? Or is there a
consensus already that it's a bad idea?
Personally I actually think this makes a lot of sense to do.
+1
It at least gives one a reasonable chance to get a useful clue
+1
# And I'
On Jun 4, 2009, at 3:58 PM, Tom Lane wrote:
It seems we have two reasonable possibilities for 8.4: revert that
patch
and keep contrib/intarray's behavior the same as it was, or leave the
patch in and document that there was a behavioral change.
You can't keep the patch and update intarray to
Hi Atsushi,
> If size <= 8, fls((size - 1) >> ALLOC_MINBITS) is fls(0).
> The result of fls(0) is undefined.
Yep, got caught out by this because my previous fls() supported zero.
> I think we have to never call fls(0) from AllocSetFreeIndex().
> My proposal code:
>
> if (size > (1 << ALLOC_
Kevin Grittner wrote:
> Bruce Momjian wrote:
>
> > Added to TODO:
> >
> > Consider improving serialized transaction behavior to avoid
> > anomalies
> >
> > *
> http://archives.postgresql.org/pgsql-hackers/2009-05/msg01136.php
> > *
> http://archives.postgresql.org/pgsql-hackers/2009-06
One of the other open items is:
>> contrib/intarray opclass definition needs updating
>> tgl says: done, but there's another problem; see also bug #4806
The state of play on this is:
* GIN cannot find items that generate no index entries, such as empty
arrays or empty text documents.
* This i
I wrote:
> Hmm ... I'll rev up my old 32-bit-Intel machine. I suspect that the
> missing link here is some state change in the database above and beyond
> just loading the data, but since we don't know exactly what that is,
> we'll have to resort to working with Tatsuo's bitwise dump.
I poked aro
Bruce Momjian escribió:
> Alvaro Herrera wrote:
> > Robert Haas escribi?:
> >
> > > Oh, this is awesome. It would be handy to include a link on the HTML
> > > version of the page for when people are trying to pull down a patch
> > > that someone has foolishly included in the body of the email rat
Markus Wanner wrote:
> The "new branches getting merged up" could work. That is, applying the
> fix to the oldest back-branch which requires the fix first and then
> merge it to all newer ones, including HEAD. However, that would require
> some rethinking: instead of creating bugfix-patches for HEA
On Tue, 2009-06-02 at 23:53 +0900, Atsushi Ogawa wrote:
> I made a faster version of AllocSetFreeIndex for x86 architecture.
> Results of benchmark script:
> Xeon(Core architecture), RedHat EL4, gcc 3.4.6
> bytes : 4 8163264 128 256 512 1024 mix
> original: 0.780
"Kevin Grittner" writes:
> By the way, that's 32 bit Kubuntu 7.10.
> Linux kgrittn-desktop 2.6.22-16-generic #1 SMP Thu Apr 2 01:27:50 GMT
> 2009 i686 GNU/Linux
> I've done a new build with --enable-debug and confirmed the problem in
> that environment.
Hmm ... I'll rev up my old 32-bit-Intel
Tom Lane wrote:
Andrew Dunstan writes:
That's what we have a buildfarm for ;-) There's a failure on FBSD too
by the look of it. I'll dig some more to see what I can find.
I see this when building HEAD on Fedora 10:
plperl.c: In function 'plperl_init_interp':
plperl.c:450: warning:
Hi,
Le 4 juin 09 à 15:55, Alvaro Herrera a écrit :
I tend to hate automatic zeroing of pages because there's no way to
get
the contents later for forensics. I would support your proposal if we
had a way of saving the block elsewhere before zeroing it (say
create a
directory corrupted+zeroed
I wrote:
> Tatsuo Ishii wrote:
>
>> http://sylpheed.sraoss.jp/tmp/searcherdb84.tar.bz2
>
> Using that on my kubuntu machine with no configure options except
> prefix:
>
> [problem confirmed]
>
> Given that I can replicate this, is there some useful next step?
By the way, that's 32 bit
Andrew Dunstan writes:
> That's what we have a buildfarm for ;-) There's a failure on FBSD too
> by the look of it. I'll dig some more to see what I can find.
I see this when building HEAD on Fedora 10:
plperl.c: In function 'plperl_init_interp':
plperl.c:450: warning: null argument where non-
Tatsuo Ishii wrote:
> http://sylpheed.sraoss.jp/tmp/searcherdb84.tar.bz2
Using that on my kubuntu machine with no configure options except
prefix:
h...@kgrittn-desktop:~$ /usr/local/pgsql-8.4beta2/bin/psql -U hiro
sylph
psql (8.4beta2)
Type "help" for help.
sylph=# SELECT msg_sid, hdr_from
Tom Lane wrote:
aduns...@postgresql.org (Andrew Dunstan) writes:
Log Message:
---
Initialise perl library as documented in perl API. Backpatch to release 7.4.
Hmm, buildfarm says this doesn't work too well on Unixware :-(
That's what we have a b
Robert Haas wrote:
> On Thu, Jun 4, 2009 at 11:32 AM, Kevin Grittner
> wrote:
>> I was going to try to scare up some resources to advance this if we
>> could get to some consensus. I don't get the feeling we're there
>> yet. Suggestions welcome.
>
> I think I might've said this before, but I
Where can I find a more recent version of syncrep patch. The last one
that I've here is synch_rep_0428 and I'm getting segfault with it ":(.
In Wiki [1] the last is syncrep_0305
[1] http://wiki.postgresql.org/wiki/NTT%27s_Development_Projects
[]s
--
Dickson S. Guedes
mail/xmpp: gue...@guedeso
aduns...@postgresql.org (Andrew Dunstan) writes:
> Log Message:
> ---
> Initialise perl library as documented in perl API. Backpatch to release 7.4.
Hmm, buildfarm says this doesn't work too well on Unixware :-(
regards, tom lane
--
Sent via pgsql-hackers mailing
Magnus Hagander wrote:
Andrew Dunstan wrote:
Magnus Hagander wrote:
Dave Page wrote:
On Thu, Jun 4, 2009 at 12:40 AM, Andrew Dunstan
wrote:
Of course, that leaves the issue of the library name to be fixed, but
sufficient unto the day ...
Yea
On Thu, Jun 4, 2009 at 11:32 AM, Kevin Grittner
wrote:
> I was going to try to scare up some resources to advance this if we
> could get to some consensus. I don't get the feeling we're there yet.
> Suggestions welcome.
I think I might've said this before, but I think you need to do (or
get some
Hi,
in case of a serious failure of a backend or an auxiliary process the
postmaster performs a crash recovery and restarts the db automatically.
Is there a possibility to deactivate the restart and to force the postmaster to
simply exit at the end ?
The background is that we will have a watchd
Bruce Momjian wrote:
> Added to TODO:
>
> Consider improving serialized transaction behavior to avoid
> anomalies
>
> *
http://archives.postgresql.org/pgsql-hackers/2009-05/msg01136.php
> *
http://archives.postgresql.org/pgsql-hackers/2009-06/msg00035.php
It might be worth adding th
On Thu, 2009-06-04 at 10:02 -0400, Tom Lane wrote:
> Simon Riggs writes:
> > What seems strange about the various errors generated in bufpage.c is
> > that they are marked as ERRORs, yet are executed within a critical
> > section causing the system to PANIC.
>
> The reason we PANIC there is to r
Tom Lane wrote:
Andrew Dunstan writes:
I have cleaned up the patch from yesterday slightly, too. I'm wondering
how far back we should backpatch all this. This API was actually
documented in Perl (just) before 7.4 was released, so in theory the API
adjustment should go all the way back. H
Aidan Van Dyk writes:
> When the russian translators get to it, they make a russion .po which
> contains (something like) the following in the msgid "" header:
> "Plural-Forms: nplurals=3; plural=n%10==1 && n%100!=11 ? 0 : n%10>=2 &&
> n%10<=4 && (n%100<10 || n%100>=20) ? 1 : 2;\n"
Oh, I s
* Tom Lane [090604 10:22]:
> p...@thetdh.com writes:
> >> Russian plural forms for 100, 101, 102 etc. is different, as for 0, 1, 2.
>
> > True. The rule IIRC is that except for 11-14 and for collective numerals,
> > declination follows the last digit.
>
> Wow. So how does anyone represent that
Tom Lane wrote:
Gevik Babakhani writes:
I was wondering what the philosophy is behind letting an "ambiguous"
function be created in the first place. Is this for backwards
compatibility or perhaps for historical reasons?
Neither; it's a feature, and one we quite like. For example, would you
p...@thetdh.com writes:
>> Russian plural forms for 100, 101, 102 etc. is different, as for 0, 1, 2.
> True. The rule IIRC is that except for 11-14 and for collective numerals,
> declination follows the last digit.
Wow. So how does anyone represent that in the .po files? AFAICT the
notation th
Andrew Dunstan writes:
> I have cleaned up the patch from yesterday slightly, too. I'm wondering
> how far back we should backpatch all this. This API was actually
> documented in Perl (just) before 7.4 was released, so in theory the API
> adjustment should go all the way back. However, in prac
Simon Riggs writes:
> What seems strange about the various errors generated in bufpage.c is
> that they are marked as ERRORs, yet are executed within a critical
> section causing the system to PANIC.
The reason we PANIC there is to reduce the probability that bad data
will be written back to disk
On Thu, Jun 4, 2009 at 2:55 PM, Alvaro Herrera
wrote:
> I tend to hate automatic zeroing of pages because there's no way to get
> the contents later for forensics.
That's why we default to zero_damaged_pages=false. Saving the pages
somewhere seems like it would be a good feature to add for
zero_
Simon Riggs wrote:
> I would much prefer:
>
> * VACUUMs seeing these errors would perform as with zero_damaged_pages.
> * other backends seeing those errors should just ERROR out.
>
> We can do this by having a new function: boolean PageIsValid() which
> performs the sanity checks. This can th
Gevik Babakhani writes:
> I was wondering what the philosophy is behind letting an "ambiguous"
> function be created in the first place. Is this for backwards
> compatibility or perhaps for historical reasons?
Neither; it's a feature, and one we quite like. For example, would you
really prefer
Andrew Dunstan wrote:
>
>
> Magnus Hagander wrote:
>> Dave Page wrote:
>>
>>> On Thu, Jun 4, 2009 at 12:40 AM, Andrew Dunstan
>>> wrote:
>>>
Of course, that leaves the issue of the library name to be fixed, but
sufficient unto the day ...
>>> Yeah - I chatted briefly
+/*
+ * fls: find last set bit.
+ *
+ * Returns the 1-based index of the most-significant bit in x. The MSB
+ * is bit number 32, the LSB is bit number 1. If x is zero, the result is
+ * undefined.
+ */
+static inline int
+fls(unsigned int x)
...
+ idx = fls((size - 1) >> ALLOC_M
Magnus Hagander wrote:
Dave Page wrote:
On Thu, Jun 4, 2009 at 12:40 AM, Andrew Dunstan wrote:
Of course, that leaves the issue of the library name to be fixed, but
sufficient unto the day ...
Yeah - I chatted briefly with Magnus about that a while back. I added
a quick hack
2009/6/4 Gevik Babakhani :
> I was wondering what the philosophy is behind letting an "ambiguous"
> function be created in the first place. Is this for backwards compatibility
> or perhaps for historical reasons? Could someone clarify this please?
>
This is +/- for historical reasons. We used orig
> Russian plural forms for 100, 101, 102 etc. is different, as for 0, 1, 2.
True. The rule IIRC is that except for 11-14 and for collective numerals,
declination follows the last digit.
It would be possible to generalize declination via a language-specific
message-selector function, especially
Dave Page wrote:
> On Thu, Jun 4, 2009 at 12:40 AM, Andrew Dunstan wrote:
>> Of course, that leaves the issue of the library name to be fixed, but
>> sufficient unto the day ...
>
> Yeah - I chatted briefly with Magnus about that a while back. I added
> a quick hack to Mkvcbuild.pm to allow it to
Hi,
> -Original Message-
> From: ext Fujii Masao [mailto:masao.fu...@gmail.com]
> Sent: Thursday, June 04, 2009 6:25 AM
> To: Kolb, Harald (NSN - DE/Munich)
> Cc: pgsql-hackers@postgresql.org
> Subject: Re: [HACKERS] Synchronous replication: status of standby side
>
> Hi,
>
> On Thu, J
I've seen a couple of *topic issues lately.
What seems strange about the various errors generated in bufpage.c is
that they are marked as ERRORs, yet are executed within a critical
section causing the system to PANIC.
There are a number of sanity checks that are made prior to any changes
taking
On Thu, Jun 4, 2009 at 12:40 AM, Andrew Dunstan wrote:
>
> Well, that's not too easy to read, but anyway, I got to the bottom of it.
> Turns out there's a change in the Perl embedding API that nobody noticed.
> The attached patch worked for me on Windows. We'll need something like this
> on other
Hi,
Quoting "Marko Kreen" :
I'm not sure whether we should mark the old branches getting merges
down or the new branches getting merged up. I suspect I'm missing
something but I don't see any reason one is better than the other.
As pointed out by others, it doesn't make sense to merge (all
Hi,
Quoting "Tom Lane" :
BTW, Markus: you do realize "thomas" is not me but Tom Lockhart?
Uh.. thanks, that name has fallen through the cracks, before. I've
added it now, it will be included in the next sample conversion.
Regards
Markus Wanner
--
Sent via pgsql-hackers mailing list (pg
I was wondering what the philosophy is behind letting an "ambiguous"
function be created in the first place. Is this for backwards
compatibility or perhaps for historical reasons? Could someone clarify
this please?
Consider the following example:
(
FYI:
parse_func.c->ParseFuncOrColumn->164
p
Hi,
Quoting "Greg Stark" :
Hmm. I see. I'm not sure we've ever added files to back branches
either. I'm less sure of that though.
We did from time to time. Every merge commit in my current conversion
contains at least one such file that got added as part of a back
patch. The perl file men
On Tue, 2009-06-02 at 19:43 +0300, Heikki Linnakangas wrote:
> Simon Riggs wrote:
> > On Mon, 2009-06-01 at 14:47 +0900, Fujii Masao wrote:
> >
> >> pg_standby can use ln command to restore an archived file,
> >> which might destroy the archived file as follows.
> >>
> >> 1) pg_standby creates th
On Tue, 2009-06-02 at 14:54 -0400, Tom Lane wrote:
> Heikki Linnakangas writes:
> > Tom Lane wrote:
> >> That's a good point; don't we recover files under names like
> >> RECOVERYXLOG, not under names that could possibly conflict with regular
> >> WAL files?
>
> > Yes. But we rename RECOVERYXLOG
On Tue, 2009-06-02 at 14:33 -0400, Bruce Momjian wrote:
> Tom Lane wrote:
> > Simon Riggs writes:
> > > If we're going to require cascaded permissions like this, would it make
> > > sense to make GRANT cascade down the inheritance tree also?
> >
> > That's been discussed before. I forget wheth
On 4 Jun 2009, at 09:11, "Markus Wanner" wrote:
Hi,
Quoting "Greg Stark" :
This is all completely irrelevant to the CVS import.
To the CVS import it is, yes. After all, CVS has no notion of
renaming files. But my example is about renaming with git *after*
the conversion. Git *does* sup
Hi,
Quoting "Greg Stark" :
This is all completely irrelevant to the CVS import.
To the CVS import it is, yes. After all, CVS has no notion of renaming
files. But my example is about renaming with git *after* the
conversion. Git *does* support renaming (to some extent). However, it
fails
Hi,
On Thu, Jun 4, 2009 at 12:28 AM, Kolb, Harald (NSN - DE/Munich)
wrote:
> Hi,
>
> will there be a possibility to retrieve the standby situation in case of
> synchronous replication ?
> We would need a command or similar to report the current state and state
> changes
> (like: syncing, in-sync,
Hi,
Quoting "Alvaro Herrera" :
The only rant I have about the outcome is that Linus did not copy more
of it.
He he.. nice way of looking at it ;-)
Regards
Markus Wanner
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.p
60 matches
Mail list logo
