On Wed, Jun 18, 2014 at 10:00 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Amit Kapila amit.kapil...@gmail.com writes:
Won't it be possible if we convert malloc calls in backend code to
go through wrapper, we already have some precedents of same like
guc_malloc, pg_malloc?
We do not have
There is, IMO, a significant oversight with the include_dir feature.
If a distributor wants to enable it by default at initdb time, they
can't just turn it on in postgresql.conf.sample, because initdb will die
when the postgres backend refuses to start because the configdir is missing.
Yet the
On Tue, Jun 17, 2014 at 12:30 AM, Abhijit Menon-Sen a...@2ndquadrant.com
wrote:
(Cc: to pgsql-bugs dropped.)
At 2014-03-17 18:24:55 +1100, kommi.harib...@gmail.com wrote:
*** a/doc/src/sgml/xfunc.sgml
--- b/doc/src/sgml/xfunc.sgml
***
*** 153,159 SELECT clean_emp();
---
On 06/18/2014 03:30 PM, Craig Ringer wrote:
There is, IMO, a significant oversight with the include_dir feature.
If a distributor wants to enable it by default at initdb time, they
can't just turn it on in postgresql.conf.sample, because initdb will die
when the postgres backend refuses to
I wanted to check the patch last time and found a bug effecting
MVC vs MVC part of the join selectivity. Fixed version attached.
Emre Hasegeli e...@hasegeli.com:
Comparing the lists with each other slows down the function when
statistics set to higher values. To avoid this problem I only use
On 06/17/2014 09:16 PM, Andres Freund wrote:
On 2014-06-17 12:14:00 -0400, Robert Haas wrote:
On Tue, Jun 17, 2014 at 12:04 PM, Andres Freund and...@2ndquadrant.com wrote:
Well, I'm not the guy who does things with geometric data, but I don't
want to ignore the significant percentage of our
Thanks, I've marked this ready for committer.
-- Abhijit
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Hi all
I posted about a possible packaging issue with RHEL 6 PGDG packages for
9.4beta on pgsql-yum-pkg, but things are pretty quiet over there (a
prior mail asking about what happened with moving to git hasn't had a
response).
Given that time is a concern with 9.4, I thought I'd raise it here.
From: Rajeev rastogi rajeev.rast...@huawei.com
Please find the attached patch with only documentation change.
I marked this as ready for committer. The patch is good because it matches
the description in the following page:
On 2014-06-18 12:18:26 +0300, Heikki Linnakangas wrote:
On 06/17/2014 09:16 PM, Andres Freund wrote:
Well, it might be doable to correlate them along one axis, but along
both? That's more complicated... And even alongside one axis you
already get into problems if your geometries are
On 2014-06-17 16:48:07 -0700, Greg Stark wrote:
On Tue, Jun 17, 2014 at 11:16 AM, Andres Freund and...@2ndquadrant.com
wrote:
Well, it might be doable to correlate them along one axis, but along
both? That's more complicated... And even alongside one axis you
already get into problems if
From: Michael Paquier michael.paqu...@gmail.com
When doing some work on Windows, I noticed that the mkvc specs in
src/tools/msvc use wsock32.lib, which is as far as I understand an
old, obsolete version of the Windows socket library. Wouldn't it make
sense to update the specs to build only with
* Peter Geoghegan (p...@heroku.com) wrote:
On Tue, Jun 17, 2014 at 5:11 PM, Robert Haas robertmh...@gmail.com wrote:
Now, we could. We could come up with an extensible syntax, like this:
CHECK relation [ USING { checktype [ '(' arg [, ...] '}' [, ...] ];
That's what I had in mind. Using
On 06/18/2014 01:46 PM, Andres Freund wrote:
On 2014-06-18 12:18:26 +0300, Heikki Linnakangas wrote:
The main problem with using it for geometric types is that you can't easily
CLUSTER the table to make the minmax index effective again. But there are
ways around that.
Which are? Sure you can
* Matheus de Oliveira (matioli.math...@gmail.com) wrote:
Hi Hackers,
Having read only the subject- +1 from me on the idea. Maybe +1000.
I was facing a situation were we wanted to set temp_tablespaces to a
tablespace on a ephemeral disk (yes, it is AWS ephemeral disk), and I know
many users
* Andrew Dunstan (and...@dunslane.net) wrote:
I think I'd rather just say for many data types or something along
those lines, rather than imply that there is some obvious rule that
users should be able to intuit.
Perhaps with a link to where the informaiton about which exist is
available..?
On Tue, Jun 17, 2014 at 2:16 PM, Andres Freund and...@2ndquadrant.com wrote:
But I'm not trying to say that we absolutely have to support that kind
of thing; what I am trying to say is that there should be a README or
a mailing list post or some such that says: We thought about how
generic to
On Wed, Jun 18, 2014 at 7:47 PM, MauMau maumau...@gmail.com wrote:
From: Rajeev rastogi rajeev.rast...@huawei.com
Please find the attached patch with only documentation change.
I marked this as ready for committer. The patch is good because it matches
the description in the following page:
Hello ,
I have a few preliminary comments about your patch
Thank you for review comments.
the patch creates src/common/lz4/.travis.yml, which it shouldn't.
Agree. I will remove it.
Shouldn't this use palloc?
palloc() is disallowed in critical sections and we are already in CS while
executing
On 2014-06-18 18:10:34 +0530, Rahila Syed wrote:
Hello ,
I have a few preliminary comments about your patch
Thank you for review comments.
the patch creates src/common/lz4/.travis.yml, which it shouldn't.
Agree. I will remove it.
Shouldn't this use palloc?
palloc() is disallowed in
At 2014-06-18 18:10:34 +0530, rahilasye...@gmail.com wrote:
palloc() is disallowed in critical sections and we are already in CS
while executing this code. So we use malloc().
Are these allocations actually inside a critical section? It seems to me
that the critical section starts further
At 2014-06-18 18:25:34 +0530, a...@2ndquadrant.com wrote:
Are these allocations actually inside a critical section? It seems to me
that the critical section starts further down, but perhaps I am missing
something.
OK, I was missing that XLogInsert() itself can be called from inside a
critical
On Wed, Jun 18, 2014 at 6:25 PM, Abhijit Menon-Sen a...@2ndquadrant.com
wrote:
At 2014-06-18 18:10:34 +0530, rahilasye...@gmail.com wrote:
palloc() is disallowed in critical sections and we are already in CS
while executing this code. So we use malloc().
Are these allocations actually
On Tue, Jun 17, 2014 at 9:00 PM, Craig Ringer cr...@2ndquadrant.com wrote:
On 06/18/2014 12:41 AM, Robert Haas wrote:
On Mon, Jun 16, 2014 at 12:58 AM, Craig Ringer cr...@2ndquadrant.com wrote:
On 05/30/2014 11:14 PM, Heikki Linnakangas wrote:
Yeah. To recap, the failure mode is that if the
On Tue, Jun 17, 2014 at 5:40 PM, Michael Paquier
michael.paqu...@gmail.com wrote:
On Wed, Jun 18, 2014 at 1:40 AM, Robert Haas robertmh...@gmail.com wrote:
On Mon, Jun 2, 2014 at 8:55 AM, Michael Paquier
michael.paqu...@gmail.com wrote:
I'm not sure if this is reasonably possible, but one
Stephen Frost sfr...@snowman.net writes:
* Andrew Dunstan (and...@dunslane.net) wrote:
I think I'd rather just say for many data types or something along
those lines, rather than imply that there is some obvious rule that
users should be able to intuit.
Perhaps with a link to where the
On Tue, Jun 17, 2014 at 9:45 PM, Brightwell, Adam
adam.brightw...@crunchydatasolutions.com wrote:
I absolutely appreciate all of the feedback that has been provided. It has
been educational. To your point above, I started putting together a wiki
page, as Stephen has spoken to, that is meant
On 06/18/2014 09:12 PM, Robert Haas wrote:
No. Otherwise, one of those bits could get changed after a backend
takes a snapshot and before it finishes using it - so that the
transaction snapshot is in effect changing underneath it. You could
avoid that by memorizing the contents of CLOG when
Hi,
In September 2013, there was patch sent by Stas Kelvich (
http://www.postgresql.org/message-id/9e07e159-e405-41e2-9889-a04f534fc...@gmail.com)
that adds indexable kNN searches to cube contrib module.
What is needed so that it could get committed?
Regards,
depesz
Craig Ringer cr...@2ndquadrant.com writes:
I posted about a possible packaging issue with RHEL 6 PGDG packages for
9.4beta on pgsql-yum-pkg, but things are pretty quiet over there (a
prior mail asking about what happened with moving to git hasn't had a
response).
From: Fujii Masao masao.fu...@gmail.com
On Wed, Jun 18, 2014 at 7:47 PM, MauMau maumau...@gmail.com wrote:
I marked this as ready for committer. The patch is good because it
matches
the description in the following page:
http://www.postgresql.org/docs/devel/static/manage-ag-templatedbs.html
On 06/18/2014 09:34 AM, Tom Lane wrote:
Craig Ringer cr...@2ndquadrant.com writes:
I posted about a possible packaging issue with RHEL 6 PGDG packages for
9.4beta on pgsql-yum-pkg, but things are pretty quiet over there (a
prior mail asking about what happened with moving to git hasn't had a
At 2014-06-18 15:33:37 +0200, dep...@gmail.com wrote:
Hi,
In September 2013, there was patch sent by Stas Kelvich (
http://www.postgresql.org/message-id/9e07e159-e405-41e2-9889-a04f534fc...@gmail.com)
that adds indexable kNN searches to cube contrib module.
What is needed so that it
On Tue, Jun 17, 2014 at 10:06 PM, Stephen Frost sfr...@snowman.net wrote:
* Robert Haas (robertmh...@gmail.com) wrote:
On Fri, Jun 13, 2014 at 3:11 AM, Dean Rasheed dean.a.rash...@gmail.com
wrote:
Yeah, I was thinking something like this could work, but I would go
further. Suppose you had
--On 13. Juni 2014 13:46:38 -0400 Tom Lane t...@sss.pgh.pa.us wrote:
Imagine if `BeginForeignScan` set up a remote cursor and
`IterateForeignScan` just fetched _one tuple at a time_ (unlike the
current behavior where they are fetched in batches). The tuple would be
passed to
On Wed, Jun 18, 2014 at 9:00 AM, Stephen Frost sfr...@snowman.net wrote:
I have took some small time to make a PoC just to see if that is doable.
And so I did a new syntax like:
CREATE TABLESPACE spcname [TEMP | TEMPORARY] LOCATION ...
So, if TEMP or TEMPORARY is present, I mark a
* Tom Lane (t...@sss.pgh.pa.us) wrote:
Stephen Frost sfr...@snowman.net writes:
* Andrew Dunstan (and...@dunslane.net) wrote:
I think I'd rather just say for many data types or something along
those lines, rather than imply that there is some obvious rule that
users should be able to
Andrew Dunstan wrote
On 06/17/2014 07:25 PM, Andres Freund wrote:
On 2014-06-17 19:22:07 -0400, Tom Lane wrote:
Andrew Dunstan lt;
andrew@
gt; writes:
I went to have a look at documenting the jsonb comparison operators,
and
found that the docs on comparison operators contain this:
David G Johnston david.g.johns...@gmail.com writes:
Andrew Dunstan wrote
I think I'd rather just say for many data types or something along
those lines, rather than imply that there is some obvious rule that
users should be able to intuit.
Ideal world for me: we'd list the data types that
Hi,
On Wed, 2014-06-18 at 09:41 -0400, Andrew Dunstan wrote:
The only thing I can think of offhand that would require it is
pgbouncer.
Yeah. Recent pgbouncer versions require libevent 2.0+, and RHEL 6 has
1.4.
Regards,
--
Devrim GÜNDÜZ
Principal Systems Engineer @ EnterpriseDB:
* Robert Haas (robertmh...@gmail.com) wrote:
On Tue, Jun 17, 2014 at 10:06 PM, Stephen Frost sfr...@snowman.net wrote:
I had taken it to be a single privilege, but you're right, it could be
done for each of those.. I really don't think we have the bits for more
than one case here though
On Tue, Jun 17, 2014 at 10:25 PM, Stephen Frost sfr...@snowman.net wrote:
Yeah, if we have to ask an external security module a question for
each row, there's little hope of any real optimization. However, I
think there will be a significant number of cases where people will
want filtering
On 06/18/2014 06:34 AM, Tom Lane wrote:
Craig Ringer cr...@2ndquadrant.com writes:
I posted about a possible packaging issue with RHEL 6 PGDG packages for
9.4beta on pgsql-yum-pkg, but things are pretty quiet over there (a
prior mail asking about what happened with moving to git hasn't had a
On Wed, Jun 18, 2014 at 10:40 AM, Stephen Frost sfr...@snowman.net wrote:
* Robert Haas (robertmh...@gmail.com) wrote:
On Tue, Jun 17, 2014 at 10:06 PM, Stephen Frost sfr...@snowman.net wrote:
I had taken it to be a single privilege, but you're right, it could be
done for each of those.. I
On Tue, Jun 17, 2014 at 1:55 PM, Andres Freund and...@2ndquadrant.com wrote:
But the concern is more whether 1 byte can actually be written
without also writing neighbouring values. I.e. there's hardware out
there that'll implement a 1byte store as reading 4 bytes, changing one
of the bytes in
On Tue, Jun 17, 2014 at 10:23 AM, Dennis Butterstein soullinu...@web.de wrote:
Hi Marti, thank you for your quick reply. I tried the proposed tweaks and
see some differences regarding the measurements. It seems as if the overall
query performance dropped a little what I think the disabled turbo
I have released version 4.13 of the PostgreSQL Buildfarm client.
This can be downloaded from
http://www.pgbuildfarm.org/downloads/releases/build-farm-4_13.tgz
Changes in this release (from the git log):
fcc182b Don't run TestCollateLinuxUTF8 on unsupported branches.
273af50 Don't run
On Tue, Jun 17, 2014 at 6:54 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Alvaro Herrera alvhe...@2ndquadrant.com writes:
Robert Haas wrote:
On Mon, Jun 16, 2014 at 2:36 AM, Abhijit Menon-Sen a...@2ndquadrant.com
wrote:
P.S. If you tag your reviews with [REVIEW] in the Subject, it'll be
Hi,
now that we have vacuumdb --all --analyze-in-stages in 9.4, wouldn't
it make sense to get rid of the analyze_new_cluster.sh file which
pg_upgrade writes? The net content is a single line which could as
well be printed by pg_upgrade itself. Instead of an lengthy
explanation how to invoke that
On Wed, Jun 18, 2014 at 4:50 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Steven Siebert smsi...@gmail.com writes:
Attached is a proposed patch for BUG #10680.
It's a simple fix to the problem of the ldapbindpasswd leaking in
clear text to the postgresql log. The patch simply removes the raw
On 2014-06-18 11:15:15 -0400, Robert Haas wrote:
On Tue, Jun 17, 2014 at 1:55 PM, Andres Freund and...@2ndquadrant.com wrote:
What happens is that gcc will do a syscall triggering the kernel to turn
of scheduling; perform the math and store the result; turn scheduling on
again. That way
* Fabrízio de Royes Mello (fabriziome...@gmail.com) wrote:
On Wed, Jun 18, 2014 at 9:00 AM, Stephen Frost sfr...@snowman.net wrote:
Not sure about that specific syntax (don't we have SET options now?) but
I do like the general idea.
Maybe something like that:
CREATE TABLESPACE spcname
On Tue, Jun 17, 2014 at 12:50 PM, Andres Freund and...@2ndquadrant.com wrote:
I can clearly understand the utility of being able to reset the system
ID to a new, randomly-generated system ID - but giving the user the
ability to set a particular value of their own choosing seems like a
On Tue, Jun 17, 2014 at 04:07:55PM -0400, Robert Haas wrote:
On Sat, Jun 14, 2014 at 7:56 PM, Kevin Grittner kgri...@ymail.com wrote:
I looked at the standard, and initially tried to implement the
standard syntax for this; however, it appeared that the reasons
given for not using standard
On 2014-06-18 12:36:13 -0400, Robert Haas wrote:
I actually don't think any of the discussions I was involved in had the
externally visible version of replication identifiers limited to 16bits?
If you are referring to my patch, 16bits was just the width of the
*internal* name that should
Christoph Berg christoph.b...@credativ.de writes:
now that we have vacuumdb --all --analyze-in-stages in 9.4, wouldn't
it make sense to get rid of the analyze_new_cluster.sh file which
pg_upgrade writes? The net content is a single line which could as
well be printed by pg_upgrade itself.
On 2014-06-18 12:36:13 -0400, Robert Haas wrote:
On Tue, Jun 17, 2014 at 12:50 PM, Andres Freund and...@2ndquadrant.com
wrote:
I can clearly understand the utility of being able to reset the system
ID to a new, randomly-generated system ID - but giving the user the
ability to set a
On 2014-06-18 12:51:43 -0400, Tom Lane wrote:
Another angle is that some folks might have tried to automate things
even more, with a wrapper script that starts up the new postmaster
and runs analyze_new_cluster.sh all by itself. I guess they could
make the wrapper do vacuumdb --all
Stephen Frost sfr...@snowman.net writes:
Yes. I'd definitely like to see an ALTER TABLESPACE option, with an
ERROR that lists out all of the non-temporary objects which are found
(and lists any other databases which have objects in those
tablespaces..). That would allow administrators who
On 2014-06-18 18:54:05 +0200, Andres Freund wrote:
On 2014-06-18 12:36:13 -0400, Robert Haas wrote:
Sure, but that only requires being able to reset the ID randomly, not
to a particular value.
I can definitely see a point in a version of the option that generates
the id randomly.
That's
Andres Freund and...@2ndquadrant.com writes:
On 2014-06-18 12:51:43 -0400, Tom Lane wrote:
Another angle is that some folks might have tried to automate things
even more, with a wrapper script that starts up the new postmaster
and runs analyze_new_cluster.sh all by itself. I guess they could
On Wed, Jun 18, 2014 at 12:54 PM, Andres Freund and...@2ndquadrant.com wrote:
Well, I think it *does* make pg_resetxlog more dangerous; see previous
discussion of pg_computemaxlsn.
Wasn't the thing around pg_computemaxlsn that there's actually no case
where it could be used safely? And that
On 2014-06-18 13:24:14 -0400, Tom Lane wrote:
Andres Freund and...@2ndquadrant.com writes:
On 2014-06-18 12:51:43 -0400, Tom Lane wrote:
Another angle is that some folks might have tried to automate things
even more, with a wrapper script that starts up the new postmaster
and runs
On 18/06/14 19:26, Robert Haas wrote:
On Wed, Jun 18, 2014 at 12:54 PM, Andres Freund and...@2ndquadrant.com wrote:
I don't see how the proposed ability makes it more dangerous. It
*already* has the ability to reset the timelineid. That's the case where
users are much more likely to think about
On 2014-06-18 13:26:37 -0400, Robert Haas wrote:
My vote is to hold off on this until we've talked about replication
identifiers and other related topics in more depth.
I really don't understand this. We're *NOT* proposing this patch as an
underhanded way of preempting the discussion of
On 06/13/2014 05:31 PM, Petr Jelinek wrote:
Hello,
attached is a simple patch which makes it possible to change the system
identifier of the cluster in pg_control. This is useful for
individualization of the instance that is started on top of data
directory produced by pg_basebackup -
Josh Berkus wrote:
On 06/13/2014 05:31 PM, Petr Jelinek wrote:
Hello,
attached is a simple patch which makes it possible to change the system
identifier of the cluster in pg_control. This is useful for
individualization of the instance that is started on top of data
directory
On 2014-06-18 10:44:56 -0700, Josh Berkus wrote:
On 06/13/2014 05:31 PM, Petr Jelinek wrote:
Hello,
attached is a simple patch which makes it possible to change the system
identifier of the cluster in pg_control. This is useful for
individualization of the instance that is started on
At 2014-06-18 10:44:56 -0700, j...@agliodbs.com wrote:
I'm unclear on why we would overload pg_resetxlog for this.
Because pg_resetxlog already does something very similar, so the patch
is small. If it were independent, it would have to copy quite some code
from pg_resetxlog.
Wouldn't it be
Well, the initdb issue looks to be resolved. Actually, after making the
changes as suggested by Kyotaro Horiguchi, I copied only initdb binary to
my platform and didn't copy all of them. Hence, the dependencies were still
not resolved and was getting the error. However, now the database server is
Andres Freund and...@2ndquadrant.com writes:
On 2014-06-18 13:24:14 -0400, Tom Lane wrote:
Andres Freund and...@2ndquadrant.com writes:
On 2014-06-18 12:51:43 -0400, Tom Lane wrote:
Another angle is that some folks might have tried to automate things
even more, with a wrapper script that
On 2014-06-18 13:54:16 -0400, Tom Lane wrote:
Andres Freund and...@2ndquadrant.com writes:
On 2014-06-18 13:24:14 -0400, Tom Lane wrote:
Andres Freund and...@2ndquadrant.com writes:
On 2014-06-18 12:51:43 -0400, Tom Lane wrote:
Another angle is that some folks might have tried to automate
On 06/18/2014 10:48 AM, Abhijit Menon-Sen wrote:
At 2014-06-18 10:44:56 -0700, j...@agliodbs.com wrote:
I'm unclear on why we would overload pg_resetxlog for this.
Because pg_resetxlog already does something very similar, so the patch
is small. If it were independent, it would have to copy
On 2014-06-18 10:59:59 -0700, Josh Berkus wrote:
On 06/18/2014 10:48 AM, Abhijit Menon-Sen wrote:
At 2014-06-18 10:44:56 -0700, j...@agliodbs.com wrote:
I'm unclear on why we would overload pg_resetxlog for this.
Because pg_resetxlog already does something very similar, so the patch
On Wed, Jun 18, 2014 at 1:59 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Stephen Frost sfr...@snowman.net writes:
Yes. I'd definitely like to see an ALTER TABLESPACE option, with an
ERROR that lists out all of the non-temporary objects which are found
(and lists any other databases which have
On 06/18/2014 11:03 AM, Andres Freund wrote:
Well, all those actually do write to the xlog (to write a new
checkpoint, containing the updated control file). Since pg_resetxlog has
done all this pretty much since forever renaming it now seems to be a
big hassle for users for pretty much no
* Robert Haas (robertmh...@gmail.com) wrote:
On Tue, Jun 17, 2014 at 10:25 PM, Stephen Frost sfr...@snowman.net wrote:
I agree that we want to support that, if we can do so reasonably. What
I was trying to get at is simply this- don't we provide that already
with the leakproof attribute
* Tom Lane (t...@sss.pgh.pa.us) wrote:
Stephen Frost sfr...@snowman.net writes:
Yes. I'd definitely like to see an ALTER TABLESPACE option, with an
ERROR that lists out all of the non-temporary objects which are found
(and lists any other databases which have objects in those
On Tue, Jun 17, 2014 at 8:46 PM, Bruce Momjian br...@momjian.us wrote:
On Tue, Jun 17, 2014 at 07:12:16PM -0400, Tom Lane wrote:
Bruce Momjian br...@momjian.us writes:
On Tue, Jun 17, 2014 at 03:55:02PM -0400, Alvaro Herrera wrote:
Can't you compare it to the historic default value? I mean,
Robert Haas robertmh...@gmail.com wrote:
Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
I thought the reason why this hasn't been implemented before
now is that sending an ErrorResponse to the client will result
in a loss of protocol sync.
Hmm ... you are
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 06/10/2014 02:57 AM, MauMau wrote:
From: Amit Kapila amit.kapil...@gmail.com
Is there a need to free memory context in PG_CATCH()? In error
path the memory due to this temporary context will get freed as
it will delete the transaction context
Robert Haas robertmh...@gmail.com writes:
On Tue, Jun 17, 2014 at 8:46 PM, Bruce Momjian br...@momjian.us wrote:
On Tue, Jun 17, 2014 at 07:12:16PM -0400, Tom Lane wrote:
What about comparing to the symbolic value LOBLKSIZE? This would make
pg_upgrade assume that the old installation had been
Joe Conway m...@joeconway.com writes:
I think the context deletion was missed in the first place because
storeRow() is the wrong place to create the context. Rather than
creating the context in storeRow() and deleting it two levels up in
materializeQueryResult(), I think it should be created
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 06/18/2014 12:09 PM, Tom Lane wrote:
Joe Conway m...@joeconway.com writes:
I think the context deletion was missed in the first place
because storeRow() is the wrong place to create the context.
Rather than creating the context in storeRow()
On Wed, Jun 18, 2014 at 2:55 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
On Tue, Jun 17, 2014 at 8:46 PM, Bruce Momjian br...@momjian.us wrote:
On Tue, Jun 17, 2014 at 07:12:16PM -0400, Tom Lane wrote:
What about comparing to the symbolic value LOBLKSIZE?
On 06/18/2014 11:50 AM, Kevin Grittner wrote:
The first thing is that I don't think a delay between the BEGIN and
the SELECT should cause a timeout to trigger, but more importantly
there should not be two ERROR responses to one SELECT statement.
I do think a delay between BEGIN and SELECT
Robert Haas robertmh...@gmail.com writes:
On Wed, Jun 18, 2014 at 2:55 PM, Tom Lane t...@sss.pgh.pa.us wrote:
The net behavior would be the same, but I thought it might be easier to
code by thinking of it this way. Or maybe it wouldn't --- it's just a
suggestion.
Well, the difference is
Josh Berkus j...@agliodbs.com writes:
There are plenty of badly-written applications which auto-begin, that
is, they issue a BEGIN; immediately after every COMMIT; whether or
not there's any additional work to do. This is a major source of IIT
and the timeout should not ignore it.
Nonsense.
On Wed, Jun 18, 2014 at 3:28 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
On Wed, Jun 18, 2014 at 2:55 PM, Tom Lane t...@sss.pgh.pa.us wrote:
The net behavior would be the same, but I thought it might be easier to
code by thinking of it this way. Or maybe
On Wed, Jun 18, 2014 at 10:58 AM, Andres Freund and...@2ndquadrant.com wrote:
On 2014-06-18 13:54:16 -0400, Tom Lane wrote:
I think we're not on the same page. My point is that someone might want
to automate the whole sequence: stop old postmaster, run pg_upgrade, start
the updated
On Wed, Jun 18, 2014 at 3:32 PM, Andres Freund and...@2ndquadrant.com wrote:
Hi,
On 2014-01-08 23:58:16 +, Robert Haas wrote:
Reduce the number of semaphores used under --disable-spinlocks.
Instead of allocating a semaphore from the operating system for every
spinlock, allocate a fixed
Stephen Frost wrote:
* Tom Lane (t...@sss.pgh.pa.us) wrote:
Stephen Frost sfr...@snowman.net writes:
Yes. I'd definitely like to see an ALTER TABLESPACE option, with an
ERROR that lists out all of the non-temporary objects which are found
(and lists any other databases which have
On 06/18/2014 12:32 PM, Tom Lane wrote:
Josh Berkus j...@agliodbs.com writes:
There are plenty of badly-written applications which auto-begin, that
is, they issue a BEGIN; immediately after every COMMIT; whether or
not there's any additional work to do. This is a major source of IIT
and the
On 2014-06-18 15:52:49 -0400, Robert Haas wrote:
On Wed, Jun 18, 2014 at 3:32 PM, Andres Freund and...@2ndquadrant.com wrote:
Hi,
On 2014-01-08 23:58:16 +, Robert Haas wrote:
Reduce the number of semaphores used under --disable-spinlocks.
Instead of allocating a semaphore from the
Joe Conway m...@joeconway.com writes:
On 06/18/2014 12:09 PM, Tom Lane wrote:
I find myself a bit suspicious of this whole thing though. If
it's necessary to explicitly clean up the tmpcontext, why not also
the sinfo-cstrs allocation? And what about the tupdesc,
attinmeta, etc created
On Wed, Jun 18, 2014 at 4:53 PM, Alvaro Herrera alvhe...@2ndquadrant.com
wrote:
Stephen Frost wrote:
* Tom Lane (t...@sss.pgh.pa.us) wrote:
Stephen Frost sfr...@snowman.net writes:
Yes. I'd definitely like to see an ALTER TABLESPACE option, with an
ERROR that lists out all of the
On Wed, Jun 18, 2014 at 3:56 PM, Andres Freund and...@2ndquadrant.com wrote:
I'm looking at the way you did this in the context of the atomics
patch. Won't:
s_init_lock_sema(volatile slock_t *lock)
{
static int counter = 0;
*lock = (++counter) %
On Wed, Jun 18, 2014 at 3:53 PM, Josh Berkus j...@agliodbs.com wrote:
On 06/18/2014 12:32 PM, Tom Lane wrote:
Josh Berkus j...@agliodbs.com writes:
There are plenty of badly-written applications which auto-begin, that
is, they issue a BEGIN; immediately after every COMMIT; whether or
not
On Wed, Jun 18, 2014 at 12:13 PM, Andres Freund and...@2ndquadrant.com wrote:
There might be cases where that's true, but in the majority of cases
where the variable isn't highly contended it's just about the same. In
many cases the microcode will implement atomic ops using ll/sc
operations
On 2014-06-18 17:04:49 -0400, Robert Haas wrote:
On Wed, Jun 18, 2014 at 12:13 PM, Andres Freund and...@2ndquadrant.com
wrote:
There might be cases where that's true, but in the majority of cases
where the variable isn't highly contended it's just about the same. In
many cases the
1 - 100 of 133 matches
Mail list logo
