On 19 December 2012 03:03, Josh Berkus 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 this.
--
Si
On Tue, Dec 18, 2012 at 2:52 AM, Pavel Stehule 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:
http://www.postgresql
On Wed, Dec 19, 2012 at 1:58 AM, Tomas Vondra wrote:
> On 18.12.2012 18:38, Pavel Stehule wrote:
>> 2012/12/18 Peter Eisentraut :
>>> There are some system administration functions that have hardcoded
>>> superuser checks, specifically:
>>>
>>> pg_reload_conf
>>> pg_rotate_logfile
>>>
>>> Some of
On Dec 19, 2012 4:43 AM, "Josh Berkus" 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 probably
On Mon, Dec 17, 2012 at 5:37 AM, Tomas Vondra 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
>
> (c)
Robert Haas writes:
> On Mon, Dec 17, 2012 at 1:34 PM, Tom Lane 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 don't know how to fix that.
> I f
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
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. p
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.
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 sc
On Tue, Dec 18, 2012 at 7:59 PM, Andres Freund wrote:
> On 2012-12-18 19:56:18 -0500, Robert Haas wrote:
>> On Tue, Dec 18, 2012 at 5:25 PM, anara...@anarazel.de
>> wrote:
>> > The problem is that at the time GetSnapshotData returns the xmin horizon
>> > might have gone upwards and tuples requir
On Mon, Dec 17, 2012 at 1:34 PM, Tom Lane 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
>> directories, bu
On Sun, Dec 2, 2012 at 4:37 AM, Alastair Turner 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 be created
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 n
[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
On 2012-12-18 19:56:18 -0500, Robert Haas wrote:
> On Tue, Dec 18, 2012 at 5:25 PM, anara...@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. Tha
On 18.12.2012 18:38, Pavel Stehule wrote:
> 2012/12/18 Peter Eisentraut :
>> 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 Tue, Dec 18, 2012 at 7:41 PM, Noah Misch 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
>> pg_read_file_
On Tue, Dec 18, 2012 at 5:25 PM, anara...@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 procarray lock
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_sta
On Tue, Dec 18, 2012 at 5:24 PM, Peter Eisentraut 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 the troubl
Hi,
Robert Haas schrieb:
>On Fri, Dec 14, 2012 at 7:19 PM, Andres Freund
>wrote:
>> On 2012-12-14 14:01:30 -0500, Robert Haas wrote:
>>> On Fri, Dec 14, 2012 at 6:46 AM, Andres Freund
> wrote:
>>> > Just moving that tidbit inside the lock seems to be the pragmatic
>>> > choice. GetOldestXmin is
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
On Tue, Dec 18, 2012 at 4:33 AM, Dimitri Fontaine
wrote:
> Robert Haas 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
Hi,
2012/12/18 Ronan Dunklau :
> 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
On 12/18/2012 09:38 PM, Tom Lane wrote:
Andrew Dunstan 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 del
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 "lob.ВерсияВнешнегоД
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 th
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
Andrew Dunstan 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 somewhere along t
On Fri, Dec 14, 2012 at 7:19 PM, Andres Freund wrote:
> On 2012-12-14 14:01:30 -0500, Robert Haas wrote:
>> On Fri, Dec 14, 2012 at 6:46 AM, Andres Freund
>> wrote:
>> > Just moving that tidbit inside the lock seems to be the pragmatic
>> > choice. GetOldestXmin is called
>> >
>> > * once per ch
On 12/18/2012 02:58 PM, Tom Lane wrote:
Andrew Dunstan 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
Andrew Dunstan 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 that *something's* be
On 12/18/2012 02:34 PM, Tom Lane wrote:
Andres Freund 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
Andres Freund 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 problem caused by
On 2012-12-18 13:24:12 -0500, Tom Lane wrote:
> Bernhard Schrader 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
> > FR
On 12/18/2012 01:24 PM, Tom Lane wrote:
Bernhard Schrader 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
Bernhard Schrader 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. And if we simplify the UPDA
Fujii Masao writes:
> On Tue, Dec 18, 2012 at 8:09 PM, Simon Riggs 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 information.
> The timeline history file in
On Tue, Dec 18, 2012 at 2:39 AM, 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 f
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 j
On Tue, Dec 18, 2012 at 8:09 PM, Simon Riggs wrote:
> On 18 December 2012 00:53, Tom Lane wrote:
>> 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
2012/12/18 Peter Eisentraut :
> 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 these tools
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.ВерсияВнешнегоДокумента$Документ" PR
On 18 December 2012 17:09, 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
> pg_ls_
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 the
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 me
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 con
On Tue, Dec 18, 2012 at 09:28:00AM +0400, Groshev Andrey wrote:
>
>
> 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?
> >
> >
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 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 w
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
disco
>> 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
Peter Eisentraut 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 libbsd.so,
>> wh
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
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 l
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 any
On 2012-12-18 13:14:10 +0100, Dimitri Fontaine wrote:
> Andres Freund 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
Andres Freund 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 eyeballs are needed.
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 interval
On Sunday, December 16, 2012 11:14 PM Tom Lane wrote:
> Pavan Deolasee writes:
> > On Sun, Dec 16, 2012 at 3:10 PM, Simon Riggs
> wrote:
> >> As explained above, I disagree that it looks like a good idea, and
> >> you've shown no evidence it would be or is true.
>
> > Lets separate out these two
On 18 December 2012 00:53, Tom Lane wrote:
> 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 t
On 18.12.2012 11:30, Simon Riggs wrote:
On 18 December 2012 09:18, Heikki Linnakangas 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?
Robert Haas 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 parser still wouldn't
On 18 December 2012 09:18, Heikki Linnakangas 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 said?
--
Simon Riggs
On 18.12.2012 00:35, Simon Riggs wrote:
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 som
On Tue, Dec 18, 2012 at 12:51 PM, Erik Rijkers 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 or
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, 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,
On Tue, Dec 18, 2012 at 11:45 AM, Erik Rijkers 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 some time
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 type
On 18 December 2012 02:21, Jeff Davis 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 ou
72 matches
Mail list logo
