build farm that anybody can join, no fees,
no restrictions.
http://www.pgbuildfarm.org/cgi-bin/register-form.pl
Community assistance would be available to help.
--
Simon Riggs http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
--
Sent vi
swapping the
> table in the system catalog but I'm not sure about that yet.
This one is mine I don't think its important we hold that lock,
but will check.
--
Simon Riggs http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & S
s the reported lag in flush location merely an artifact
> of timing in the query, or is there something else going on? [1]
The writing of new WAL is independent of the wait that occurs on
commit, so it is entirely possible, even desirable, that the observed
effect occurs.
--
Simon Rigg
scanning N rows with LIMIT M we must assume that the action
relates in some way to N, rather than assuming the LIMIT is more and
more effective as N/M increases.
--
Simon Riggs http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
On 27 September 2012 22:29, Simon Riggs wrote:
> On 26 September 2012 22:33, wrote:
>> The following bug has been logged on the website:
>>
>> Bug reference: 7572
>> Logged by: Daniele Varrazzo
>> Email address: daniele.varra...@gmail
t particular coding was pretty weird. Please change.
--
Simon Riggs http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
ed to
be solved in the right way, not by having a too-far-forwards nextxid
on the checkpoint record. Having said that, I can't see any bugs that
would be caused by this.
--
Simon Riggs http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Servi
On 2 December 2012 12:51, Simon Riggs wrote:
> On 1 December 2012 22:56, Tom Lane wrote:
>> tar...@gmail.com writes:
>>> [ txid_current can show a bogus value near XID wraparound ]
>>> This happens only if wal_level=hot_standby.
>>
>> I bel
t it needs to
> change.
OK. At least we have the minimal coding to fall back on if need be.
> This coding was ill-considered from the word go.
Agreed, but then I don't have a clear reason why it is that way and
yet I'm sure I did it for some reason.
--
Simon Riggs
On 2 December 2012 16:44, Tom Lane wrote:
> Simon Riggs writes:
>> On 2 December 2012 15:25, Tom Lane wrote:
>>> This coding was ill-considered from the word go.
>
>> Agreed, but then I don't have a clear reason why it is that way and
>> yet I'm sur
So there's
> something wrong/incomplete about that fix.
>
> This is a bit urgent since we now have to consider whether to withdraw
> 9.2.2 and issue a hasty 9.2.3. Do we have a regression here since
> 9.2.1, and if so how bad is it?
I'll look at this now.
--
Si
ke the attached.
I've reworked pause logic along the lines you suggest. Attached here
for further discussion.
> This is not a regression because the pause logic is broken this same
> way since 9.1. So I no longer think that we need a rewrap.
I think we do need a rewrap, si
On 5 December 2012 13:34, Simon Riggs wrote:
> Aboriginal bug extends back to 9.0.
I don't see any bug in 9.0 and 9.1, just 9.2+
--
Simon Riggs http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
--
Sent via pgsql-bugs
with things.
You can, but by shutting down server, updating recovery target, then
restarting server.
That's not a beautiful design, its just waiting for someone to make
recovery targets changeable, which is best done when recovery.conf
parameters are in postgresql.conf
--
Simon Riggs
n about whether to continue applying WAL. As Simon
> mentioned, we seem to be lacking some infrastructure that would let
> the user adjust the recovery_target parameters before resuming WAL
> processing. But, assuming for the moment that our workaround for
> that is "shutdown t
On 5 December 2012 17:17, Simon Riggs wrote:
> The recovery target and the consistency point are in some ways in
> conflict. If the recovery target is before the consistency point there
> is no point in stopping there, whether or not we pause. What we should
> do is say "recove
On 5 December 2012 18:48, Tom Lane wrote:
> I wrote:
>> Andres Freund writes:
>>> On 2012-12-05 17:24:42 +, Simon Riggs wrote:
>>>> So ISTM that we should make recoveryStopsHere() return false while we
>>>> are inconsistent. Problems solved.
>
On 5 December 2012 21:15, Tom Lane wrote:
> Simon Riggs writes:
>> On 5 December 2012 18:48, Tom Lane wrote:
>>> On further thought, it seems like recovery_pause_at_target is rather
>>> misdesigned anyway, and taking recovery target parameters from
>>> recov
ely that we'd find out it is significant than
> that we'd find out anybody could detect the lack of a memory barrier
> there.
Agreed. And any future logic to stop at a specific point will be
exactly precise because the decision and action will be taken in same
process.
Patch l
ackup_label, that prevents normal
> startup before the issue is resolved?
Yes, I've thought about allowing recovery to skip corrupt indexes, but
that feature hasn't been implemented yet.
We'd need to track such things as recovery proceeds and then mark them
as invalid
initdb install:
>
> shared_buffers = 8GB
> work_mem = 64MB
> maintenance_work_mem = 256MB
> max_stack_depth = 8MB
> wal_level = hot_standby
> synchronous_commit = off
> wal_buffers = 64MB
> checkpoint_segments = 10
> checkpoint_completion_target = 0
> max_wal_senders =
> this.
Connection from a standby is disabled by default. Don't enable it...
--
Simon Riggs http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make cha
nly
NOREPLICATION allows neither option
--
Simon Riggs http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
; NOREPLICATION allows neither option
>>
> Someone is working for it already ?
> If not yet, may I try to implement it ?
Please do. It looks fairly short.
--
Simon Riggs http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
-
st simply mistyped the coordinates...
sriggs=# select point( polygon '((0,0),(0,1),(1,1),(1,0))');
point
---
(0.5,0.5)
(1 row)
Your last point is a duplicate of the 2nd point, so you have a
4-pointed triangle and hence a strange centre.
--
Simon Riggs http://
an take some time till we reach consistency it seems rather plausible
> that there now will be a gap in initilized pages. From
> checkPoint.oldestActiveXid to running->nextXid if there are pages
> inbetween.
That was an old bug.
StartupSUBTRANS() now explicitly fills th
n for that suggestion is that nobody ever
reported this bug, so either few people use binary mode or they use
the old syntax. Of course, that is not a normal suggestion, so feel
free to walk up and down my spine with boots on for suggesting it.
Thoughts?
--
Simon Riggs http://
{
> + $$ = makeDefElem($1, (Node *)
> makeString("binary"));
> + }
So, no that doesn't work.
--
Simon Riggs http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training &
o many people are
bothered, since no complaints in 3 years. Documenting 'binary' seems
better.
--
Simon Riggs http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.
On 27 May 2013 15:31, Tom Lane wrote:
> Simon Riggs writes:
>> On 26 May 2013 17:10, Tom Lane wrote:
>>> More readable would be to invent an intermediate nonterminal falling
>>> between ColId and ColLabel, whose expansion would be "IDENT |
>>&
ly tuned, as yet. Some room
for improvement exists.
In some cases, conscious choices were made to keep processing on
master fast at the expense of speed on the standby.
There doesn't seem to be anything which is in itself an error here.
--
Simon Riggs http://www.2ndQuadrant
, Andres.
>
> Are there any plans to commit this patch and what version it is going
> to be done to?
>
> Thank you.
I'll be committing this soon, since we're likely coming up to the next
point release soon.
Thanks for the reminder.
--
Simon Riggs http://www
I'm seeing this problem too, so I might be able to shed some light on it.
Here's exactly what I did:
> cd /usr/src/postgresql-9.0.2
> tar -xjvf postgresql-9.0.2.tar.bz2
> mv postgresql-9.0.2 src
> mkdir obj-x86_64
> cd obj-x86_64
> /usr/src/postgresql-9.0.2/src/configure
> '--prefix=/usr/local/p
201 - 233 of 233 matches
Mail list logo
