On Fri, Oct 14, 2011 at 07:36:32PM +0100, Peter Geoghegan wrote:
This evening, David Fetter described a problem to me that he was
having building the Twitter FDW. It transpired that it was down to its
dependence on an #include that was recently judged to be
redundant.This seems like another
2011/10/15 Jun Ishiduka ishizuka@po.ntts.co.jp:
if (!shutdown XLogStandbyInfoActive())
+ {
LogStandbySnapshot(checkPoint.oldestActiveXid,
checkPoint.nextXid);
+ XLogReportParameters(REPORT_ON_BACKEND);
+ }
Why doesn't the change of FPW need to
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. Even
On 2011-10-15 07:41, Tom Lane wrote:
Yeb Havingayebhavi...@gmail.com 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 -
On 17/10/11 02:53, Robert Haas wrote:
On Sun, Oct 16, 2011 at 4:58 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Dimitri Fontaine dimi...@2ndquadrant.fr writes:
Now that you mention it, the following might actually already work:
WITH settings AS (
SELECT set_config('timezone',
On Oct17, 2011, at 01:09 , Tom Lane wrote:
Florian Pflug f...@phlo.org 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
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 stop
On Oct16, 2011, at 20:26 , Tom Lane wrote:
Florian Pflug f...@phlo.org 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
(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] column
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
Alvaro Herrera alvhe...@alvh.no-ip.org 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
On Mon, Oct 17, 2011 at 8:03 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Alvaro Herrera alvhe...@alvh.no-ip.org writes:
I just noticed that HeapTupleHeaderAdvanceLatestRemovedXid is comparing Xmax
as a TransactionId without verifying whether it is a multixact or not.
Since they advance
On Mon, Oct 17, 2011 at 8:03 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Alvaro Herrera alvhe...@alvh.no-ip.org writes:
I just noticed that HeapTupleHeaderAdvanceLatestRemovedXid is comparing Xmax
as a TransactionId without verifying whether it is a multixact or not.
Since they advance
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
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
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
desmodemone desmodem...@gmail.com 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
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 ) ;
On Mon, Oct 17, 2011 at 7:30 PM, desmodemone desmodem...@gmail.com 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
At Monday, 10/17/2011 on 4:38 pm Simon Riggs wrote:
On Mon, Oct 17, 2011 at 8:03 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Alvaro Herrera alvhe...@alvh.no-ip.org writes:
I just noticed that HeapTupleHeaderAdvanceLatestRemovedXid is comparing
Xmax as a TransactionId without verifying whether
On 18/10/2011, at 1:00 PM, Robert Haas wrote:
On Mon, Oct 17, 2011 at 7:30 PM, desmodemone desmodem...@gmail.com 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
Royce Ausburn royce...@inomial.com 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
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!
Oracle's
On Wed, Oct 12, 2011 at 11:45 PM, Kyotaro HORIGUCHI
horiguchi.kyot...@oss.ntt.co.jp 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
Robert Haas robertmh...@gmail.com 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.
On Thu, Oct 13, 2011 at 6:48 AM, Kohei KaiGai kai...@kaigai.gr.jp wrote:
struct ObjectAccessInfoData {
ObjectAccessType oa_type;
ObjectAddress oa_address;
union {
struct {
HeapTuple newtuple;
TupleDesc
On Mon, Oct 17, 2011 at 11:54 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com 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
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.h for your
Robert Haas robertmh...@gmail.com writes:
On Mon, Oct 17, 2011 at 11:54 PM, Tom Lane t...@sss.pgh.pa.us 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.
On Tue, Oct 18, 2011 at 12:11 AM, Tatsuo Ishii is...@postgresql.org 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
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 750
(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 appropriate.
32 matches
Mail list logo
