On 18 December 2012 02:21, Jeff Davis pg...@j-davis.com 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
On 12/18/2012 02:41 AM, Bruce Momjian wrote:
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
On Tue, Dec 18, 2012 at 11:45 AM, Erik Rijkers e...@xs4all.nl wrote:
On Tue, December 18, 2012 08:04, Alexander Korotkov wrote:
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
On Tue, December 18, 2012 09:45, Alexander Korotkov wrote:
You should use {0,n} to express from 0 to n occurences.
Thanks, but I know that of course. It's a testing program; and in the end
robustness with
unexpected or even wrong input is as important as performance. (to put it
bluntly, I
On 12/18/12 3:17 AM, Simon Riggs wrote:
Clearly part of the response could involve pg_dump on the damaged
structure, at some point.
This is the main thing I wanted to try out more, once I have a decent
corruption generation tool. If you've corrupted a single record but can
still pg_dump the
On Tue, Dec 18, 2012 at 12:51 PM, Erik Rijkers e...@xs4all.nl wrote:
On Tue, December 18, 2012 09:45, Alexander Korotkov wrote:
You should use {0,n} to express from 0 to n occurences.
Thanks, but I know that of course. It's a testing program; and in the end
robustness with
unexpected
On 18.12.2012 00:35, Simon Riggs wrote:
On 17 December 2012 17:39, Heikki Linnakangashlinnakan...@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
On 18 December 2012 09:18, Heikki Linnakangas hlinnakan...@vmware.com wrote:
That seems correct to me. The backup is considered valid after reaching
0/1764F48, which is where the checkpoint record ends. minRecoveryPoint is
set to the same. What do you think it should be set to?
I already
Robert Haas robertmh...@gmail.com writes:
And on the other hand, if you could get a clean split between the two
grammars, then regardless of exactly what the split was, it might seem
a win. But it seemed to me when I looked at this that you'd have to
duplicate a lot of stuff and the small
On 18.12.2012 11:30, Simon Riggs wrote:
On 18 December 2012 09:18, Heikki Linnakangashlinnakan...@vmware.com wrote:
That seems correct to me. The backup is considered valid after reaching
0/1764F48, which is where the checkpoint record ends. minRecoveryPoint is
set to the same. What do you
On 18 December 2012 00:53, Tom Lane t...@sss.pgh.pa.us wrote:
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
On Sunday, December 16, 2012 11:14 PM Tom Lane wrote:
Pavan Deolasee pavan.deola...@gmail.com writes:
On Sun, Dec 16, 2012 at 3:10 PM, Simon Riggs si...@2ndquadrant.com
wrote:
As explained above, I disagree that it looks like a good idea, and
you've shown no evidence it would be or is
Hello
this patch was proposed
http://archives.postgresql.org/pgsql-hackers/2012-08/msg00817.php and
there was no objections
* there are no issue with patching
* no warnings
* code is clean and respect our source code policy
* tested without errors
My last objections was satisfied - last
Andres Freund and...@2ndquadrant.com writes:
In 2) unfortunately one has to make decision in which way to simplify
negated XLByte(LT|LE) expressions. I tried to make that choice very
careful and when over every change several times after that, so I hope
there aren't any bad changes, but more
On 2012-12-18 13:14:10 +0100, Dimitri Fontaine wrote:
Andres Freund and...@2ndquadrant.com writes:
In 2) unfortunately one has to make decision in which way to simplify
negated XLByte(LT|LE) expressions. I tried to make that choice very
careful and when over every change several times after
Basic stuff:
- Rebase of Patch is required.
- Compiles cleanly without any errors/warnings
- Regression tests pass.
What it does:
-
This patch is useful when COPY command input/output are stored in
compression format or in
Re: Tom Lane 2012-12-18 26465.1355798...@sss.pgh.pa.us
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
Greg Smith wrote:
In general, what I hope people will be able to do is switch over to
their standby server, and then investigate further. I think it's
unlikely that people willing to pay for block checksums will only have
one server. Having some way to nail down if the same block is bad on
Peter Eisentraut pete...@gmx.net writes:
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
There is no good way to make the poor soul who has no standby server
happy here. You're just choosing between bad alternatives. The first
block error is often just that--the first one, to be joined by others
soon afterward. My experience at how drives fail says the second error
is a lot more
On 12/18/2012 02:41 AM, Bruce Momjian wrote:
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
On 12/18/2012 03:45 AM, Bernhard Schrader wrote:
On 12/18/2012 02:41 AM, Bruce Momjian wrote:
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
On Tue, Dec 18, 2012 at 10:52:46AM -0500, Andrew Dunstan wrote:
The translations from oid to label are in pg_enum, but it looks like
somehow you have lost that mapping. I'm not sure what you've done
but AFAICT pg_upgrade is doing the right thing.
I just did this (from 9.0 to 9.2) and the
On Tue, Dec 18, 2012 at 09:28:00AM +0400, Groshev Andrey wrote:
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?
Hello.
I've tried to implement this API for our Multicorn FDW, and I have a few
questions about the API.
First, I don't understand what are the requirements on the rowid
pseudo-column values.
In particular, this sentence from a previous mail makes it ambiguous to me:
At the beginning, I
On Mon, Dec 17, 2012 at 09:21:59PM -0500, Bruce Momjian wrote:
Mismatch of relation names: database database, old rel
public.lob.ВерсияВнешнегоДокумента$Документ_pkey, new rel
public.plob.ВерсияВнешнегоДокумент
а$Документ
Failure, exiting
I am now confused over the error message
There are some system administration functions that have hardcoded
superuser checks, specifically:
pg_reload_conf
pg_rotate_logfile
pg_read_file
pg_read_file_all
pg_read_binary_file
pg_read_binary_file_all
pg_stat_file
pg_ls_dir
Some of these are useful in monitoring or maintenance tools, and
On 18 December 2012 17:09, Peter Eisentraut pete...@gmx.net wrote:
There are some system administration functions that have hardcoded
superuser checks, specifically:
pg_reload_conf
pg_rotate_logfile
pg_read_file
pg_read_file_all
pg_read_binary_file
pg_read_binary_file_all
pg_stat_file
later in the log pg_dump, I found the definition of new rel
--
-- Name: plob.ВерсияВнешнегоДокумента$Документ; Type: CONSTRAINT; Schema:
public; Owner: postgres; Tablespace:
--
ALTER TABLE ONLY lob.ВерсияВнешнегоДокумента$Документ
ADD CONSTRAINT plob.ВерсияВнешнегоДокумента$Документ PRIMARY
2012/12/18 Peter Eisentraut pete...@gmx.net:
There are some system administration functions that have hardcoded
superuser checks, specifically:
pg_reload_conf
pg_rotate_logfile
Some of these are useful in monitoring or maintenance tools, and the
hardcoded superuser checks require that
On Tue, Dec 18, 2012 at 8:09 PM, Simon Riggs si...@2ndquadrant.com wrote:
On 18 December 2012 00:53, Tom Lane t...@sss.pgh.pa.us wrote:
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
On 12/18/2012 05:22 PM, Bruce Momjian wrote:
On Tue, Dec 18, 2012 at 10:52:46AM -0500, Andrew Dunstan wrote:
The translations from oid to label are in pg_enum, but it looks like
somehow you have lost that mapping. I'm not sure what you've done
but AFAICT pg_upgrade is doing the right thing.
I
On Tue, Dec 18, 2012 at 2:39 AM, 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
Fujii Masao masao.fu...@gmail.com writes:
On Tue, Dec 18, 2012 at 8:09 PM, Simon Riggs si...@2ndquadrant.com wrote:
What I'm saying is that the new history file is created from the old
one, so the latest file includes all the history as a direct copy. The
only thing new is one line of
Bernhard Schrader bernhard.schra...@innogames.de writes:
Beside of that, we tested a little bit more with the failing query:
The statement which is causing the error is a big UPDATE-statement with
FROM. After some testing we figured out that the subselect in the
FROM-clause is working fine.
On 12/18/2012 01:24 PM, Tom Lane wrote:
Bernhard Schrader bernhard.schra...@innogames.de writes:
Beside of that, we tested a little bit more with the failing query:
The statement which is causing the error is a big UPDATE-statement with
FROM. After some testing we figured out that the
On 2012-12-18 13:24:12 -0500, Tom Lane wrote:
Bernhard Schrader bernhard.schra...@innogames.de writes:
Beside of that, we tested a little bit more with the failing query:
The statement which is causing the error is a big UPDATE-statement with
FROM. After some testing we figured out that the
Andres Freund and...@2ndquadrant.com writes:
On 2012-12-18 13:24:12 -0500, Tom Lane wrote:
Does the table being updated have any indexes on enum columns? I'm
suspicious that the bogus OID is in an index page somewhere, and not
in the table at all.
I already wondered whether it could be a
On 12/18/2012 02:34 PM, Tom Lane wrote:
Andres Freund and...@2ndquadrant.com writes:
On 2012-12-18 13:24:12 -0500, Tom Lane wrote:
Does the table being updated have any indexes on enum columns? I'm
suspicious that the bogus OID is in an index page somewhere, and not
in the table at all.
I
Andrew Dunstan and...@dunslane.net writes:
He's upgrading from 9.0, which didn't have enum extension at all, and
where odd enums didn't mean anything special.
Really? The noncontiguous pg_enum OIDs shown in
http://archives.postgresql.org/pgsql-hackers/2012-12/msg01089.php
suggest strongly
On 12/18/2012 02:58 PM, Tom Lane wrote:
Andrew Dunstan and...@dunslane.net writes:
He's upgrading from 9.0, which didn't have enum extension at all, and
where odd enums didn't mean anything special.
Really? The noncontiguous pg_enum OIDs shown in
On Fri, Dec 14, 2012 at 7:19 PM, Andres Freund and...@2ndquadrant.com wrote:
On 2012-12-14 14:01:30 -0500, Robert Haas wrote:
On Fri, Dec 14, 2012 at 6:46 AM, Andres Freund and...@2ndquadrant.com
wrote:
Just moving that tidbit inside the lock seems to be the pragmatic
choice. GetOldestXmin
Andrew Dunstan and...@dunslane.net writes:
People have been known to hack pg_enum on their own, especially before
we added enum extension.
Of course, if they do that they get to keep both pieces.
Yeah ... this would be very readily explainable if there had been a
manual deletion from pg_enum
On Tue, 2012-12-18 at 08:17 +, Simon Riggs wrote:
I think we should discuss whether we accept my premise? Checksums will
actually detect more errors than we see now, and people will want to
do something about that. Returning to backup is one way of handling
it, but on a busy production
On Tue, 2012-12-18 at 04:06 -0500, Greg Smith wrote:
Having some way to nail down if the same block is bad on a
given standby seems like a useful interface we should offer, and it
shouldn't take too much work. Ideally you won't find the same
corruption there. I'd like a way to check the
On Tue, Dec 18, 2012 at 09:34:53PM +0400, Groshev Andrey wrote:
later in the log pg_dump, I found the definition of new rel
--
-- Name: plob.ВерсияВнешнегоДокумента$Документ; Type: CONSTRAINT; Schema:
public; Owner: postgres; Tablespace:
--
ALTER TABLE ONLY
On 12/18/2012 09:38 PM, Tom Lane wrote:
Andrew Dunstan and...@dunslane.net writes:
People have been known to hack pg_enum on their own, especially before
we added enum extension.
Of course, if they do that they get to keep both pieces.
Yeah ... this would be very readily explainable if there
Hi,
2012/12/18 Ronan Dunklau rdunk...@gmail.com:
Hello.
I've tried to implement this API for our Multicorn FDW, and I have a few
questions about the API.
First, I don't understand what are the requirements on the rowid
pseudo-column values.
In particular, this sentence from a previous
On Tue, Dec 18, 2012 at 4:33 AM, Dimitri Fontaine
dimi...@2ndquadrant.fr wrote:
Robert Haas robertmh...@gmail.com writes:
And on the other hand, if you could get a clean split between the two
grammars, then regardless of exactly what the split was, it might seem
a win. But it seemed to me
On 12/18/12 5:10 PM, Robert Haas wrote:
I can't help but suspect that the way we handle keywords today is
monumentally inefficient. The unreserved_keyword products, et al,
just seem somehow badly wrong-headed. We take the trouble to
distinguish all of those cases so that we an turn around
Hi,
Robert Haas robertmh...@gmail.com schrieb:
On Fri, Dec 14, 2012 at 7:19 PM, Andres Freund and...@2ndquadrant.com
wrote:
On 2012-12-14 14:01:30 -0500, Robert Haas wrote:
On Fri, Dec 14, 2012 at 6:46 AM, Andres Freund
and...@2ndquadrant.com wrote:
Just moving that tidbit inside the lock
On Tue, Dec 18, 2012 at 5:24 PM, Peter Eisentraut pete...@gmx.net wrote:
On 12/18/12 5:10 PM, Robert Haas wrote:
I can't help but suspect that the way we handle keywords today is
monumentally inefficient. The unreserved_keyword products, et al,
just seem somehow badly wrong-headed. We take
On Tue, Dec 18, 2012 at 12:09:10PM -0500, Peter Eisentraut wrote:
There are some system administration functions that have hardcoded
superuser checks, specifically:
pg_reload_conf
pg_rotate_logfile
pg_read_file
pg_read_file_all
pg_read_binary_file
pg_read_binary_file_all
pg_stat_file
On Tue, Dec 18, 2012 at 5:25 PM, anara...@anarazel.de
and...@anarazel.de wrote:
The problem is that at the time GetSnapshotData returns the xmin horizon
might have gone upwards and tuples required for decoding might get removed by
other backends. That needs to be prevented while holding the
On Tue, Dec 18, 2012 at 7:41 PM, Noah Misch n...@leadboat.com wrote:
On Tue, Dec 18, 2012 at 12:09:10PM -0500, Peter Eisentraut wrote:
There are some system administration functions that have hardcoded
superuser checks, specifically:
pg_reload_conf
pg_rotate_logfile
pg_read_file
On 18.12.2012 18:38, Pavel Stehule wrote:
2012/12/18 Peter Eisentraut pete...@gmx.net:
There are some system administration functions that have hardcoded
superuser checks, specifically:
pg_reload_conf
pg_rotate_logfile
Some of these are useful in monitoring or maintenance tools, and the
On 2012-12-18 19:56:18 -0500, Robert Haas wrote:
On Tue, Dec 18, 2012 at 5:25 PM, anara...@anarazel.de
and...@anarazel.de wrote:
The problem is that at the time GetSnapshotData returns the xmin horizon
might have gone upwards and tuples required for decoding might get removed
by other
[moved to hackers]
On Wednesday, December 5, 2012, Tom Lane wrote:
Jeff Janes jeff.ja...@gmail.com javascript:; 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,
On 2012-12-17 00:31:00 +0100, Tomas Vondra wrote:
I've updated the patch to include the optimization described in the
previous post, i.e. if the number of relations is below a certain
threshold, use a simple for loop, for large numbers of relations use
bsearch calls.
This is done by a new
On Sun, Dec 2, 2012 at 4:37 AM, Alastair Turner b...@ctrlf5.co.za wrote:
Patch for the changes discussed in
http://archives.postgresql.org/pgsql-hackers/2010-10/msg00919.php
attached (eventually ...)
In summary: If the input file (-f) doesn't exist or the ouput or log
files (-o and -l) can't
On Mon, Dec 17, 2012 at 1:34 PM, Tom Lane t...@sss.pgh.pa.us wrote:
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
On Tue, Dec 18, 2012 at 7:59 PM, Andres Freund and...@2ndquadrant.com wrote:
On 2012-12-18 19:56:18 -0500, Robert Haas wrote:
On Tue, Dec 18, 2012 at 5:25 PM, anara...@anarazel.de
and...@anarazel.de wrote:
The problem is that at the time GetSnapshotData returns the xmin horizon
might have
On 2012-12-17 11:44:00 +0900, Michael Paquier wrote:
Thanks for all your comments.
The new version (v5) of this patch fixes the error you found when
reindexing indexes being referenced in foreign keys.
The fix is done with switchIndexConstraintOnForeignKey:pg_constraint.c, in
charge of
Heikki,
I ran into an unexpected issue while testing. I just wanted to fire up
a chain of 5 replicas to see if I could connect them in a loop.
However, I ran into a weird issue when starting up r3: it refused to
come out of the database is starting up mode until I did a write on
the master.
Folks,
So as a test I tried to connect a group of 9.3 streaming replicas in a
circle (4 replicas). This was very easy to do:
1. create r1 as replica of master
2. create r2 as replica of r1
3. create r3 as replica of r2
4. create r4 as replica of r3
5. start traffic on master
6. shut down r1
7.
Hackers,
Currently we can see each master's current replicas using
pg_stat_replication. However, there is no way from a replica, that I
know of, to figure out who its master is other than to look at
recovery.conf.
We should probably have a function, like pg_replication_master(), which
gives the
Robert Haas robertmh...@gmail.com writes:
On Mon, Dec 17, 2012 at 1:34 PM, Tom Lane t...@sss.pgh.pa.us wrote:
This is definitely not per make's contract, either. I think maybe the
Don't rebuild the list if only the OBJS have changed hack in common.mk
is a brick or two shy of a load, but I
On Mon, Dec 17, 2012 at 5:37 AM, Tomas Vondra t...@fuzzy.cz wrote:
Hi,
attached is a new version of the patch that
(a) converts the 'log_step_seconds' variable to a constant (and does
not allow changing it using a command-line option etc.)
(b) keeps the current logging as a default
On Dec 19, 2012 4:43 AM, Josh Berkus j...@agliodbs.com wrote:
Hackers,
Currently we can see each master's current replicas using
pg_stat_replication. However, there is no way from a replica, that I
know of, to figure out who its master is other than to look at
recovery.conf.
We should
On Wed, Dec 19, 2012 at 1:58 AM, Tomas Vondra t...@fuzzy.cz wrote:
On 18.12.2012 18:38, Pavel Stehule wrote:
2012/12/18 Peter Eisentraut pete...@gmx.net:
There are some system administration functions that have hardcoded
superuser checks, specifically:
pg_reload_conf
pg_rotate_logfile
On Tue, Dec 18, 2012 at 2:52 AM, Pavel Stehule pavel.steh...@gmail.com wrote:
Attached updated patch
Seems fine. I'll mark this as ready for committer.
Nice work!
--
Shigeru HANADA
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
On 19 December 2012 03:03, Josh Berkus j...@agliodbs.com wrote:
So, my question is:
1. should we detect for replication cycles? *Can* we?
2. should we warn the user, or refuse to start up?
Why not just monitor the config you just created? Anybody that
actually tests their config would spot
72 matches
Mail list logo
