Hello,
At Wed, 25 Apr 2012 02:31:24 +0900, Fujii Masao masao.fu...@gmail.com wrote
in CAHGQGwE1OvB=HLcahLeL5oP66sxsfsGMgwU3MqAAwZ_Vr=x...@mail.gmail.com
If we are allowed to be tolerant of the temporary lack of
coherence in shared memory there, the spinlock could be removed.
But the
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 no
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 j...@agliodbs.com 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
On Fri, Apr 27, 2012 at 12:40 AM, Robert Haas robertmh...@gmail.com wrote:
On Thu, Apr 26, 2012 at 6:48 PM, Josh Berkus j...@agliodbs.com 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.
On Fri, Apr 27, 2012 at 1:51 AM, Josh Berkus j...@agliodbs.com 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
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
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 root
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 robertmh...@gmail.com 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
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 br...@momjian.us writes:
I agree adding rarely-used options to a tool doesn't make sense, but the
question is what percentage of the git_changelog
On Fri, Apr 27, 2012 at 10:21 AM, Kevin Grittner
kevin.gritt...@wicourts.gov 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
Robert Haas robertmh...@gmail.com 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 t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com 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
Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com 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
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
On 27 April 2012 16:08, Simon Riggs si...@2ndquadrant.com 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
On Fri, Apr 27, 2012 at 4:41 PM, Thom Brown t...@linux.com wrote:
On 27 April 2012 16:08, Simon Riggs si...@2ndquadrant.com 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,
On 04/27/2012 11:45 AM, Simon Riggs wrote:
On Fri, Apr 27, 2012 at 4:41 PM, Thom Brownt...@linux.com wrote:
On 27 April 2012 16:08, Simon Riggssi...@2ndquadrant.com wrote:
I notice that there isn't a parameter called enable_indexonly (or similar).
ISTM that such a major new feature should
On Fri, Apr 27, 2012 at 6:25 PM, Andrew Dunstan and...@dunslane.net 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,
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 kevin.gritt...@wicourts.gov writes:
Tom Lane t...@sss.pgh.pa.us 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
On Fri, Apr 27, 2012 at 4:56 PM, Andrew Dunstan and...@dunslane.net 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
On Fri, Apr 27, 2012 at 17:56, Andrew Dunstan and...@dunslane.net wrote:
On 04/27/2012 11:45 AM, Simon Riggs wrote:
On Fri, Apr 27, 2012 at 4:41 PM, Thom Brownt...@linux.com wrote:
On 27 April 2012 16:08, Simon Riggssi...@2ndquadrant.com wrote:
I notice that there isn't a parameter
Tom Lane t...@sss.pgh.pa.us 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.
On Wed, Dec 15, 2010 at 10:11 AM, Alvaro Herrera
alvhe...@commandprompt.com 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 19:42, Robert Haas robertmh...@gmail.com wrote:
On Wed, Dec 15, 2010 at 10:11 AM, Alvaro Herrera
alvhe...@commandprompt.com 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
On Fri, Apr 27, 2012 at 1:46 PM, Magnus Hagander mag...@hagander.net wrote:
On Fri, Apr 27, 2012 at 19:42, Robert Haas robertmh...@gmail.com wrote:
On Wed, Dec 15, 2010 at 10:11 AM, Alvaro Herrera
alvhe...@commandprompt.com wrote:
It occurs to me that we may need a new mode, which disconnects
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
Andrew Dunstan and...@dunslane.net 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
Robert Haas robertmh...@gmail.com writes:
On Wed, Dec 15, 2010 at 10:11 AM, Alvaro Herrera
alvhe...@commandprompt.com 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
On Fri, Apr 27, 2012 at 6:59 PM, Josh Berkus j...@agliodbs.com 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
On Fri, Apr 27, 2012 at 11:21 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Andrew Dunstan and...@dunslane.net 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
On Fri, Apr 27, 2012 at 7:29 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
On Wed, Dec 15, 2010 at 10:11 AM, Alvaro Herrera
alvhe...@commandprompt.com wrote:
It occurs to me that we may need a new mode, which disconnects sessions
that are not in a
Hi,
On Friday, April 27, 2012 07:42:59 PM Robert Haas wrote:
On Wed, Dec 15, 2010 at 10:11 AM, Alvaro Herrera
alvhe...@commandprompt.com 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
On Friday, April 27, 2012 08:38:10 PM Simon Riggs wrote:
On Fri, Apr 27, 2012 at 7:29 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
On Wed, Dec 15, 2010 at 10:11 AM, Alvaro Herrera
alvhe...@commandprompt.com wrote:
It occurs to me that we may need a
Simon Riggs si...@2ndquadrant.com writes:
On Fri, Apr 27, 2012 at 7:29 PM, Tom Lane t...@sss.pgh.pa.us 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
On Fri, Apr 27, 2012 at 20:48, Tom Lane t...@sss.pgh.pa.us wrote:
Simon Riggs si...@2ndquadrant.com writes:
On Fri, Apr 27, 2012 at 7:29 PM, Tom Lane t...@sss.pgh.pa.us wrote:
No, I'm not happy with that. Smart shutdown is defined to not affect
current sessions. I'm fine with having a fourth
Magnus Hagander mag...@hagander.net writes:
On Fri, Apr 27, 2012 at 20:48, Tom Lane t...@sss.pgh.pa.us 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-
On Fri, Apr 27, 2012 at 2:29 PM, Tom Lane t...@sss.pgh.pa.us 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
On Fri, Apr 27, 2012 at 2:48 PM, Tom Lane t...@sss.pgh.pa.us 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)
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 further
On 27.04.2012 21:56, Tom Lane wrote:
Magnus Hagandermag...@hagander.net writes:
On Fri, Apr 27, 2012 at 20:48, Tom Lanet...@sss.pgh.pa.us 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
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:
[resending because of postgresql.org bounces on first try]
Simon Riggs si...@2ndquadrant.com wrote:
Kevin Grittner
On Fri, Apr 27, 2012 at 3:00 PM, Robert Haas robertmh...@gmail.com wrote:
On Fri, Apr 27, 2012 at 2:48 PM, Tom Lane t...@sss.pgh.pa.us 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.
Heikki Linnakangas heikki.linnakan...@enterprisedb.com 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
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 on
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()
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 shutdown
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 aakash.b...@gmail.com 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
On Fri, Apr 27, 2012 at 1:57 PM, Robert Haas robertmh...@gmail.com 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
[replaced bad email address for Josh (which was my fault)]
Aakash Goel aakash.b...@gmail.com 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
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 list
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 not
On Friday, April 27, 2012 11:04:04 PM Kevin Grittner wrote:
[replaced bad email address for Josh (which was my fault)]
Aakash Goel aakash.b...@gmail.com wrote:
All, the wiki page is now up at
http://wiki.postgresql.org/wiki/XReader.
Note that the approach Aakash is taking doesn't
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 press work for
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:
Hmmm. So are we
Robert Haas robertmh...@gmail.com 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 -
Andres Freund and...@2ndquadrant.com 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
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:
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:
Hi Kevin, Hi Aakash,
On Saturday, April 28, 2012 12:18:38 AM Kevin Grittner wrote:
Andres Freund and...@2ndquadrant.com 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
Abbas Butt abbas.b...@enterprisedb.com writes:
On Fri, Apr 27, 2012 at 11:21 PM, Tom Lane t...@sss.pgh.pa.us 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
Greg Smith g...@2ndquadrant.com 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:
On Fri, Apr 27, 2012 at 4:11 AM, Simon Riggs si...@2ndquadrant.com 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
Peter Eisentraut pete...@gmx.net 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
Andres Freund and...@2ndquadrant.com 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
Josh Berkus j...@agliodbs.com 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
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
Devrim =?ISO-8859-1?Q?G=DCND=DCZ?= dev...@gunduz.org 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
On Fri, Apr 27, 2012 at 07:19:55PM -0400, Tom Lane wrote:
Devrim =?ISO-8859-1?Q?G=DCND=DCZ?= dev...@gunduz.org 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
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.
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
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
Bruce Momjian br...@momjian.us 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
On Fri, Apr 27, 2012 at 09:10:54PM -0400, Tom Lane wrote:
Bruce Momjian br...@momjian.us 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
Bruce Momjian br...@momjian.us 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 t...@sss.pgh.pa.us wrote:
Bruce Momjian br...@momjian.us 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
Peter Eisentraut pete...@gmx.net 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
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. With a
81 matches
Mail list logo
