There seems to be a problem in behavior of Create Index Concurrently and Hot
Update in HEAD code .
Please see the below testcase
Step-1
---
Client-1
Create table t1(c1 int, c2 int, c3 int);
insert into t1 values(1,2,3);
Step-2
---
Client - 2
update t1 set c2=4; where c1
On 30 October 2012 21:57, Tom Lane t...@sss.pgh.pa.us wrote:
So what I'm proposing instead, which is implemented in the other half of
the attached patch, is that we simply put an arbitrary limit on how many
outer-relation sets we'll consider while generating parameterized
indexscans. As
On Wed, Oct 31, 2012 at 11:41 AM, Amit Kapila amit.kap...@huawei.comwrote:
According to me, the problem happens at Step-4. As at Step-4, it does the
HOT update due to which validate_index() is not able to put an entry for
C2=5
Thanks for the report. I can reproduce this issue. As you
On 31 October 2012 08:59, Pavan Deolasee pavan.deola...@gmail.com wrote:
On Wed, Oct 31, 2012 at 11:41 AM, Amit Kapila amit.kap...@huawei.com
wrote:
According to me, the problem happens at Step-4. As at Step-4, it does the
HOT update due to which validate_index() is not able to put an
On Wednesday, October 31, 2012 3:25 AM Josh Berkus
I should think that doing this requires heading back towards there
being a single unique configuration stream, and over the course of
several versions, deprecating the INCLUDE directive.
Oh, maybe I should take a closer look at Amit's
Hello
how is state of this
http://archives.postgresql.org/pgsql-hackers/2009-09/msg01920.php ?
Regards
Pavel Stehule
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On 30/10/12 22:06, Oskari Saarenmaa wrote:
PL/Python maps Python SPIError exceptions with 'spidata' attribute into SQL
errors. PL/Python also creates classes in plpy.spiexceptions for all known
errors but does not initialize their spidata, so when a PL/Python function
raises such an exception
Hi All,
We are using postgreSQL since 2007 (now we use postgreSQL 8.4) and until
recently we used to perform vacuum and analyze tasks by ourself. Nevertheless
we reached a point where these tasks are taking so much time that why we decide
to use the autovacuum daemon.
But we have some
On Tue, Oct 30, 2012 at 11:24 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Josh Berkus j...@agliodbs.com writes:
I should think that doing this requires heading back towards there
being a single unique configuration stream, and over the course of
several versions, deprecating the INCLUDE directive.
Hello
this list is for PostgreSQL development purpose, better try at psql-general or
-admin.
But the autoanalyze is not that effective for second kind.
if it is not running at all it is very probably because of threshold +
scale_factor and the size of the second kind of tables.
We tried to
Hello
it is expected behave?
1.session
postgres=# begin;
BEGIN
postgres=# lock oo IN ACCESS EXCLUSIVE MODE;
LOCK TABLE
2. session
postgres=# select * from oo for update nowait;
hangs forever
Regards
Pavel Stehule
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
tested on 9.3
Pavel
2012/10/31 Pavel Stehule pavel.steh...@gmail.com:
Hello
it is expected behave?
1.session
postgres=# begin;
BEGIN
postgres=# lock oo IN ACCESS EXCLUSIVE MODE;
LOCK TABLE
2. session
postgres=# select * from oo for update nowait;
hangs forever
Regards
On Wednesday, October 31, 2012 02:51:38 PM Pavel Stehule wrote:
it is expected behave?
1.session
postgres=# begin;
BEGIN
postgres=# lock oo IN ACCESS EXCLUSIVE MODE;
LOCK TABLE
2. session
postgres=# select * from oo for update nowait;
hangs forever
NOWAIT is about row
On 31 October 2012 14:52, Pavel Stehule pavel.steh...@gmail.com wrote:
tested on 9.3
Pavel
2012/10/31 Pavel Stehule pavel.steh...@gmail.com:
Hello
it is expected behave?
1.session
postgres=# begin;
BEGIN
postgres=# lock oo IN ACCESS EXCLUSIVE MODE;
LOCK TABLE
2.
Hi,
On Wednesday, October 31, 2012 02:51:38 PM Pavel Stehule wrote:
Hello
it is expected behave?
1.session
postgres=# begin;
BEGIN
postgres=# lock oo IN ACCESS EXCLUSIVE MODE;
LOCK TABLE
2. session
postgres=# select * from oo for update nowait;
hangs forever
Yes, I
Pavel Stehule escribió:
Hello
it is expected behave?
1.session
postgres=# begin;
BEGIN
postgres=# lock oo IN ACCESS EXCLUSIVE MODE;
LOCK TABLE
2. session
postgres=# select * from oo for update nowait;
hangs forever
select for update nowait would raise an error if the
Alvaro Herrera escribió:
Now, is this the right behavior? I'm not sure. But I know for certain
that making it behave as you expect is very tricky. The table lock is
grabbed during parse analysis; we'd have to postpone grabbing the lock
until after we have had the chance to notice that
2012/10/31 Alvaro Herrera alvhe...@2ndquadrant.com:
Alvaro Herrera escribió:
Now, is this the right behavior? I'm not sure. But I know for certain
that making it behave as you expect is very tricky. The table lock is
grabbed during parse analysis; we'd have to postpone grabbing the lock
Alvaro Herrera wrote:
Fix erroneous choices of segNo variables
Commit dfda6eba (which changed segment numbers to use a single 64 bit
variable instead of log/seg) introduced a couple of bogus choices of
exactly which log segment number variable to use in each case.
This is currently pretty
Hey,
On 30/10/12 20:33, Andres Freund wrote:
+#ifdef MAP_HUGETLB
+# ifdef __ia64__
+#define PG_HUGETLB_BASE_ADDR (void *)(0x8000UL)
+#define PG_MAP_HUGETLB (MAP_HUGETLB|MAP_FIXED)
+# else
Not your fault, but that looks rather strange to me. The level of
Now, is this the right behavior? I'm not sure. But I know for certain
that making it behave as you expect is very tricky. The table lock is
grabbed during parse analysis; we'd have to postpone grabbing the lock
until after we have had the chance to notice that there's a FOR UPDATE
clause
Amit,
I think you can simplify this task by forgetting about parsing the .auto
file entirely when writing it. That is, the .auto file should be
regenerated, and should write out whatever has been set in pg_settings,
regardless of what was in the file beforehand. I don't see the value in
parsing
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi!
This is an old problem, referred to in bug #4907:
CREATE TABLE test(id INTEGER);
INSERT INTO test VALUES (1);
CREATE OR REPLACE FUNCTION test_func() returns SETOF test as $$
DECLARE
res_ test;
BEGIN
FOR res_ IN SELECT * FROM test
On Wed, Oct 31, 2012 at 2:21 AM, Josh Berkus j...@agliodbs.com wrote:
Hey, are you going to work on this for 9.3?
Yes, I do plan to get back to it. Thanks for the push :)
I really could use the feature ...
If you're not aware already, you can work around the limitation using
a subquery.
On Mon, Oct 29, 2012 at 08:18:33AM -0400, Kevin Grittner wrote:
Andres Freund wrote:
On Sunday, October 28, 2012 11:47:16 PM Simon Riggs wrote:
Andres Freund and...@2ndquadrant.com wrote:
* Is it ok to make FOR UPDATE somewhat weaker than before? In 9.2
and earlier you could be sure
Simon Riggs si...@2ndquadrant.com writes:
We should be able to do a better job of recognising some other
aspect/symmetry of this situation and then simplifying the problem
from that. Calculating all paths treats the problem as a complete
unknown and we must be able to do better than that. If
On 31 October 2012 19:44, Tom Lane t...@sss.pgh.pa.us wrote:
Before 9.2, we didn't have this problem in this guise because we didn't
generate parameterized paths bottom-up; instead, given that we had
already decided to join t2 and t3 for some reason, we would look to see
what indexpaths we
On 31 October 2012 19:35, Noah Misch n...@leadboat.com wrote:
On Mon, Oct 29, 2012 at 08:18:33AM -0400, Kevin Grittner wrote:
Andres Freund wrote:
On Sunday, October 28, 2012 11:47:16 PM Simon Riggs wrote:
Andres Freund and...@2ndquadrant.com wrote:
* Is it ok to make FOR UPDATE somewhat
Simon Riggs wrote:
On 31 October 2012 19:35, Noah Misch n...@leadboat.com wrote:
On Mon, Oct 29, 2012 at 08:18:33AM -0400, Kevin Grittner wrote:
Andres Freund wrote:
The point is the introduction of a weaker lock level which can be
used by the ri triggers. I don't see any imperative
On Wed, Oct 31, 2012 at 05:22:10PM -0300, Alvaro Herrera wrote:
Simon Riggs wrote:
On 31 October 2012 19:35, Noah Misch n...@leadboat.com wrote:
+1. I had not considered this angle during previous reviews, but I agree
with
Andres's position. Since this patch does not strengthen the
On Wed, Oct 31, 2012 at 10:35 AM, Alvaro Herrera
alvhe...@2ndquadrant.comwrote:
I'm not particularly fond of the (rather confusing) extensive use of
global vars throughout the xlog code. Am I the only one?
Nope.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise
On Sun, Oct 28, 2012 at 8:22 AM, David Lee davidomu...@gmail.com wrote:
Thanks. Is this something viable as a feature request?
Just to contribute a tiny amount of data: I also get this request from
users on a semi-regular basis. It's definitely below the pains of
pg_dump/restore or
On Wed, Oct 24, 2012 at 12:06:35PM -0400, Tom Lane wrote:
Noah Misch n...@leadboat.com writes:
For FKs, we currently document that The referenced columns must be the
columns of a non-deferrable unique or primary key constraint in the
referenced
table. Taking that literally, one might
This was rather surprising - my synchronous commit was... not cancelled. Is
this expected behaviour?
d5r5fdj6u5ieml= begin;
BEGIN
d5r5fdj6u5ieml= set synchronous_commit = 'on';
SET
d5r5fdj6u5ieml= insert into data values ('baz');
INSERT 0 1
d5r5fdj6u5ieml= commit;
^CCancel request sent
WARNING:
On Wednesday, October 31, 2012 10:21 PM Josh Berkus wrote:
Amit,
I think you can simplify this task by forgetting about parsing the .auto
file entirely when writing it. That is, the .auto file should be
regenerated, and should write out whatever has been set in pg_settings,
regardless of
On Wed, Oct 31, 2012 at 06:39:20PM -0700, Peter van Hardenberg wrote:
This was rather surprising - my synchronous commit was... not
cancelled. Is this expected behaviour?
I believe it is.
Does the following do the right thing?
SET synchronous_commit='on';
BEGIN;
INSERT INTO data VALUES
On Tue, 2012-10-30 at 17:28 -0400, Tom Lane wrote:
A concrete usage case that this breaks is doing something like
find . -name '*.c' | xargs grep whatever
Up to now I've always been able to assume that that would catch
occurrences of whatever coming from *.y and *.l files. No more
On Wednesday, October 31, 2012 11:50 PM Palle Girgensohn wrote:
Hash: SHA1
Hi!
This is an old problem, referred to in bug #4907:
ALTER TABLE test ADD COLUMN foo INTEGER;
SELECT * FROM test_func();
- -- ERROR: wrong record type supplied in RETURN NEXT
You have to run create or replace
On Thu, Nov 1, 2012 at 1:03 PM, David Fetter da...@fetter.org wrote:
On Wed, Oct 31, 2012 at 06:39:20PM -0700, Peter van Hardenberg wrote:
This was rather surprising - my synchronous commit was... not
cancelled. Is this expected behaviour?
I believe it is.
Does the following do the
On Thu, Nov 01, 2012 at 01:31:34PM +0900, Michael Paquier wrote:
On Thu, Nov 1, 2012 at 1:03 PM, David Fetter da...@fetter.org wrote:
On Wed, Oct 31, 2012 at 06:39:20PM -0700, Peter van Hardenberg wrote:
This was rather surprising - my synchronous commit was... not
cancelled. Is this
On Thu, Nov 01, 2012 at 02:10:46PM +0900, Michael Paquier wrote:
On Thu, Nov 1, 2012 at 1:48 PM, David Fetter da...@fetter.org wrote:
I guess my disk subsystem (it's a consumer-grade DAS SSD) doesn't have
enough latency for my reflexes to hit ^C fast enough. Any way to
inject this fault
41 matches
Mail list logo
