> + /*
> + * The backend writes WAL of FPW at checkpoint. However, The
> backend do
> + * not need to write WAL of FPW at checkpoint shutdown because
> it
> + * performs when startup finishes.
> + */
> + XLogReportParame
On Tue, Oct 18, 2011 at 10:04 AM, Robert Haas wrote:
> Hmm, so you added the non-locked test in TAS()? Did you try adding it
> just to TAS_SPIN()? On Itanium, I found that it was slightly better
> to do it only in TAS_SPIN() - i.e. in the contended case.
>
Would it be a good change for S_LOCK(
(2011/10/18 2:27), Shigeru Hanada wrote:
> The new patch could be applied with some shifts. Regression tests of
> core and file_fdw have passed cleanly. Though I've tested only simple
> tests, ANALYZE works for foreign tables for file_fdw, and estimation of
> costs and selectivity seem appropriat
>> With help from IBM Japan Ltd. we did some tests on a larger IBM
>> machine than Tom Lane has used for his
>> test(http://archives.postgresql.org/message-id/8292.1314641...@sss.pgh.pa.us).
>> In his case it was IBM 8406-71Y, which has 8 physical cores and
>> 4SMT(32 threadings). Ours is IBM Power
On Tue, Oct 18, 2011 at 12:11 AM, Tatsuo Ishii wrote:
>>> That would be great. What I've been using as a test case is pgbench
>>> -S -c $NUM_CPU_CORES -j $NUM_CPU_CORES with scale factor 100 and
>>> shared_buffers=8GB.
>>>
>>> I think what you'd want to compare is the performance of unpatched
>>>
Robert Haas writes:
> On Mon, Oct 17, 2011 at 11:54 PM, Tom Lane wrote:
>> http://www.faqs.org/rfcs/rfc3629.html
> I'm still confused. The input string is already known to be valid
> UTF-8, so the second byte (if there is one) must be between 0x80 and
> 0xBF. Therefore it will be neither 0xED
>> That would be great. What I've been using as a test case is pgbench
>> -S -c $NUM_CPU_CORES -j $NUM_CPU_CORES with scale factor 100 and
>> shared_buffers=8GB.
>>
>> I think what you'd want to compare is the performance of unpatched
>> master, vs. the performance with this line added to s_lock.
On Mon, Oct 17, 2011 at 11:54 PM, Tom Lane wrote:
> Robert Haas writes:
>> - Why does the second byte need special handling for 0xED and 0xF4?
>
> http://www.faqs.org/rfcs/rfc3629.html
>
> See section 4 in particular. The underlying requirement is to disallow
> multiple representations of the sa
On Thu, Oct 13, 2011 at 6:48 AM, Kohei KaiGai wrote:
> struct ObjectAccessInfoData {
> ObjectAccessType oa_type;
> ObjectAddress oa_address;
> union {
> struct {
> HeapTuple newtuple;
> TupleDesc tupdesc; /* on
Robert Haas writes:
> - Why does the second byte need special handling for 0xED and 0xF4?
http://www.faqs.org/rfcs/rfc3629.html
See section 4 in particular. The underlying requirement is to disallow
multiple representations of the same Unicode code point.
regards, tom l
On Wed, Oct 12, 2011 at 11:45 PM, Kyotaro HORIGUCHI
wrote:
> Hello, the work is finished.
>
> Version 4 of the patch is attached to this message.
I went through this in a bit more detail tonight and am cleaning it
up. But I'm a bit confused, looking at pg_utf8_increment() in detail:
- Why does
On tis, 2011-10-18 at 01:30 +0200, desmodemone wrote:
>
> alter table testup DROP CONSTRAINT testup_pkey ;
>
> alter table testup add primary key(a) DEFERRABLE INITIALLY
> IMMEDIATE ;
>
> update testup set a=a+1 ;
> UPDATE 2
>
> commit;
>
>
> Seems an Oracle bug not Postgresql one!
Or
Royce Ausburn writes:
> On 18/10/2011, at 1:00 PM, Robert Haas wrote:
>> I don't think it's a bug for it to work. It'd probably work in
>> PostgreSQL too, if you inserted (2) first and then (1). It's just
>> that, as Tom says, if you want it to be certain to work (rather than
>> depending on the
On 18/10/2011, at 1:00 PM, Robert Haas wrote:
> On Mon, Oct 17, 2011 at 7:30 PM, desmodemone wrote:
>> Seems an Oracle bug not Postgresql one!
>
> I don't think it's a bug for it to work. It'd probably work in
> PostgreSQL too, if you inserted (2) first and then (1). It's just
> that, as Tom
At Monday, 10/17/2011 on 4:38 pm Simon Riggs wrote:
> On Mon, Oct 17, 2011 at 8:03 PM, Tom Lane wrote:
> > Alvaro Herrera writes:
> >> I just noticed that HeapTupleHeaderAdvanceLatestRemovedXid is comparing
> >> Xmax as a TransactionId without verifying whether it is a multixact or
> >> not.
On Mon, Oct 17, 2011 at 7:30 PM, desmodemone wrote:
> Seems an Oracle bug not Postgresql one!
I don't think it's a bug for it to work. It'd probably work in
PostgreSQL too, if you inserted (2) first and then (1). It's just
that, as Tom says, if you want it to be certain to work (rather than
dep
Hello there
Thanks Tom!
By the way I find something very funny :
Oracle 11gR2 :
SQL> create table testup ( a number ) ;
Tabella creata.
SQL> alter table testup add primary key (a) NOT DEFERRABLE INITIALLY
IMMEDIATE ;
Tabella modificata.
SQL> insert into testup values (1 ) ;
desmodemone writes:
> create table testup ( a int ) ;
> alter table testup add primary key (a ) ;
> insert into testup values (1);
> insert into testup values (2);
> update testup set a=a+1 ;
> ERROR: duplicate key value violates unique constraint "testup_pkey"
> DETTAGLI: Key (a)=(2) alrea
Hello there,
two guys of our developer team ( Lorenzo and Federico )
have seen a strange behaviour (in 8.4 and 9.1.1 ) on update, and I think is
a bug or something really strange or I not understand correctly this
behavior .
I explain now ( begin transaction or auto commit is th
Well, on the other hand maybe there is something wrong with the data.
Here's the test/steps I just did -
1. I do the pg_basebackup when the master is under load, hot slave now will
not start up but warm slave will.
2. I start a warm slave and let it catch up to current
3. On the slave I change 'ho
I can confirm that both the pg_clog and pg_subtrans errors do occur when
using pg_basebackup instead of rsync. The data itself seems to be fine
because using the exact same data I can start up a warm standby no problem,
it is just the hot standby that will not start up.
On Sat, Oct 15, 2011 at 7
On Mon, Oct 17, 2011 at 8:03 PM, Tom Lane wrote:
> Alvaro Herrera writes:
>> I just noticed that HeapTupleHeaderAdvanceLatestRemovedXid is comparing Xmax
>> as a TransactionId without verifying whether it is a multixact or not.
>> Since they advance separately, this could lead to bogus answers
On Mon, Oct 17, 2011 at 8:03 PM, Tom Lane wrote:
> Alvaro Herrera writes:
>> I just noticed that HeapTupleHeaderAdvanceLatestRemovedXid is comparing Xmax
>> as a TransactionId without verifying whether it is a multixact or not.
>> Since they advance separately, this could lead to bogus answers
Alvaro Herrera writes:
> I just noticed that HeapTupleHeaderAdvanceLatestRemovedXid is comparing Xmax
> as a TransactionId without verifying whether it is a multixact or not. Since
> they advance separately, this could lead to bogus answers. This probably
> needs to be fixed. I didn't look i
I just noticed that HeapTupleHeaderAdvanceLatestRemovedXid is comparing Xmax as
a TransactionId without verifying whether it is a multixact or not. Since they
advance separately, this could lead to bogus answers. This probably needs to
be fixed. I didn't look into past releases to see if ther
(2011/10/07 18:09), Etsuro Fujita wrote:
> Thank you for the review and the helpful information.
> I rebased. Please find attached a patch. I'll add the patch to the next CF.
>
> Changes:
>
>* cleanups and fixes
>* addition of the following to ALTER FOREIGN TABLE
>ALTER [COLUMN] c
Florian Pflug writes:
> In addition, I think we should reword the explanation in 4.2.8 (The SQL
> Language
> / SQL Syntax / Value Expressions / Window Functions). Instead of that rather
> long (and IMHO hard to read) paragraph about possible frame clauses and their
> behaviour in the presence or
On Mon, October 17, 2011 00:09, Jeff Davis wrote:
To facilitate would-be testers let me mention that to apply this patch one
needs to remove the
catversion changes from the patch.
(as discussed before:
http://archives.postgresql.org/pgsql-hackers/2011-02/msg00817.php )
Erik Rijkers
--
Se
=?UTF-8?B?SmFuIFVyYmHFhHNraQ==?= writes:
> On 17/10/11 02:53, Robert Haas wrote:
>> I previously floated the idea of using a new keyword, possibly LET,
>> for this, like this:
>>
>> LET var = value [, ...] IN query
> LET was something I thought about, although you'd have to use something
> like
On Oct16, 2011, at 20:26 , Tom Lane wrote:
> Florian Pflug writes:
>> On Oct16, 2011, at 19:09 , Tom Lane wrote:
>>> That doesn't seem like the same thing at all, because the indexed column
>>> is on different sides of the expression in the two cases. The situation
>>> that I'm worried about is "
Hi,
In 9.1, the following procedure writes a junk message into the server log;
$ initdb -D data
$ cat << EOF >> data/postgresql.conf
wal_level = hot_standby
max_wal_senders = 1
synchronous_standby_names = '*'
EOF
$ pg_ctl -D data start
$ psql -c "create table t (i int)" &
$ pg_ctl -D data -m fast
On Oct17, 2011, at 01:09 , Tom Lane wrote:
> Florian Pflug writes:
>> ... reading those parts again, I realize the it says "When ORDER BY is
>> omitted
>> the *default* frame consists ... ", and that the second quote is followed
>> by a footnote which says
>
>> There are options to define the w
On 17/10/11 02:53, Robert Haas wrote:
> On Sun, Oct 16, 2011 at 4:58 PM, Tom Lane wrote:
>> Dimitri Fontaine writes:
>>> Now that you mention it, the following might actually already work:
>>
>>> WITH settings AS (
>>>SELECT set_config('timezone', 'Europe/Amsterdam', t),
>>> set_co
On 2011-10-15 07:41, Tom Lane wrote:
Yeb Havinga writes:
Hello Royce,
Thanks again for testing.
I looked this patch over but concluded that it's not ready to apply,
mainly because there are too many weird behaviors around error
reporting.
Tom, thanks for reviewing - getting the syntax errors
On Sun, 2011-10-16 at 14:43 -0700, Jeff Davis wrote:
> On Fri, 2011-10-07 at 12:54 +0400, Alexander Korotkov wrote:
>
> > The first thing caught my eye in existing GiST code is idea of
> > subtype_float. float8 has limited precision and can't respresent, for
> > example, varlena values good enough
2011/10/15 Jun Ishiduka :
>
>> > if (!shutdown && XLogStandbyInfoActive())
>> > + {
>> > LogStandbySnapshot(&checkPoint.oldestActiveXid,
>> > &checkPoint.nextXid);
>> > + XLogReportParameters(REPORT_ON_BACKEND);
>> > + }
>> >
>> > Why doesn't the change of FPW need to
36 matches
Mail list logo
