On 2015-11-15 16:24:24 -0500, Robert Haas wrote:
> I think it needs to be adapted to use predefined constants for the
> tranche IDs instead of hardcoded values, maybe based on the attached
> tranche-constants.patch.
Yea, that part is clearly not ok. Let me look at the patch.
> Also, I think we
On 2015-11-17 14:14:50 +0300, Ildus Kurbangaliev wrote:
> 1) We can avoid constants, and use a standard steps for tranches
> creation.
The constants are actually a bit useful, to easily determine
builtin/non-builtin stuff.
> 2) We have only one global variable (BufferCtl)
Don't see the
On 2015-08-04 23:37:08 +0300, Ildus Kurbangaliev wrote:
> diff --git a/src/backend/access/transam/clog.c
> b/src/backend/access/transam/clog.c
> index 3a58f1e..10c25cf 100644
> --- a/src/backend/access/transam/clog.c
> +++ b/src/backend/access/transam/clog.c
> @@ -457,7 +457,8 @@
On 2015-09-06 22:57:04 +0300, Ildus Kurbangaliev wrote:
> Ok, I've kept only one tranche for individual LWLocks
But you've added the lock names as a statically sized array to all
tranches? Why not just a pointer to an array that's either NULL ('not
individualy named locks') or appropriately
Hi,
On 2015-09-05 12:48:12 +0300, Ildus Kurbangaliev wrote:
> Another parts require a some discussion so I didn't touch them yet.
At this point I don't see any point in further review until these are
addressed.
> The idea to create an individual tranches for individual LWLocks have
> come from
On 2015-09-15 14:39:51 -0400, Robert Haas wrote:
> We could, but since that would be strictly more annoying and less
> flexible than what we've already got, why would we?
I don't find the current approach of having to define tranches in every
backend all that convenient. It also completely breaks
On 2015-12-12 21:15:52 -0500, Robert Haas wrote:
> On Sat, Dec 12, 2015 at 1:17 PM, and...@anarazel.de <and...@anarazel.de>
> wrote:
> > Here's two patches doing that. The first is an adaption of your
> > constants patch, using an enum and also converting xlog.c
On 2015-11-15 16:24:24 -0500, Robert Haas wrote:
> I think what we should do about the buffer locks is polish up this
> patch and get it applied:
>
> http://www.postgresql.org/message-id/20150907175909.gd5...@alap3.anarazel.de
>
> I think it needs to be adapted to use pr
:25 -0500, Bruce Momjian wrote:
> > > > Yes? But it's ok sizewise on the common platforms?
> > >
> > > What is the uncommon part? I guess I missed that.
> >
> > http://archives.postgresql.org/message-id/20151212181702.GH17938%40alap3.anarazel.de
>
&
I missed that.
http://archives.postgresql.org/message-id/20151212181702.GH17938%40alap3.anarazel.de
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
when it's
> > > > larger than 4 bytes. I'm not sure if that's cause for real concern,
> > > > given that it's not very concurrent or ancient platforms where that's
> > > > the case.
> > > > http://archives.postgresql.org/message-id/20150915020625.GI9666%
On 2016-01-26 13:22:09 +0530, Amit Kapila wrote:
> @@ -633,9 +633,11 @@ postgres 27093 0.0 0.0 30096 2752 ?Ss
> 11:34 0:00 postgres: ser
> Time when the state was last changed
>
>
> - waiting
> - boolean
> - True if this backend is currently waiting
Tom Lane t...@sss.pgh.pa.us schrieb:
Andres Freund and...@anarazel.de writes:
I refreshed the patch so it works again on current HEAD. Basically
some
trivial fixes and dfd26f9c5f371437f243249025863ea9911aacaa. The
latter doesn't
seem necessary to me after the changes, so I simply ditched
anara...@anarazel.de and...@anarazel.de schrieb:
Thom Brown t...@linux.com schrieb:
On 2 March 2012 23:33, Thom Brown t...@linux.com wrote:
On 2 March 2012 22:32, Dimitri Fontaine dimi...@2ndquadrant.fr
wrote:
test=# CREATE TABLE badname (id int, a int, b text);
ERROR: invalid relation
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
Tom Lane t...@sss.pgh.pa.us schrieb:
Greg Smith g...@2ndquadrant.com writes:
To try and speed up replicating this problem I switched to a smaller
database scale, 100, and I was able to get a crash there. Here's the
latest:
2012-12-26 00:01:19 EST [2278]: WARNING: refcount of
Tom Lane t...@sss.pgh.pa.us schrieb:
Andres Freund and...@2ndquadrant.com writes:
I am still worried about the following scenario in the EXEC_BACKEND
case:
1) postmaster starts
2) reads config
3) executes _PG_init for shared_preload_libraries
4) library 'abc' gets config value
Robert Haas robertmh...@gmail.com schrieb:
On Sat, Dec 29, 2012 at 4:30 PM, Peter Geoghegan
pe...@2ndquadrant.com wrote:
Ascertaining the identity of the object in question perfectly
unambiguously, so that you can safely do something like lookup a
comment on the object, seems like something
Tom Lane t...@sss.pgh.pa.us schrieb:
Andres Freund and...@2ndquadrant.com writes:
On 2013-01-09 11:27:46 -0500, Tom Lane wrote:
I'd prefer posting a single message with the discussion and the
patch(es). If you think it's helpful to split a patch into separate
parts for reviewing, add
Josh Berkus j...@agliodbs.com schrieb:
Andreas,
Is there a git fork for logical replication somewhere?
Check the bottom of the email ;)
---
Please excuse brevity and formatting - I am writing this on my mobile phone.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
Tom Lane t...@sss.pgh.pa.us schrieb:
Andres Freund and...@2ndquadrant.com writes:
I don't find that a convincing comparison. Normally don't need to
shutdown the
server between two pg_dump commands. Which very well might be
scripted.
Especially as for now, without a background
Tom Lane t...@sss.pgh.pa.us schrieb:
Andres Freund and...@2ndquadrant.com writes:
On 2013-02-17 15:10:35 +, Greg Stark wrote:
Peter G is sitting near me and reminded me that this issue came up
in the
past. Iirc the conclusion then is that we're calling memcpy where
the
source and
Tom Lane t...@sss.pgh.pa.us schrieb:
Boszormenyi Zoltan z...@cybertec.at writes:
Then, why isn't memcpy() skipped if the source and dest are the same?
It would be a micro-optimization but a valid one.
No, it'd be more like a micro-pessimization, because the test would be
wasted effort in the
Peter Geoghegan peter.geoghega...@gmail.com schrieb:
On 17 February 2013 18:52, anara...@anarazel.de and...@anarazel.de
wrote:
You already need a suppression file to use valgrind sensibly, its
easy enough to add it there. Perhaps we should add one to the tree?
Perhaps you should take the time
Hi,
Michael Paquier michael.paqu...@gmail.com schrieb:
Andres, Masao, do you need an extra round or review or do you think
this is
ready to be marked as committer?
On my side I have nothing more to add to the existing patches.
I think they do need review before that - I won't be able to do
Kevin Grittner kgri...@ymail.com schrieb:
Andres Freund and...@2ndquadrant.com wrote:
if I understand things correctly REFRESH MATERIALIZED VIEW locks
the materialized view with an AcessExclusiveLock even if the view
already contains data.
Yeah. At the time I had to make a decision on
Tom Lane t...@sss.pgh.pa.us schrieb:
Bruce Momjian br...@momjian.us writes:
Should I just patch pg_upgrade to remove the indisvalid, skip
indisvalid indexes, and backpatch it? Users should be using the
version of pg_upgrade to match new pg_dump. Is there any case where
they don't match?
Tom Lane t...@sss.pgh.pa.us schrieb:
anara...@anarazel.de and...@anarazel.de writes:
Tom Lane t...@sss.pgh.pa.us schrieb:
Yeah, if you can just ignore !indisvalid indexes that should work
fine.
I see no need to look at indisready if you're doing that.
You need to look at inisready in 9.2
Andrew Dunstan and...@dunslane.net schrieb:
On 04/15/2013 11:46 AM, Andres Freund wrote:
Me either. It's an oversight, really. Unless there is any objection
I'll
change them toot sweet. What about the existing (as of 9.2)
functions?
ISTM json_in, out, recv, send should also be immutable.
Tom Lane t...@sss.pgh.pa.us schrieb:
Andres Freund and...@2ndquadrant.com writes:
On 2013-04-25 13:17:31 -0400, Tom Lane wrote:
Since we know that C.I.C. executes in its own transaction, and there
can't be more than one on the same table due to locking, it seems to
me
that it'd be safe to
Alex Goncharov alex-goncha...@comcast.net schrieb:
,--- You/Andres (Fri, 7 Oct 2011 02:28:30 +0200) *
| a lot of cases where the database could deduce (quite easily) that
a
| result column cannot be null
| Could you quickly explain what exactly you want that information for?
Just
|
Kevin Grittner kevin.gritt...@wicourts.gov schrieb:
Robert Haas robertmh...@gmail.com wrote:
Any chance you can run oprofile (on either branch, don't really
care) against the 32 client test and post the results?
Besides the other changes we discussed, I boosted scale to 150 and
ran at
32 matches
Mail list logo
