On Tue, December 18, 2012 08:04, Alexander Korotkov wrote:
> trgm-regexp-0.9.patch.gz 22 k
Hi.
I ran the same test again: HEAD versus trgm_regex v6, 7 and 9. In v9 there is
some gain but also
some regression.
It remains a difficult problem...
If I get some time in the holidays I'll try to
On Mon, Dec 17, 2012 at 1:16 PM, Alexander Korotkov wrote:
> Didn't reproduce it yet. Can you retry it with this line uncommented:
> #define TRGM_REGEXP_DEBUG
> Then we can see which stage it fails.
>
Bug is found and fixed in attached patch.
--
With best regards,
Alexander Korotkov.
trgm-
On Mon, 2012-12-17 at 18:02 +0100, Christoph Berg wrote:
> I have no clue why no one else has seen this bug before, but the
> reason for the error seems to be that configure is invoking the
> setproctitle test including -ledit. libedit.so is linked to libbsd.so,
> which in turn contains setproctitl
[moved to hackers]
On Wednesday, December 5, 2012, Tom Lane wrote:
> Jeff Janes writes:
> > I now see where the cost is coming from. In commit 21a39de5809 (first
> > appearing in 9.2) the "fudge factor" cost estimate for large indexes
> > was increased by about 10 fold, which really hits this i
18.12.2012, 05:22, "Bruce Momjian" :
> This is the first pg_upgrade mismatch report we have gotten about 9.1.
> I have asked the reporter for details.
>
> Is what is the full 9.1 version number?
>
> ---
>> # rpm -qa |grep p
Since Thom already did the destruction test, I only chained 7 standbies,
just to see if I could reproduce his error.
In the process, I accidentally connected one standby to itself. This
failed, but the error message wasn't very helpful; it just gave me
"FATAL: could not connect, the database syste
On Fri, 2012-10-26 at 16:23 -0500, Karl O. Pinc wrote:
> On 10/26/2012 10:23:56 AM, Karl O. Pinc wrote:
> > On 10/26/2012 09:58:05 AM, Karl O. Pinc wrote:
> >
> > > The attached patch, raise_using_keyword_table.patch,
> > > puts the pl/pgsql RAISE USING keywords into a table,
> > > replacing a pro
cpluspluscheck is having issues with this change:
In file included from /tmp/cpluspluscheck.QEdLaR/test.cpp:3:0:
./src/include/postgres_fe.h:34:0: warning: "Assert" redefined [enabled by
default]
In file included from /tmp/cpluspluscheck.QEdLaR/test.cpp:2:0:
src/include/postgres.h:673:0: note: th
Robert Haas writes:
> I'm frankly kind of shocked at the revelation that the parser is
> already 14% of the backend. I knew it was big; I didn't realize it
> was THAT big.
Yeah, likewise. It makes me wonder whether we aren't past the size
of grammar that bison is a good choice for: considering
On 12/17/2012 09:44 PM, Tom Lane wrote:
I think we should assume that the libedit developers are utterly
clueless about not trampling on application namespace, and just cut
that library out of *all* our link checks except for the symbols we
specifically expect to get from libedit/libreadline.
Christoph Berg writes:
> We are regularly teaching PostgreSQL courses at linuxhotel.de.
> Starting from the course in November, PG doesn't compile anymore on
> their default Debian Squeeze install laptops they hand out to the
> participants. After ./configure && make, the error looks like this:
>
On Mon, 2012-12-17 at 19:14 +, Simon Riggs wrote:
> We'll need a way of expressing some form of corruption tolerance.
> zero_damaged_pages is just insane,
The main problem I see with zero_damaged_pages is that it could
potentially write out the zero page, thereby really losing your data if
it
This is the first pg_upgrade mismatch report we have gotten about 9.1.
I have asked the reporter for details.
Is what is the full 9.1 version number?
---
On Mon, Dec 17, 2012 at 03:33:40PM +0400, Groshev Andrey wrote:
> He
On Mon, Dec 17, 2012 at 12:14:29PM +0100, Bernhard Schrader wrote:
> Hello together,
>
> last thursday I upgraded one of our 9.0.6 postgresql servers to
> 9.2.2 with pg_upgrade. So far everything seemed to work but we now
> discover problems with the enum types. If we run one specific query
> it b
On Sat, Dec 15, 2012 at 11:52 AM, Tom Lane wrote:
> "Kevin Grittner" writes:
>> Tom Lane wrote:
>>> the parser tables are basically number-of-tokens wide by
>>> number-of-states high. (In HEAD there are 433 tokens known to the
>>> grammar, all but 30 of which are keywords, and 4367 states.)
>>>
>
On Mon, Dec 17, 2012 at 12:14:29PM +0100, Bernhard Schrader wrote:
> Hello together,
>
> last thursday I upgraded one of our 9.0.6 postgresql servers to
> 9.2.2 with pg_upgrade. So far everything seemed to work but we now
> discover problems with the enum types. If we run one specific query
> it b
Simon Riggs writes:
> On 17 December 2012 14:16, Heikki Linnakangas wrote:
>> I also wonder if pg_basebackup should
>> include *all* timeline history files in the backup, not just the latest one
>> strictly required to restore.
> Why? the timeline history file includes the previous timelines alr
Hannu Krosing writes:
> On 12/17/2012 10:34 PM, Peter Eisentraut wrote:
>> Yes, this would be a good solution for some applications, but the only
>> way I can think of to manage the compatibility issue is to invent some
>> function attribute system like
>>
>> CREATE FUNCTION ... OPTIONS (call_con
On Sun, Dec 16, 2012 at 01:20:53PM -0500, Tom Lane wrote:
> Magnus Hagander writes:
> > On Sat, Dec 15, 2012 at 2:24 PM, Erik Rijkers wrote:
> >> That would make such a truncation less frequent, and after all a truncated
> >> display is not
> >> particular useful.
>
> > Agreed - it's useful dur
On 12/17/2012 10:34 PM, Peter Eisentraut wrote:
On 12/16/12 1:20 PM, Hannu Krosing wrote:
I was going to suggest some special function name to be pulled out of code
passed to CREATE FUNCTION in line with
CREATE FUNCTION foo(a,b,c) AS $$
import x
from __future__ import nex_coo
On 17 December 2012 14:16, Heikki Linnakangas wrote:
> I'm not happy with the fact that we just ignore the problem in a backup
> taken from a standby, silently giving the user a backup that won't start up.
That's spooky. I just found a different issue with prmotion during
backup on your other th
On 17 December 2012 17:39, Heikki Linnakangas wrote:
> (This is different from the other issue related to timeline switches I just
> posted about. There's no timeline switch involved in this one.)
>
> If you do "pg_basebackup -x" against a standby server, in some circumstances
> the backup fails t
2012/12/17 Peter Eisentraut :
> On 12/16/12 1:20 PM, Hannu Krosing wrote:
>> I was going to suggest some special function name to be pulled out of code
>> passed to CREATE FUNCTION in line with
>>
>> CREATE FUNCTION foo(a,b,c) AS $$
>> import x
>> from __future__ import nex_cool_fea
On 17 December 2012 19:29, Tom Lane wrote:
> Simon Riggs writes:
>> Discussing this makes me realise that we need a more useful response
>> than just "your data is corrupt", so user can respond "yes, I know,
>> I'm trying to save whats left".
>
>> We'll need a way of expressing some form of corru
On 12/16/12 1:20 PM, Hannu Krosing wrote:
> I was going to suggest some special function name to be pulled out of code
> passed to CREATE FUNCTION in line with
>
> CREATE FUNCTION foo(a,b,c) AS $$
> import x
> from __future__ import nex_cool_feature
>
> def helper_function
On Sun, Dec 16, 2012 at 8:38 AM, Tomas Vondra wrote:
> On 8.12.2012 03:08, Jeff Janes wrote:
>>
>> It seems to me you need considerable expertise to figure out how to do
>> optimal recovery (i.e. losing the least transactions) in this
>> situation, and that that expertise cannot be automated. Do
Simon Riggs writes:
> Discussing this makes me realise that we need a more useful response
> than just "your data is corrupt", so user can respond "yes, I know,
> I'm trying to save whats left".
> We'll need a way of expressing some form of corruption tolerance.
> zero_damaged_pages is just insan
On 14 December 2012 20:15, Greg Smith wrote:
> On 12/14/12 3:00 PM, Jeff Davis wrote:
>>
>> After some thought, I don't see much value in introducing multiple
>> instances of corruption at a time. I would think that the smallest unit
>> of corruption would be the hardest to detect, so by introduci
2012/12/17 Shigeru Hanada :
> On Sun, Oct 28, 2012 at 7:16 AM, Pavel Stehule
> wrote:
>> Hello
>>
>> here is updated patch
>>
>> main change - it doesn't touch psql lexer - like Tom proposed
>> other points respect Phil's notices
>
> I reviewed v12 patch. It provides gset command which works
> c
Pavan Deolasee writes:
> BTW, now that XLogRecPtr is uint64, can't we change the pd_lsn field
> to use the same type ?
No, at least not without breaking on-disk compatibility on little-endian
machines.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hac
I wrote:
> Now perhaps this is not make's fault so much as a lack of adequate
> dependency specifications. It may be that we can still use .SECONDARY
> if we add the $(OBJS) lists as explicit targets of "make all" in backend
> directories, but I'm not sure how invasive that would be.
I experiment
On 2012-12-17 23:45:51 +0530, Pavan Deolasee wrote:
> On Mon, Dec 17, 2012 at 11:26 PM, Pavan Deolasee
> wrote:
>
> >>
> >
> > I probably did not mean increasing that to beyond 64-bit. OTOH I
> > wondered if we would ever want to steal a few bits from the LSN field,
> > given the numbers you just
Peter Eisentraut writes:
> I suppose that you are not using automatic dependency mode, so you are
> seeing the change just now with the recent introduction of global
> .SECONDARY.
True.
> This is working correctly, as far as make is concerned. There is no
> configuration knob in make that says,
Andres Freund writes:
> On 2012-12-17 12:47:41 -0500, Tom Lane wrote:
>> But, if the day ever comes when 64 bits doesn't seem like enough, I bet
>> we'd move to 128-bit integers, which will surely be available on all
>> platforms by then. So +1 for using plain comparisons --- in fact, I'd
>> vote
On Mon, Dec 17, 2012 at 11:26 PM, Pavan Deolasee
wrote:
>>
>
> I probably did not mean increasing that to beyond 64-bit. OTOH I
> wondered if we would ever want to steal a few bits from the LSN field,
> given the numbers you just put out. But it was more of a question than
> objection.
>
BTW, no
On 12/17/12 8:46 AM, Peter Eisentraut wrote:
> On 12/15/12 11:23 AM, Tom Lane wrote:
>> =?iso-8859-15?q?C=E9dric_Villemain?= writes:
>>> Le vendredi 14 décembre 2012 23:02:11, Tom Lane a écrit :
$ rm gram.o
rm: remove regular file `gram.o'? y
$ make
make: Nothing to be done for
On Mon, Dec 17, 2012 at 11:17 PM, Tom Lane wrote:
> Heikki Linnakangas writes:
>> On 17.12.2012 11:04, Pavan Deolasee wrote:
>>> On Mon, Dec 17, 2012 at 2:00 PM, Heikki Linnakangas
>>> wrote:
I've still used XLByte* macros, but I agree that plain <=> are easier to
read. +1 for using <
On 2012-12-17 12:47:41 -0500, Tom Lane wrote:
> Heikki Linnakangas writes:
> > On 17.12.2012 11:04, Pavan Deolasee wrote:
> >> On Mon, Dec 17, 2012 at 2:00 PM, Heikki Linnakangas
> >> wrote:
> >>> I've still used XLByte* macros, but I agree that plain <=> are easier to
> >>> read. +1 for using <
Heikki Linnakangas writes:
> On 17.12.2012 11:04, Pavan Deolasee wrote:
>> On Mon, Dec 17, 2012 at 2:00 PM, Heikki Linnakangas
>> wrote:
>>> I've still used XLByte* macros, but I agree that plain <=> are easier to
>>> read. +1 for using <=> in new code.
>> Do we ever see us changing this from 6
(This is different from the other issue related to timeline switches I
just posted about. There's no timeline switch involved in this one.)
If you do "pg_basebackup -x" against a standby server, in some
circumstances the backup fails to restore with error like this:
C 2012-12-17 19:09:44.042
=?iso-8859-15?q?C=E9dric_Villemain?= writes:
> Le lundi 17 décembre 2012 17:42:04, Tom Lane a écrit :
>> Well, it's behaving as documented, but what this means is we need to be
>> very wary of what contexts we can use .SECONDARY in. I'd just as soon
>> try to avoid using it at all --- my example
On Mon, Dec 17, 2012 at 10:19 PM, Cédric Villemain
wrote:
>
> That's not so obvious.
> The current behavior is expected by .SECONDARY.
> In other words, if I just 'touch rewriteDefine.c' then rewriteDefine.o will be
> rebuilt by make (as expected).
>
> $ touch rewriteDefine.c
> $ make
> gcc -O2 -
Le lundi 17 décembre 2012 17:42:04, Tom Lane a écrit :
> =?iso-8859-15?q?C=E9dric_Villemain?= writes:
> > Le lundi 17 décembre 2012 16:45:16, Tom Lane a écrit :
> >> Having seen this, I now think .SECONDARY is broken across the board.
> >
> > make does what it is supposed to do here IIUC.
>
> We
We are regularly teaching PostgreSQL courses at linuxhotel.de.
Starting from the course in November, PG doesn't compile anymore on
their default Debian Squeeze install laptops they hand out to the
participants. After ./configure && make, the error looks like this:
postmaster/postmaster.o: In funct
On Mon, Dec 17, 2012 at 5:19 PM, Tom Lane wrote:
> Heikki Linnakangas writes:
>> I'm not happy with the fact that we just ignore the problem in a backup
>> taken from a standby, silently giving the user a backup that won't start
>> up. Why not include the timeline history file in the backup?
>
>
Le lundi 17 décembre 2012 15:29:09, Andrew Dunstan a écrit :
> On 12/17/2012 08:46 AM, Peter Eisentraut wrote:
> > On 12/15/12 11:23 AM, Tom Lane wrote:
> >> =?iso-8859-15?q?C=E9dric_Villemain?= writes:
> >>> Le vendredi 14 décembre 2012 23:02:11, Tom Lane a écrit :
> $ rm gram.o
> rm: r
=?iso-8859-15?q?C=E9dric_Villemain?= writes:
> Le lundi 17 décembre 2012 16:45:16, Tom Lane a écrit :
>> Having seen this, I now think .SECONDARY is broken across the board.
> make does what it is supposed to do here IIUC.
Well, it's behaving as documented, but what this means is we need to be
v
Le lundi 17 décembre 2012 16:45:16, Tom Lane a écrit :
> Pavan Deolasee writes:
> > On Mon, Dec 17, 2012 at 7:16 PM, Peter Eisentraut wrote:
> >> If you
> >> want to rebuild postgres, run make in src/backend, and analyze.o (or
> >> whatever) will be rebuilt.
> >
> > FWIW for me, make in src/back
Heikki Linnakangas writes:
> I'm not happy with the fact that we just ignore the problem in a backup
> taken from a standby, silently giving the user a backup that won't start
> up. Why not include the timeline history file in the backup?
+1. I was not aware that we weren't doing that --- it s
Pavan Deolasee writes:
> On Mon, Dec 17, 2012 at 7:16 PM, Peter Eisentraut wrote:
>> If you
>> want to rebuild postgres, run make in src/backend, and analyze.o (or
>> whatever) will be rebuilt.
> FWIW for me, make in src/backend fails with this:
> i686-apple-darwin11-llvm-gcc-4.2: parser/analyze
Jeff Davis writes:
>> -A relation name
>> -Corruption type (an entry from this list)
>> -How many blocks to touch
>>
>> I'll just loop based on the count, randomly selecting a block each time
>> and messing with it in that way.
For the messing with it part, did you consider zzuf?
http://caca
On 12/17/2012 08:46 AM, Peter Eisentraut wrote:
On 12/15/12 11:23 AM, Tom Lane wrote:
=?iso-8859-15?q?C=E9dric_Villemain?= writes:
Le vendredi 14 décembre 2012 23:02:11, Tom Lane a écrit :
$ rm gram.o
rm: remove regular file `gram.o'? y
$ make
make: Nothing to be done for `all'.
WTF?
A pre
pg_basebackup -x is supposed to include all the required WAL files in
the backup, so that you have everything needed to restore a consistent
database. However, it's not including the timeline history files.
Usually that's not a problem because normally you don't need to follow
any old timelines
On Mon, Dec 17, 2012 at 7:16 PM, Peter Eisentraut wrote:
> If you
> want to rebuild postgres, run make in src/backend, and analyze.o (or
> whatever) will be rebuilt.
FWIW for me, make in src/backend fails with this:
i686-apple-darwin11-llvm-gcc-4.2: parser/analyze.o: No such file or directory
ma
On 12/15/12 11:23 AM, Tom Lane wrote:
> =?iso-8859-15?q?C=E9dric_Villemain?= writes:
>> Le vendredi 14 décembre 2012 23:02:11, Tom Lane a écrit :
>>> $ rm gram.o
>>> rm: remove regular file `gram.o'? y
>>> $ make
>>> make: Nothing to be done for `all'.
>>>
>>> WTF?
>
>> A previous patch changed t
On 17 December 2012 12:07, Heikki Linnakangas wrote:
> On 15.12.2012 01:09, Josh Berkus wrote:
>
>> Tested this on yesterday's snapshot. Worked great.
>>
>
> Thanks for the testing!
>
>
> Now I wanna test a chain of cascading replicas ... how far can we chain
>> these?
>>
>
> There's no limit in
On Sun, Dec 16, 2012 at 11:14 PM, Tom Lane wrote:
> And I agree with him that your proposed
> redefinition of the bit's meaning to avoid that is pretty horrid;
> it's ugly, complicates the invariant quite a lot, and breaks some
> existing usages of the bit.
(slammed.. feels the pain) You defini
On 15.12.2012 01:09, Josh Berkus wrote:
Tested this on yesterday's snapshot. Worked great.
Thanks for the testing!
Now I wanna test a chain of cascading replicas ... how far can we chain
these?
There's no limit in theory. I tested with one master and two chained
standbys myself. Give it a
On Fri, 2012-12-14 at 01:31 +0400, Alexander Korotkov wrote:
> Hi!
>
Hi!
I have attached a patch with some significant edits.
* In your patch, there was still an inconsistency between the comment
for bounds_adjacent and the code. I refactored it to ensure it always
takes the upper bound as bound
On 17.12.2012 11:04, Pavan Deolasee wrote:
On Mon, Dec 17, 2012 at 2:00 PM, Heikki Linnakangas
wrote:
On 16.12.2012 16:16, Andres Freund wrote:
Now that XLRecPtr's are plain 64bit integers what are we supposed to use
in code comparing and manipulating them? There already is plenty example
of
On Sun, Oct 28, 2012 at 7:16 AM, Pavel Stehule wrote:
> Hello
>
> here is updated patch
>
> main change - it doesn't touch psql lexer - like Tom proposed
> other points respect Phil's notices
I reviewed v12 patch. It provides gset command which works
consistently with other psql commands, such a
Hi!
On Mon, Dec 17, 2012 at 12:54 PM, Erik Rijkers wrote:
> On Sun, December 16, 2012 22:25, Alexander Korotkov wrote:
>
> > trgm-regexp-0.8.patch.gz 22 k
>
> Hi Alexander,
>
> I gave this a quick try; the patch works when compiled for DEBUG, but
> crashes as a
> 'speed'-compiled binary:
>
> C
On Mon, December 17, 2012 09:54, Pavel Stehule wrote:
> Helllo
>
> I try to search simple solution and I didn't find anything. It is possible?
>
Perhaps not strictly 1 commandline but I often use this:
echo '\timing on \\ select 1+2' | psql
Erik Rijkers
--
Sent via pgsql-hackers mailing li
On Mon, Dec 17, 2012 at 2:00 PM, Heikki Linnakangas
wrote:
> On 16.12.2012 16:16, Andres Freund wrote:
>>
>> Now that XLRecPtr's are plain 64bit integers what are we supposed to use
>> in code comparing and manipulating them? There already is plenty example
>> of both, but I would like new code to
postgres=# \timing
Timing is on.
postgres=# SELECT now();
now
2012-12-17 15:56:39.655+07
(1 row)
Time: 11.429 ms
postgres=#
--
View this message in context:
http://postgresql.1045698.n5.nabble.com/is-possible-enforce-timing-on-from-command-line-tp
On Sun, December 16, 2012 22:25, Alexander Korotkov wrote:
> trgm-regexp-0.8.patch.gz 22 k
Hi Alexander,
I gave this a quick try; the patch works when compiled for DEBUG, but crashes
as a
'speed'-compiled binary:
Compile for speed:
$ pg_config --configure
'--prefix=/home/aardvark/pg_stuff/p
Helllo
I try to search simple solution and I didn't find anything. It is possible?
Regards
Pavel Stehule
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On 16.12.2012 16:16, Andres Freund wrote:
Now that XLRecPtr's are plain 64bit integers what are we supposed to use
in code comparing and manipulating them? There already is plenty example
of both, but I would like new code to go into one direction not two...
I personally find direct comparisons/
68 matches
Mail list logo
