On Thu, Nov 01, 2012 at 02:10:46PM +0900, Michael Paquier wrote:
> On Thu, Nov 1, 2012 at 1:48 PM, David Fetter 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 determini
On Thu, Nov 01, 2012 at 01:31:34PM +0900, Michael Paquier wrote:
> On Thu, Nov 1, 2012 at 1:03 PM, David Fetter 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 be
On Thu, Nov 1, 2012 at 1:03 PM, David Fetter 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 right thing?
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 repla
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 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 ('ba
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
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 Wed, Oct 24, 2012 at 12:06:35PM -0400, Tom Lane wrote:
> Noah Misch 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 imagine t
On Sun, Oct 28, 2012 at 8:22 AM, David Lee 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 fork-and-reuse-of-connections of l
On Wed, Oct 31, 2012 at 10:35 AM, Alvaro Herrera
wrote:
> 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 PostgreSQL Company
On Wed, Oct 31, 2012 at 05:22:10PM -0300, Alvaro Herrera wrote:
> Simon Riggs wrote:
> > On 31 October 2012 19:35, Noah Misch 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 strong
Simon Riggs wrote:
> On 31 October 2012 19:35, Noah Misch 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 that t
On 31 October 2012 19:35, Noah Misch 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 wrote:
>>
>> >>> * Is it ok to make FOR UPDATE somewhat weaker than before? In
On 31 October 2012 19:44, Tom Lane 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 could make for t1
Simon Riggs 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 we look at the
> pr
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 wrote:
>
> >>> * Is it ok to make FOR UPDATE somewhat weaker than before? In 9.2
> >>> and earlier you could be sure that if you
On Wed, Oct 31, 2012 at 2:21 AM, Josh Berkus 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.
Instead of: WHERE fo
-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 LOOP
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
> 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
> cla
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
> docum
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
2012/10/31 Alvaro Herrera :
> 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 h
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 t
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 a
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 .
On 31 October 2012 14:52, Pavel Stehule wrote:
> tested on 9.3
>
> Pavel
>
> 2012/10/31 Pavel Stehule :
> > Hello
> >
> > it is expected behave?
> >
> > 1.session
> >
> > postgres=# begin;
> > BEGIN
> > postgres=# lock oo IN ACCESS EXCLUSIVE MODE;
> > LOCK TABLE
> >
> > 2. session
> >
> > postgre
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 a
tested on 9.3
Pavel
2012/10/31 Pavel Stehule :
> 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
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)
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 t
On Tue, Oct 30, 2012 at 11:24 PM, Tom Lane wrote:
> Josh Berkus 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.
>
>> Oh, maybe I should ta
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 diffic
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 it
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 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 Ami
On 31 October 2012 08:59, Pavan Deolasee wrote:
>
>
> On Wed, Oct 31, 2012 at 11:41 AM, Amit Kapila
> 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 entry for
>> C2=5
>>
>
> Thanks for
On Wed, Oct 31, 2012 at 11:41 AM, Amit Kapila 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 entry for
> C2=5
>
>
Thanks for the report. I can reproduce this issue. As you rightly pointed
out,
On 30 October 2012 21:57, Tom Lane 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 written, the patch
40 matches
Mail list logo