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
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 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
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:
On Mon, Dec 17, 2012 at 2:00 PM, Heikki Linnakangas
hlinnakan...@vmware.com 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
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 list
Hi!
On Mon, Dec 17, 2012 at 12:54 PM, Erik Rijkers e...@xs4all.nl 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:
On Sun, Oct 28, 2012 at 7:16 AM, Pavel Stehule pavel.steh...@gmail.com 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
On 17.12.2012 11:04, Pavan Deolasee wrote:
On Mon, Dec 17, 2012 at 2:00 PM, Heikki Linnakangas
hlinnakan...@vmware.com 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
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
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
On Sun, Dec 16, 2012 at 11:14 PM, Tom Lane t...@sss.pgh.pa.us 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
On 17 December 2012 12:07, Heikki Linnakangas hlinnakan...@vmware.comwrote:
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
On 12/15/12 11:23 AM, Tom Lane wrote:
=?iso-8859-15?q?C=E9dric_Villemain?= ced...@2ndquadrant.com 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
On Mon, Dec 17, 2012 at 7:16 PM, Peter Eisentraut pete...@gmx.net 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
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
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?= ced...@2ndquadrant.com 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
Jeff Davis pg...@j-davis.com 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?
Pavan Deolasee pavan.deola...@gmail.com writes:
On Mon, Dec 17, 2012 at 7:16 PM, Peter Eisentraut pete...@gmx.net 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:
Heikki Linnakangas hlinnakan...@vmware.com 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
Le lundi 17 décembre 2012 16:45:16, Tom Lane a écrit :
Pavan Deolasee pavan.deola...@gmail.com writes:
On Mon, Dec 17, 2012 at 7:16 PM, Peter Eisentraut pete...@gmx.net wrote:
If you
want to rebuild postgres, run make in src/backend, and analyze.o (or
whatever) will be rebuilt.
FWIW
=?iso-8859-15?q?C=E9dric_Villemain?= ced...@2ndquadrant.com 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
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?= ced...@2ndquadrant.com writes:
Le vendredi 14 décembre 2012 23:02:11, Tom Lane a écrit :
$ rm gram.o
On Mon, Dec 17, 2012 at 5:19 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Heikki Linnakangas hlinnakan...@vmware.com 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
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
Le lundi 17 décembre 2012 17:42:04, Tom Lane a écrit :
=?iso-8859-15?q?C=E9dric_Villemain?= ced...@2ndquadrant.com 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
On Mon, Dec 17, 2012 at 10:19 PM, Cédric Villemain
ced...@2ndquadrant.com 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
$
=?iso-8859-15?q?C=E9dric_Villemain?= ced...@2ndquadrant.com 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
(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
Heikki Linnakangas hlinnakan...@vmware.com writes:
On 17.12.2012 11:04, Pavan Deolasee wrote:
On Mon, Dec 17, 2012 at 2:00 PM, Heikki Linnakangas
hlinnakan...@vmware.com wrote:
I've still used XLByte* macros, but I agree that plain = are easier to
read. +1 for using = in new code.
Do we
On 2012-12-17 12:47:41 -0500, Tom Lane wrote:
Heikki Linnakangas hlinnakan...@vmware.com writes:
On 17.12.2012 11:04, Pavan Deolasee wrote:
On Mon, Dec 17, 2012 at 2:00 PM, Heikki Linnakangas
hlinnakan...@vmware.com wrote:
I've still used XLByte* macros, but I agree that plain = are
On Mon, Dec 17, 2012 at 11:17 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Heikki Linnakangas hlinnakan...@vmware.com writes:
On 17.12.2012 11:04, Pavan Deolasee wrote:
On Mon, Dec 17, 2012 at 2:00 PM, Heikki Linnakangas
hlinnakan...@vmware.com wrote:
I've still used XLByte* macros, but I agree
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?= ced...@2ndquadrant.com 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
On Mon, Dec 17, 2012 at 11:26 PM, Pavan Deolasee
pavan.deola...@gmail.com 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
Andres Freund and...@2ndquadrant.com 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
Peter Eisentraut pe...@eisentraut.org 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
On 2012-12-17 23:45:51 +0530, Pavan Deolasee wrote:
On Mon, Dec 17, 2012 at 11:26 PM, Pavan Deolasee
pavan.deola...@gmail.com 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
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 experimented a
Pavan Deolasee pavan.deola...@gmail.com 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
2012/12/17 Shigeru Hanada shigeru.han...@gmail.com:
On Sun, Oct 28, 2012 at 7:16 AM, Pavel Stehule pavel.steh...@gmail.com
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
On 14 December 2012 20:15, Greg Smith g...@2ndquadrant.com 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
Simon Riggs si...@2ndquadrant.com 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
On Sun, Dec 16, 2012 at 8:38 AM, Tomas Vondra t...@fuzzy.cz 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.
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(x):
On 17 December 2012 19:29, Tom Lane t...@sss.pgh.pa.us wrote:
Simon Riggs si...@2ndquadrant.com 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
2012/12/17 Peter Eisentraut pete...@gmx.net:
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
On 17 December 2012 17:39, Heikki Linnakangas hlinnakan...@vmware.com 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
On 17 December 2012 14:16, Heikki Linnakangas hlinnakan...@vmware.com 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
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
On Sun, Dec 16, 2012 at 01:20:53PM -0500, Tom Lane wrote:
Magnus Hagander mag...@hagander.net writes:
On Sat, Dec 15, 2012 at 2:24 PM, Erik Rijkers e...@xs4all.nl wrote:
That would make such a truncation less frequent, and after all a truncated
display is not
particular useful.
Hannu Krosing ha...@krosing.net 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
Simon Riggs si...@2ndquadrant.com writes:
On 17 December 2012 14:16, Heikki Linnakangas hlinnakan...@vmware.com 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
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 breaks
On Sat, Dec 15, 2012 at 11:52 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Kevin Grittner kgri...@mail.com 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,
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 breaks
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:
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
Christoph Berg christoph.b...@credativ.de 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
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.
Robert Haas robertmh...@gmail.com 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
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:
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 prose
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
18.12.2012, 05:22, Bruce Momjian br...@momjian.us:
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
[moved to hackers]
On Wednesday, December 5, 2012, Tom Lane wrote:
Jeff Janes jeff.ja...@gmail.com 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
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
On Mon, Dec 17, 2012 at 1:16 PM, Alexander Korotkov aekorot...@gmail.comwrote:
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
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
68 matches
Mail list logo
