On Sat, Jun 28, 2014 at 1:48 PM, Andres Freund and...@2ndquadrant.com
wrote:
On 2014-06-28 11:58:41 +0530, Amit Kapila wrote:
1.
+pg_atomic_compare_exchange_u32_impl(volatile pg_atomic_uint32 *ptr,
+ uint32 *expected, uint32 newval)
+{
+ bool ret;
+ uint32 current;
+ current =
Hi
2014-06-29 0:48 GMT+02:00 MauMau maumau...@gmail.com:
From: Pavel Stehule pavel.steh...@gmail.com
I modified description of setting system variables in dependency on O.S.
Thank you, it's almost OK. As mentioned in my previous mail, I think
determines should be determine to follow
On 2014-06-29 11:53:28 +0530, Amit Kapila wrote:
On Sat, Jun 28, 2014 at 1:48 PM, Andres Freund and...@2ndquadrant.com
Two things:
a) compare_exchange is a read/write operator and so far I've defined it
to have full barrier semantics (documented in atomics.h). I'd be
happy to
On 2014-06-28 19:36:39 +0300, Heikki Linnakangas wrote:
On 06/27/2014 08:15 PM, Robert Haas wrote:
On Thu, Jun 26, 2014 at 3:04 PM, Andres Freund and...@2ndquadrant.com
wrote:
I don't really see usecases where it's not related data that's being
touched, but: The point is that the fastpath
On 29 June 2014 10:55, Andres Freund and...@2ndquadrant.com wrote:
So, I'd looked at it with an eye towards committing it and found some
more things. I've now
* added the restriction that the cluster name can only be ASCII. It's
shown from several clusters with differing encodings, and it's
On Fri, Jun 27, 2014 at 6:14 AM, Tom Lane t...@sss.pgh.pa.us wrote:
David Rowley dgrowle...@gmail.com writes:
If there's no way to tell that the target entry comes from a left join,
then would it be a bit too quirky to just do the NOT NULL checking when
list_length(query-rtable) == 1 ? or
Thanks, I marked it as ready for committer. I hope Fujii san or another
committer will commit this, refining English expression if necessary.
Regards
MauMau
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
Hi.
I've attached a patch to contrib/unaccent as outlined in my review the
other day. I'm familiar with multiple languages in which modifiers are
separate characters (but not Arabic), so I decided to try a quick test
because I was curious.
I added a line containing only U+0940 (DEVANAGARI VOWEL
Hi,
Thanks a lot for the review and comments. Here is an updated patch.
On 6/25/2014 8:20 AM, Abhijit Menon-Sen wrote:
Your patch should definitely add a test case or two to
sql/unaccent.sql and expected/unaccent.out showing the behaviour that
didn't work before the change.
That would
On 2014-06-29 11:11:14 +0100, Thomas Munro wrote:
On 29 June 2014 10:55, Andres Freund and...@2ndquadrant.com wrote:
So, I'd looked at it with an eye towards committing it and found some
more things. I've now
* added the restriction that the cluster name can only be ASCII. It's
shown
Hi.
When this patch was first added to a CF, I had a quick look at it, but
left it for a proper review by someone more familiar with PL/Python
internals for precisely this reason:
2) You removed the comment:
- /*
- * We don't support arrays of row
At 2014-06-29 18:08:53 +0530, a...@2ndquadrant.com wrote:
I think the patch is ready for committer.
That's based on my earlier quick look and the current archaeology. But
I'm not a PL/Python user, and Ronan signed up to review the patch, so I
haven't changed the status.
Ronan, did you get a
2014-06-29 13:35 GMT+02:00 MauMau maumau...@gmail.com:
Thanks, I marked it as ready for committer. I hope Fujii san or another
committer will commit this, refining English expression if necessary.
sure
Thank you very much
Regards
Pavel
Regards
MauMau
At 2014-06-29 20:35:04 +0900, maumau...@gmail.com wrote:
Thanks, I marked it as ready for committer. I hope Fujii san or
another committer will commit this, refining English expression if
necessary.
Since it was just a matter of editing, I went through the patch and
corrected various minor
Abhijit Menon-Sen a...@2ndquadrant.com writes:
I had another look now, and I think removing the comment is fine. It
actually made no sense to me in context, so I went digging a little.
...
Note that the first argument was actually NULL, so the comment made
sense when it was written. But the
At 2014-06-27 00:51:02 +0200, p...@2ndquadrant.com wrote:
Also based on Alvaro's comment, I replaced the scanf parsing code with
strtoul(l) function.
As far as I can tell (from the thread and a quick look at the patch),
your latest version of the patch addresses all the review comments.
On 2014-06-29 19:44:21 +0530, Abhijit Menon-Sen wrote:
At 2014-06-27 00:51:02 +0200, p...@2ndquadrant.com wrote:
Also based on Alvaro's comment, I replaced the scanf parsing code with
strtoul(l) function.
As far as I can tell (from the thread and a quick look at the patch),
your latest
So, what's the status of this patch?
There's been quite a lot of discussion (though only about the approach;
no formal code/usage review has yet been posted), but as far as I can
tell, it just tapered off without any particular consensus.
-- Abhijit
--
Sent via pgsql-hackers mailing list
Dave McGuire mcgu...@neurotica.com writes:
On 06/25/2014 01:57 PM, Tom Lane wrote:
Is there anyone in the NetBSD/VAX community who would be willing to
host a PG buildfarm member?
I could put together a simh-based machine (i.e., fast) on a vm, if
nobody else has stepped up for this.
No
Hi,
As shown by the CLOBBER_CACHE_ALWAYS animal test_decoding's tests fail
if they take very long. The failures aren't bugs, but diffs like:
BEGIN
+ COMMIT
+ BEGIN
table public.tr_sub: INSERT: id[integer]:1 path[text]:'1-top-#1'
The added transaction is an analyze started by autovacuum.
Abhijit Menon-Sen a...@2ndquadrant.com writes:
So, what's the status of this patch?
There's been quite a lot of discussion (though only about the approach;
no formal code/usage review has yet been posted), but as far as I can
tell, it just tapered off without any particular consensus.
AFAICT,
Andres Freund and...@2ndquadrant.com writes:
Solution I)
Change ReorderBufferCommit() to not call the begin()/commit() callbacks
if no change() callback has been called. Technically that's trivial, but
I don't think that'd end up being a better behaviour.
Solution II)
Disable
On 2014-06-29 10:36:22 -0400, Tom Lane wrote:
Andres Freund and...@2ndquadrant.com writes:
Solution I)
Change ReorderBufferCommit() to not call the begin()/commit() callbacks
if no change() callback has been called. Technically that's trivial, but
I don't think that'd end up being a
On 2014-06-29 10:24:22 -0400, Tom Lane wrote:
Dave McGuire mcgu...@neurotica.com writes:
On 06/25/2014 01:57 PM, Tom Lane wrote:
Is there anyone in the NetBSD/VAX community who would be willing to
host a PG buildfarm member?
I could put together a simh-based machine (i.e., fast) on a
Andres Freund and...@2ndquadrant.com writes:
Maybe I'm just not playful enough, but keeping a platform alive so we
can run postgres in simulator seems a bit, well, pointless.
True --- an actual machine would be more useful, even if slower. Some
of the existing buildfarm critters are pretty
Andres Freund and...@2ndquadrant.com writes:
On 2014-06-29 10:36:22 -0400, Tom Lane wrote:
You mean disable autovac only in the contrib/test_decoding check run,
right? That's probably OK since it's tested in the main regression
runs.
Actually I'd not even though of that, but just of
On 2014-06-29 11:08:39 -0400, Tom Lane wrote:
Andres Freund and...@2ndquadrant.com writes:
On 2014-06-29 10:36:22 -0400, Tom Lane wrote:
You mean disable autovac only in the contrib/test_decoding check run,
right? That's probably OK since it's tested in the main regression
runs.
Andres Freund and...@2ndquadrant.com writes:
Hm? I think we're misunderstanding each other - I was thinking of tacking
ALTER TABLE .. SET (AUTOVACUUM_ENABLED = false) to the tables created in
test_decoding/sql/, not to something outside.
Ah, got it. Yeah, seems like an OK workaround.
[ trimming the cc list since this isn't VAX-specific ]
I wrote:
Yeah. We'd need to look at the relevant part of config.log to be sure,
but my guess is that configure tried that switch, failed to recognize
that it wasn't actually working, and seized on it as what to use.
Maybe the
I have reviewed this patch, and think we should do what the patch
is trying to do, but I don't think the submitted patch would
actually work. I have attached a suggested patch which I think
would work. Gurjeet, could you take a look at it?
My comments on prior discussion embedded below.
I wrote:
BTW, it sure looks like the part of ACX_PTHREAD beginning with
# Various other checks:
if test x$acx_pthread_ok = xyes; then
(lines 163..210 in HEAD's acx_pthread.m4) is dead code.
On closer inspection, this has been broken since commit
On 2014-06-29 12:20:02 -0400, Tom Lane wrote:
I wrote:
BTW, it sure looks like the part of ACX_PTHREAD beginning with
# Various other checks:
if test x$acx_pthread_ok = xyes; then
(lines 163..210 in HEAD's acx_pthread.m4) is dead code.
On closer inspection, this has been
Kevin Grittner kgri...@ymail.com writes:
Gurjeet Singh gurj...@singh.im wrote:
Besides, there's already a throttle built in using the
PGSTAT_STAT_INTERVAL limit.
This is a key point; neither the original patch nor my proposed
alternative bypasses that throttling.
That's a fair point that
Robert Haas robertmh...@gmail.com wrote:
On Wed, Jun 25, 2014 at 11:40 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Fujii Masao masao.fu...@gmail.com writes:
Why is IIT timeout turned on only when send_ready_for_query is true?
I was thinking it should be turned on every time a message is
Kevin Grittner kgri...@ymail.com writes:
I propose to push this as it stands except for the postgres_fdw
part. The default is easy enough to change if we reach consensus,
and expanding the scope can be a new patch in a new CF.
Objections?
There's been enough noise about the external
Hi Vaishnavi.
In addition to Jaime's comments about the functionality, here are are
some comments about the code.
Well, they were supposed to be comments about the code, but it turns out
I have comments about the feature as well. We need to figure out what to
do about the database and user
Dave McGuire mcgu...@neurotica.com writes:
On 06/29/2014 10:54 AM, Andres Freund wrote:
Maybe I'm just not playful enough, but keeping a platform alive so we
can run postgres in simulator seems a bit, well, pointless.
On the in a simulator matter: It's important to keep in mind that
there
On Sun, Jun 29, 2014 at 12:32 PM, Kevin Grittner kgri...@ymail.com wrote:
Moreover, there would be no way to implement a timeout like that without
adding a gettimeofday() call after every packet receipt, which is overhead
we do not need and cannot afford. I don't think this feature should
Joshua Yanovski pythones...@gmail.com:
Proof of concept initial patch for enabling index only scans for
partial indices even when an attribute is not in the target list, as
long as it is only used in restriction clauses that can be proved by
the index predicate. This also works for index
On June 29, 2014 9:01:27 PM CEST, Dave McGuire mcgu...@neurotica.com wrote:
On 06/29/2014 02:58 PM, Patrick Finnegan wrote:
Last I checked, NetBSD doesn't support any sort of multiprocessor
VAX.
Multiprocessor VAXes exist, but you're stuck with either Ultrix or
VMS
on them.
Hi Pat, it's
Vik Fearing vik.fear...@dalibo.com writes:
On 06/21/2014 10:11 PM, Pavel Stehule wrote:
Is any reason or is acceptable incompatible change CONNECTION_LIMIT
instead CONNECTION LIMIT? Is decreasing parser size about 1% good enough
for breaking compatibility?
How is compatibility broken? The
Dave McGuire mcgu...@neurotica.com writes:
On 06/29/2014 10:24 AM, Tom Lane wrote:
Hey, right up the river from here!
Come on up and hack! There's always something neat going on around
here. Ever run a PDP-11? B-)
There were so many PDP-11s around CMU when I was an undergrad that
I
Robert, Dean,
* Dean Rasheed (dean.a.rash...@gmail.com) wrote:
On 26 June 2014 18:04, Robert Haas robertmh...@gmail.com wrote:
ALTER TABLE t1 SET POLICY p1 ON SELECT TO t1_p1_sel_quals;
GRANT SELECT ON TABLE t1 TO role1 USING p1;
As I see it, the downside of this is that it gets a lot
Robert Haas robertmh...@gmail.com writes:
On Sun, Jun 29, 2014 at 12:32 PM, Kevin Grittner kgri...@ymail.com wrote:
I propose to push this as it stands except for the postgres_fdw
part. The default is easy enough to change if we reach consensus,
and expanding the scope can be a new patch in a
2014-06-29 15:24 GMT+02:00 Abhijit Menon-Sen a...@2ndquadrant.com:
At 2014-06-29 20:35:04 +0900, maumau...@gmail.com wrote:
Thanks, I marked it as ready for committer. I hope Fujii san or
another committer will commit this, refining English expression if
necessary.
Since it was just a
On 29 June 2014 10:01, Thomas Munro mu...@ip9.org wrote:
Would anyone who is interested in a SKIP LOCKED feature and
attending the CHAR(14)/PGDay UK conference next week be
interested in a birds-of-a-feather discussion?
Sounds like a plan. I'll check my schedule.
--
Simon Riggs
Abhijit Menon-Sen a...@2ndquadrant.com writes:
3) This is such a simple change with no new infrastructure code
(PLyObject_ToComposite already exists). Can you think of a reason
why this wasn't done until now? Was it a simple miss or purposefully
excluded?
This is not an authoritative answer:
On 2014-06-29 15:48:15 -0400, Tom Lane wrote:
Robert Haas robertmh...@gmail.com writes:
On Sun, Jun 29, 2014 at 12:32 PM, Kevin Grittner kgri...@ymail.com wrote:
I propose to push this as it stands except for the postgres_fdw
part. The default is easy enough to change if we reach
Andres Freund and...@2ndquadrant.com writes:
On 2014-06-29 15:48:15 -0400, Tom Lane wrote:
Robert Haas robertmh...@gmail.com writes:
Yeah, I think someone should do some analysis of whether this is
adding gettimeofday() calls, and how many, and what the performance
implications are.
I
On 2014-06-29 12:53:56 -0400, Tom Lane wrote:
I do not think it is: specifically, the notion
that we will call ereport(FATAL) directly from a signal handler
does not fill me with warm fuzzies.
Aren't we already pretty much doing that for
SIGTERM/pg_terminate_backend() and recovery conflict
On Sat, Jun 28, 2014 at 07:35:10AM -0700, Kevin Grittner wrote:
David Fetter da...@fetter.org wrote:
On Sat, Jun 21, 2014 at 11:06:26AM -0700, Kevin Grittner wrote:
Here is v2.
I've taken the liberty of making an extension that uses this.
Preliminary tests indicate a 10x performance
On 2014-06-29 17:28:06 -0400, Tom Lane wrote:
Andres Freund and...@2ndquadrant.com writes:
On 2014-06-29 15:48:15 -0400, Tom Lane wrote:
Robert Haas robertmh...@gmail.com writes:
Yeah, I think someone should do some analysis of whether this is
adding gettimeofday() calls, and how many,
Andres Freund and...@2ndquadrant.com writes:
On 2014-06-29 12:53:56 -0400, Tom Lane wrote:
I do not think it is: specifically, the notion
that we will call ereport(FATAL) directly from a signal handler
does not fill me with warm fuzzies.
Aren't we already pretty much doing that for
Hi,
In workloads with mostly simple statements, memory allocations are the
primary bottleneck. Some of the allocations are unlikely to be avoidable
without major work, but others seem superflous in many scenarios.
Why aren't we delaying allocations in e.g. AtStart_Inval(),
On 26.6.2014 23:48, Tomas Vondra wrote:
On 26.6.2014 20:43, Tomas Vondra wrote:
Attached is v2 of the patch, with some cleanups / minor improvements:
* there's a single FIXME, related to counting tuples in the
Meh, I couldn't resist resolving this FIXME, so attached is v3 of the
patch.
On 2014-06-29 19:13:55 -0400, Tom Lane wrote:
Andres Freund and...@2ndquadrant.com writes:
On 2014-06-29 12:53:56 -0400, Tom Lane wrote:
I do not think it is: specifically, the notion
that we will call ereport(FATAL) directly from a signal handler
does not fill me with warm fuzzies.
Andres Freund and...@2ndquadrant.com writes:
Note that we're *inside* recv() here.
Well, actually, the recv() has probably failed with an EINTR at this
point, or else it will when/if control returns.
Uh, no, that would pretty much destroy the point of trying to report
an error message at all.
Andres Freund and...@2ndquadrant.com writes:
Why aren't we delaying allocations in e.g. AtStart_Inval(),
AfterTriggerBeginXact() to when the data structures are acutally used?
Aren't we? Neither of those would be doing much work certainly.
regards, tom lane
--
Sent
On 2014-06-29 19:52:23 -0400, Tom Lane wrote:
Andres Freund and...@2ndquadrant.com writes:
Why aren't we delaying allocations in e.g. AtStart_Inval(),
AfterTriggerBeginXact() to when the data structures are acutally used?
Aren't we? Neither of those would be doing much work certainly.
Andres Freund and...@2ndquadrant.com writes:
On 2014-06-29 19:52:23 -0400, Tom Lane wrote:
Andres Freund and...@2ndquadrant.com writes:
Why aren't we delaying allocations in e.g. AtStart_Inval(),
AfterTriggerBeginXact() to when the data structures are acutally used?
Aren't we? Neither of
On 2014-06-29 19:51:05 -0400, Tom Lane wrote:
Andres Freund and...@2ndquadrant.com writes:
Note that we're *inside* recv() here.
Well, actually, the recv() has probably failed with an EINTR at this
point, or else it will when/if control returns.
Well, the point is that we'll be reentering
On 2014-06-29 21:12:49 -0400, Tom Lane wrote:
Andres Freund and...@2ndquadrant.com writes:
On 2014-06-29 19:52:23 -0400, Tom Lane wrote:
Andres Freund and...@2ndquadrant.com writes:
Why aren't we delaying allocations in e.g. AtStart_Inval(),
AfterTriggerBeginXact() to when the data
On Sun, Jun 29, 2014 at 9:25 PM, Andres Freund and...@2ndquadrant.com wrote:
On 2014-06-29 11:11:14 +0100, Thomas Munro wrote:
On 29 June 2014 10:55, Andres Freund and...@2ndquadrant.com wrote:
So, I'd looked at it with an eye towards committing it and found some
more things. I've now
*
Mmm. This patch is found that useless, from the first.
Thanks for the patch! But when I read the source code of pg_resetxlog,
I found that it has already reset the backup locations. Please see
RewriteControlFile() which does that. So I wonder if we need nothing
at least in HEAD for the
On Mon, Jun 30, 2014 at 12:49 PM, Kyotaro HORIGUCHI
horiguchi.kyot...@lab.ntt.co.jp wrote:
Mmm. This patch is found that useless, from the first.
Thanks for the patch! But when I read the source code of pg_resetxlog,
I found that it has already reset the backup locations. Please see
Hi.
We're two weeks into the CommitFest now, and things are moving along
quite nicely.
Fourteen patches have been committed, and twelve more are marked ready
for committer. But most importantly, many patches have been reviewed,
and only nine patches still lack a reviewer (and most of those have
At 2014-06-29 21:55:24 +0300, e...@hasegeli.com wrote:
I will update the patch as returned with feedback
I don't think it's fair to mark this as returned with feedback without a
more detailed review (I think of returned with feedback as providing a
concrete direction to follow). I've set it
Hello,
misunderstanding, but all these patches are totally useless.
So we should mark this patch as Rejected Patches?
I think so.
regards,
--
Kyotaro Horiguchi
NTT Open Source Software Center
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your
At 2014-06-30 13:55:59 +0900, horiguchi.kyot...@lab.ntt.co.jp wrote:
So we should mark this patch as Rejected Patches?
I think so.
Done.
-- Abhijit
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
On 13 June 2014 13:01, Abhijit Menon-Sen Wrote
I've changed this to use %zu at Álvaro's suggestion. I'll post an
updated patch after I've finished some (unrelated) refactoring.
I have started reviewing the patch..
1. Patch applied to git head cleanly.
2. Compiled in Linux -- Some warnings
On Sun, Jun 29, 2014 at 2:54 PM, Andres Freund and...@2ndquadrant.com
wrote:
On 2014-06-29 11:53:28 +0530, Amit Kapila wrote:
On Sat, Jun 28, 2014 at 1:48 PM, Andres Freund and...@2ndquadrant.com
I think it is better to have some discussion about it. Apart from this,
today I noticed atomic
71 matches
Mail list logo
