Thank you for sugestion.
> This still makes catching up in standby mode slower, as you get
> many more restartpoints. The reason for ignoring
> checkpoint_segments during recovery was to avoid that.
I may have a misunderstanding around there, or your intention.
I understand that standby creates
Sorry for broken message.
> >From I said that the former (spinlock) could be dropped, but the
> latter (read as volatile) should be needed.
I said that the former (spinlock) could be dropped from the view
of functionarity, but the latter (read as volatile) should be
needed.
> >From the view of
On Fri, Apr 27, 2012 at 1:26 AM, Josh Berkus wrote:
> Simon,
>
>> I'm beginning to work on advanced additions to in-core replication for
>> PostgreSQL.
> ...
>> Those are the basic requirements that I am trying to address. There
>> are a great many important details, but the core of this is probab
On Fri, Apr 27, 2012 at 12:40 AM, Robert Haas wrote:
> On Thu, Apr 26, 2012 at 6:48 PM, Josh Berkus wrote:
>> So the idea is that you'll present briefly your intentions for 9.3 at
>> the developer meeting, and then have this in-depth afterwards? Sounds
>> great.
>
> I really, really do not want
On Fri, Apr 27, 2012 at 1:51 AM, Josh Berkus wrote:
> Now, the other issue I'd be worried about for this optimization is what
> happens when the nulls become non-trailing? For example, this pattern:
>
> 1. Out of 700 columns, columns 301+ are all Null, so we map them away.
> 2. User updates colu
Hi,
This is the version I used to run the following commands
select version();
version
PostgreSQL 9.2devel on x86_64-unknown-linux-gnu, compiled by gcc
(Ubuntu/Linaro 4.4.4-14ubuntu5
When I do this:
rhaas=# set default_transaction_isolation = 'serializable';
SET
rhaas=# begin;
BEGIN
rhaas=# select 1;
Then I get this:
TRAP: FailedAssertion("!(!RecoveryInProgress())", File: "predicate.c",
Line: 1637)
LOG: server process (PID 290) was terminated by signal 6: Abort trap
The ro
On 04/27/2012 08:25 AM, Abbas Butt wrote:
The notation "relation.*" represents a whole-row reference.
While parsing a whole-row reference is transformed into a Var with
varno set to the correct range table entry,
and varattno == 0 to signal that it references the whole tuple. (For
reference
Robert Haas wrote:
> When I do this:
>
> rhaas=# set default_transaction_isolation = 'serializable';
> SET
> rhaas=# begin;
> BEGIN
> rhaas=# select 1;
>
> Then I get this:
>
> TRAP: FailedAssertion("!(!RecoveryInProgress())", File:
> "predicate.c", Line: 1637)
> LOG: server process (PID 290
On Thu, Apr 26, 2012 at 03:19:04PM -0400, Bruce Momjian wrote:
> On Thu, Apr 26, 2012 at 02:05:23PM -0400, Tom Lane wrote:
> > Bruce Momjian writes:
> > > I agree adding rarely-used options to a tool doesn't make sense, but the
> > > question is what percentage of the git_changelog userbase am I?
On Fri, Apr 27, 2012 at 10:21 AM, Kevin Grittner
wrote:
> My first thought was that if we can detect that we are in HS, we
> should probably throw an ERROR on an attempt to set
> default_transaction_isolation = 'serializable'.
I think that would result in the server failing to start. We could
th
Robert Haas writes:
> Or, maybe there's a way to throw an error when serializable mode is
> used rather than when it's requested.
Couldn't we check and throw an error at the place in transaction startup
where default_transaction_isolation is copied to the active variable?
On Fri, Apr 27, 2012 at 11:02 AM, Tom Lane wrote:
> Robert Haas writes:
>> Or, maybe there's a way to throw an error when serializable mode is
>> used rather than when it's requested.
>
> Couldn't we check and throw an error at the place in transaction startup
> where default_transaction_isolatio
Tom Lane wrote:
> Robert Haas writes:
>> Or, maybe there's a way to throw an error when serializable mode
>> is used rather than when it's requested.
>
> Couldn't we check and throw an error at the place in transaction
> startup where default_transaction_isolation is copied to the
> active varia
I notice that there isn't a parameter called enable_indexonly (or similar).
ISTM that such a major new feature should be controlled by a planner
method parameter, just as all the existing planner methods are.
This will help us evaluate index only scans in production, and turn
them off if they hav
On 27 April 2012 16:08, Simon Riggs wrote:
> I notice that there isn't a parameter called enable_indexonly (or similar).
>
> ISTM that such a major new feature should be controlled by a planner
> method parameter, just as all the existing planner methods are.
>
> This will help us evaluate index o
On Fri, Apr 27, 2012 at 4:41 PM, Thom Brown wrote:
> On 27 April 2012 16:08, Simon Riggs wrote:
>> I notice that there isn't a parameter called enable_indexonly (or similar).
>>
>> ISTM that such a major new feature should be controlled by a planner
>> method parameter, just as all the existing p
On 04/27/2012 11:45 AM, Simon Riggs wrote:
On Fri, Apr 27, 2012 at 4:41 PM, Thom Brown wrote:
On 27 April 2012 16:08, Simon Riggs wrote:
I notice that there isn't a parameter called enable_indexonly (or similar).
ISTM that such a major new feature should be controlled by a planner
method p
On Fri, Apr 27, 2012 at 6:25 PM, Andrew Dunstan wrote:
>
>
> On 04/27/2012 08:25 AM, Abbas Butt wrote:
>
>>
>> The notation "relation.*" represents a whole-row reference.
>> While parsing a whole-row reference is transformed into a Var with varno
>> set to the correct range table entry,
>> and va
On 04/27/2012 12:02 PM, Abbas Butt wrote:
However, is this a change we really want to make?:
pg_get_triggerdef
---
"Kevin Grittner" writes:
> Tom Lane wrote:
>> Couldn't we check and throw an error at the place in transaction
>> startup where default_transaction_isolation is copied to the
>> active variable?
> Wouldn't that leave users stuck if the postgresql.conf set the
> default to serializable? Nobody
On Fri, Apr 27, 2012 at 4:56 PM, Andrew Dunstan wrote:
>> (Easier when they used to look different...)
>
>
> Maybe we should have the stylesheet watermark the dev docs pages.
+1
Many users have >1 version in production. This would help
--
Simon Riggs http://www.2ndQuadrant.
On Fri, Apr 27, 2012 at 17:56, Andrew Dunstan wrote:
>
>
> On 04/27/2012 11:45 AM, Simon Riggs wrote:
>>
>> On Fri, Apr 27, 2012 at 4:41 PM, Thom Brown wrote:
>>>
>>> On 27 April 2012 16:08, Simon Riggs wrote:
I notice that there isn't a parameter called enable_indexonly (or
simil
Tom Lane wrote:
> Yeah, it would definitely be nicer if BEGIN; SET TRANSACTION LEVEL
> would work too. Maybe the place to put the check is where we
> establish the transaction snapshot.
That makes sense, and doesn't seem like it would be hard, from what
I recall of that code. I know I've fal
On Wed, Dec 15, 2010 at 10:11 AM, Alvaro Herrera
wrote:
> It occurs to me that we may need a new mode, which disconnects sessions
> that are not in a transaction (or as soon as they are) but leaves
> in-progress transactions alone; this could be the new default. Of
> course, this is much more dif
On Fri, Apr 27, 2012 at 19:42, Robert Haas wrote:
> On Wed, Dec 15, 2010 at 10:11 AM, Alvaro Herrera
> wrote:
>> It occurs to me that we may need a new mode, which disconnects sessions
>> that are not in a transaction (or as soon as they are) but leaves
>> in-progress transactions alone; this cou
On Fri, Apr 27, 2012 at 1:46 PM, Magnus Hagander wrote:
> On Fri, Apr 27, 2012 at 19:42, Robert Haas wrote:
>> On Wed, Dec 15, 2010 at 10:11 AM, Alvaro Herrera
>> wrote:
>>> It occurs to me that we may need a new mode, which disconnects sessions
>>> that are not in a transaction (or as soon as t
> What I'm hoping to do is to build a basic prototype of logical
> replication using WAL translation, so we can inspect it to see what
> the downsides are.
Sounds like Mammoth. You take a look at that?
--
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com
--
Sent via pgsql-hackers mai
Andrew Dunstan writes:
> Right, what I'm asking is whether or not we actually want that side
> effect in all cases, and specifically in this case where it's clearly
> not necessary.
We could dodge that case by only changing the behavior when showstar is
false; there is no need to change it othe
Robert Haas writes:
> On Wed, Dec 15, 2010 at 10:11 AM, Alvaro Herrera
> wrote:
>> It occurs to me that we may need a new mode, which disconnects sessions
>> that are not in a transaction (or as soon as they are) but leaves
>> in-progress transactions alone; this could be the new default. Of
>>
On Fri, Apr 27, 2012 at 6:59 PM, Josh Berkus wrote:
>
>> What I'm hoping to do is to build a basic prototype of logical
>> replication using WAL translation, so we can inspect it to see what
>> the downsides are.
>
> Sounds like Mammoth. You take a look at that?
Well, they all sound similar. My
On Fri, Apr 27, 2012 at 11:21 PM, Tom Lane wrote:
> Andrew Dunstan writes:
> > Right, what I'm asking is whether or not we actually want that side
> > effect in all cases, and specifically in this case where it's clearly
> > not necessary.
>
> We could dodge that case by only changing the behavi
On Fri, Apr 27, 2012 at 7:29 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Wed, Dec 15, 2010 at 10:11 AM, Alvaro Herrera
>> wrote:
>>> It occurs to me that we may need a new mode, which disconnects sessions
>>> that are not in a transaction (or as soon as they are) but leaves
>>> in-progress t
Hi,
On Friday, April 27, 2012 07:42:59 PM Robert Haas wrote:
> On Wed, Dec 15, 2010 at 10:11 AM, Alvaro Herrera
> wrote:
> > It occurs to me that we may need a new mode, which disconnects sessions
> > that are not in a transaction (or as soon as they are) but leaves
> > in-progress transactions a
On Friday, April 27, 2012 08:38:10 PM Simon Riggs wrote:
> On Fri, Apr 27, 2012 at 7:29 PM, Tom Lane wrote:
> > Robert Haas writes:
> >> On Wed, Dec 15, 2010 at 10:11 AM, Alvaro Herrera
> >>
> >> wrote:
> >>> It occurs to me that we may need a new mode, which disconnects sessions
> >>> that are
Simon Riggs writes:
> On Fri, Apr 27, 2012 at 7:29 PM, Tom Lane wrote:
>> No, I'm not happy with that. Smart shutdown is defined to not affect
>> current sessions. I'm fine with having a fourth mode that acts as you
>> suggest (and, probably, even with making it the default); but not with
>> ta
On Fri, Apr 27, 2012 at 20:48, Tom Lane wrote:
> Simon Riggs writes:
>> On Fri, Apr 27, 2012 at 7:29 PM, Tom Lane wrote:
>>> No, I'm not happy with that. Smart shutdown is defined to not affect
>>> current sessions. I'm fine with having a fourth mode that acts as you
>>> suggest (and, probably
Magnus Hagander writes:
> On Fri, Apr 27, 2012 at 20:48, Tom Lane wrote:
>> I'm not necessarily opposed to commandeering the name "smart" for the
>> new behavior, so that what we have to find a name for is the old "smart"
>> behavior. How about
>>
>>slow- allow existing sessions to
On Fri, Apr 27, 2012 at 2:29 PM, Tom Lane wrote:
>> This idea appeared to have some support. I'd like to suggest that we
>> take this a step further. Instead of adding a fourth mode, I'd like
>> to suggest that we redefine "smart" to have the behavior described
>> above.
>
> No, I'm not happy wi
On Fri, Apr 27, 2012 at 2:48 PM, Tom Lane wrote:
> I'm not necessarily opposed to commandeering the name "smart" for the
> new behavior, so that what we have to find a name for is the old "smart"
> behavior. How about
>
> slow - allow existing sessions to finish (old "smart")
> s
On Thu, Apr 26, 2012 at 09:25:25PM +0300, Peter Eisentraut wrote:
> On m??n, 2012-04-23 at 12:30 -0400, Noah Misch wrote:
> > I've been enjoying "\x auto" in .psqlrc, but I noticed the row count footer
> > missing when it chooses ordinary output:
>
> > Looks like the logic in printQuery() needs fu
On 27.04.2012 21:56, Tom Lane wrote:
Magnus Hagander writes:
On Fri, Apr 27, 2012 at 20:48, Tom Lane wrote:
I'm not necessarily opposed to commandeering the name "smart" for the
new behavior, so that what we have to find a name for is the old "smart"
behavior. How about
slow- al
Sure Kevin, will get the wiki page ready asap, and reply back. Thanks.
On Thu, Apr 26, 2012 at 8:10 PM, Kevin Grittner wrote:
> [resending because of postgresql.org bounces on first try]
>
> Simon Riggs wrote:
> > Kevin Grittner wrote:
>
> >> The GSoC xReader project is intended to be a major
On Fri, Apr 27, 2012 at 3:00 PM, Robert Haas wrote:
> On Fri, Apr 27, 2012 at 2:48 PM, Tom Lane wrote:
>> I'm not necessarily opposed to commandeering the name "smart" for the
>> new behavior, so that what we have to find a name for is the old "smart"
>> behavior. How about
>>
>> slow
Heikki Linnakangas wrote:
> Just thinking out loud here..
In the spirit of kicking around ideas...
For those writing service scripts where you want a time limit on how
long a stop can take, so that the service script doesn't prevent OS
shutdown within a bounded time, it would also be nice to
On fre, 2012-04-27 at 20:39 +0200, Andres Freund wrote:
> I think the current smart mode is rather useful. There is quite some
> stuff that you cannot do inside a transaction - or it doesn't make
> sense - which still needs to shutdown gracefully. E.g. transaction
> managers.
Could you elaborate o
On tor, 2012-04-26 at 17:32 +0500, Asif Naeem wrote:
> PFA test case. It used simple select statement to retrieve data via
> plpython. It crashes latest pg 9.2 with the following stack trace i.e.
> Apparently it is being crashed because of invalid related pointer value of
> pfree() *header->contex
On Friday, April 27, 2012 10:17:59 PM Peter Eisentraut wrote:
> On fre, 2012-04-27 at 20:39 +0200, Andres Freund wrote:
> > I think the current smart mode is rather useful. There is quite some
> > stuff that you cannot do inside a transaction - or it doesn't make
> > sense - which still needs to sh
All, the wiki page is now up at http://wiki.postgresql.org/wiki/XReader.
On Sat, Apr 28, 2012 at 1:19 AM, Aakash Goel wrote:
> Sure Kevin, will get the wiki page ready asap, and reply back. Thanks.
>
>
> On Thu, Apr 26, 2012 at 8:10 PM, Kevin Grittner <
> kevin.gritt...@wicourts.gov> wrote:
>
>>
On Fri, Apr 27, 2012 at 1:57 PM, Robert Haas wrote:
> I think there is no point at all in having a discussion about this
> unless we can first agree that the overwhelming majority of people who
> have commented on this issue on this list are unhappy with the current
> default behavior.
count me i
[replaced bad email address for Josh (which was my fault)]
Aakash Goel wrote:
> All, the wiki page is now up at
> http://wiki.postgresql.org/wiki/XReader.
Note that the approach Aakash is taking doesn't involve changes to
the backend code, it is strictly a standalone executable to which
fun
>> I suspect that's a bit aggressive. We have a couple of issues that I
>> think we should fix before beta1:
Hmmm. So are we looking at May 7? Or later?
I'd like to do some press work for this.
--
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com
--
Sent via pgsql-hackers mailing li
On Thu, Apr 26, 2012 at 03:19:04PM -0400, Bruce Momjian wrote:
> Also consider that A is usually the big, clear commit message, and B,C,D
> are just minor adjustments with more brief commits, which might require
> adjusting the release note item for feature A. When they are in
> newest-first order
On Fri, Apr 27, 2012 at 02:16:02PM -0700, Josh Berkus wrote:
>
> >> I suspect that's a bit aggressive. We have a couple of issues that I
> >> think we should fix before beta1:
>
> Hmmm. So are we looking at May 7? Or later?
>
> I'd like to do some press work for this.
Someone said one week as
On Friday, April 27, 2012 11:04:04 PM Kevin Grittner wrote:
> [replaced bad email address for Josh (which was my fault)]
>
> Aakash Goel wrote:
> > All, the wiki page is now up at
> >
> > http://wiki.postgresql.org/wiki/XReader.
>
> Note that the approach Aakash is taking doesn't involve chang
On 4/27/12 2:29 PM, Bruce Momjian wrote:
> On Fri, Apr 27, 2012 at 02:16:02PM -0700, Josh Berkus wrote:
>>
I suspect that's a bit aggressive. We have a couple of issues that I
think we should fix before beta1:
>>
>> Hmmm. So are we looking at May 7? Or later?
>>
>> I'd like to do some p
On Fri, Apr 27, 2012 at 02:43:13PM -0700, Josh Berkus wrote:
> On 4/27/12 2:29 PM, Bruce Momjian wrote:
> > On Fri, Apr 27, 2012 at 02:16:02PM -0700, Josh Berkus wrote:
> >>
> I suspect that's a bit aggressive. We have a couple of issues that I
> think we should fix before beta1:
> >>
>
Robert Haas writes:
> It seems we need another signal for the new mode, and the obvious
> candidate is SIGUSR2. But what shall the mapping look like?
> [Choice #1] SIGUSR2 -> slow, SIGTERM -> smart, SIGINT -> fast, SIGQUIT
> -> immediate
> [Choice #2] SIGTERM -> slow, SIGUSR2 -> smart, SIGINT ->
Andres Freund wrote:
> In the current, prototypal, state there is one component thats
> integrated into the server (because it needs information thats
> only available there).
The xReader design was based on the idea that it would be nice not
to cause load on the master machine, and that by pr
On 04/26/2012 12:57 PM, Robert Haas wrote:
I don't recall seeing any previous postings about the 2Q project,
either. We should try to keep these discussions on-list.
First brought up two months ago to the list it seemed most relevant to
at the time:
http://archives.postgresql.org/pgsql-clust
On 04/27/2012 11:33 AM, Simon Riggs wrote:
Well, they all sound similar. My info was that Mammoth was not WAL-based.
Mammoth was transaction log based but not WAL based.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postg
Hi Kevin, Hi Aakash,
On Saturday, April 28, 2012 12:18:38 AM Kevin Grittner wrote:
> Andres Freund wrote:
> > In the current, prototypal, state there is one component thats
> > integrated into the server (because it needs information thats
> > only available there).
> The xReader design was based
Abbas Butt writes:
> On Fri, Apr 27, 2012 at 11:21 PM, Tom Lane wrote:
>> More generally, it seems rather inelegant to be forcibly adding a cast
>> when in most cases the existing notation is not wrong. AFAICS the
>> plain "relname" notation is only ambiguous if there is a column of the
>> same
Greg Smith wrote:
> On 04/26/2012 12:57 PM, Robert Haas wrote:
>> I don't recall seeing any previous postings about the 2Q project,
>> either. We should try to keep these discussions on-list.
>
> First brought up two months ago to the list it seemed most
> relevant to at the time:
>
http://arch
On Fri, Apr 27, 2012 at 4:11 AM, Simon Riggs wrote:
> What I'm hoping to do is to build a basic prototype of logical
> replication using WAL translation, so we can inspect it to see what
> the downsides are. It's an extremely non-trivial problem and so I
> expect there to be mountains to climb. Th
Peter Eisentraut writes:
> I must have been confused about the tuple descriptor APIs. ob->tupdesc
> is created using CreateTupleDescCopy(), which copies the refcount of the
> original tuple descriptor,
Um, surely not. That would be nonsensical, and anyway a look at the
code shows it isn't doing
Andres Freund wrote:
> Something like registering/deregistering also doesn't fit that
> well with the way walsender works as far as I understand it.
If you look at the diagrams on the xReader Wiki page, the lines
labeled "XLOG stream" are the ones using walsender/walreceiver. The
green arrows
Josh Berkus writes:
> On 4/27/12 2:29 PM, Bruce Momjian wrote:
>> Someone said one week as not enough, so I assumed a wrap on May 10 with
>> beta release on May 14.
> Doing a release on May 14 will be a challenge, thanks to people being on
> airplanes to pgCon. We might want to verify availabili
Hi,
On Fri, 2012-04-27 at 19:02 -0400, Tom Lane wrote:
> The website crew might have a problem though.
Magnus is flying on 13th and 14th, Dave, Stefan and Thom are flying on
14th. I'm flying on 15th -- it seems I have some cycles for updating
website, I hope. Not sure about the others.
(As a si
Devrim =?ISO-8859-1?Q?G=DCND=DCZ?= writes:
> (As a side note, RPMs *may not* be ready, because I (and Magnus) will be
> at PGDay Turkey on 12th, and will be busy over the whole weekend).
Ugh. Maybe the whole idea of getting a beta out before PGCon is doomed.
Still, if we don't try for this sched
On Fri, Apr 27, 2012 at 07:19:55PM -0400, Tom Lane wrote:
> Devrim =?ISO-8859-1?Q?G=DCND=DCZ?= writes:
> > (As a side note, RPMs *may not* be ready, because I (and Magnus) will be
> > at PGDay Turkey on 12th, and will be busy over the whole weekend).
>
> Ugh. Maybe the whole idea of getting a be
> Ugh. Maybe the whole idea of getting a beta out before PGCon is doomed.
> Still, if we don't try for this schedule, we're looking at at least two
> more weeks' slip, because we're surely not going to wrap during PGCon.
We could do it in person!
--
Josh Berkus
PostgreSQL Experts Inc.
http://
> Do we want to do the normal package Thursday, release Monday process? I
> assumed we did.
Given that in the last 2 years, our betas have been "news", I think we
need to.
--
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgr
On 04/27/2012 06:48 PM, Kevin Grittner wrote:
That's largely my fault.
It may not have come out that way, but I was trying more to point out
the complexity of the story rather than assign blame. I find it hard to
point at any obvious "don't do that again" target here.
--
Greg Smith 2ndQu
Bruce Momjian writes:
> On Fri, Apr 27, 2012 at 07:19:55PM -0400, Tom Lane wrote:
>> Ugh. Maybe the whole idea of getting a beta out before PGCon is doomed.
>> Still, if we don't try for this schedule, we're looking at at least two
>> more weeks' slip, because we're surely not going to wrap durin
On Fri, Apr 27, 2012 at 09:10:54PM -0400, Tom Lane wrote:
> Bruce Momjian writes:
> > On Fri, Apr 27, 2012 at 07:19:55PM -0400, Tom Lane wrote:
> >> Ugh. Maybe the whole idea of getting a beta out before PGCon is doomed.
> >> Still, if we don't try for this schedule, we're looking at at least two
Bruce Momjian writes:
> On Fri, Apr 27, 2012 at 09:10:54PM -0400, Tom Lane wrote:
>> How would that help? The bottleneck is packaging, which is the same
>> work whatever we call it.
> We release the alpha with no packaging.
Think we'd lose a lot of potential testers that way.
On Apr 27, 2012, at 21:24, Tom Lane wrote:
> Bruce Momjian writes:
>> On Fri, Apr 27, 2012 at 09:10:54PM -0400, Tom Lane wrote:
>>> How would that help? The bottleneck is packaging, which is the same
>>> work whatever we call it.
>
>> We release the alpha with no packaging.
>
> Think we'd los
Peter Eisentraut writes:
> On tor, 2012-04-26 at 17:32 +0500, Asif Naeem wrote:
>> PFA test case. It used simple select statement to retrieve data via
>> plpython. It crashes latest pg 9.2 with the following stack trace i.e.
>> Apparently it is being crashed because of invalid related pointer val
> "Kevin Grittner" wrote:
> Tom Lane wrote:
>
>> Yeah, it would definitely be nicer if BEGIN; SET TRANSACTION LEVEL
>> would work too. Maybe the place to put the check is where we
>> establish the transaction snapshot.
>
> That makes sense,
> I'll take a shot at it sometime today,
Attached
80 matches
Mail list logo
