Hi, Jaime

thank you for your answer.

I understand it.

I turned synchronous_commit to "local",
I get desirable behavior.

I've thought that if there are no standby,
the primary would behave like stand-alone...
sorry, this is my misunderstanding.

regards,

(2011/05/27 14:53), Jaime Casanova wrote:
On Fri, May 27, 2011 at 12:26 AM, Tomonari Katsumata
<katsumata.tomon...@po.ntts.co.jp>  wrote:

I've checked "unlogged table" and "Streaming Replication".
I'm thinking about using unlogged tables as work-tables on Primary.

1) construct Streaming Replication Environment.
  Primary and Standby are same server with different database cluster and
port number.

2) create unlogged table on Primary.
  =# CREATE UNLOGGED TABLE tbl1(i int);
  This table is available on primary only.

because streaming replication works shipping WAL records (the records
of the transactional log) to the standby but because UNLOGGED tables
are not logged to WAL i guess those always will be empty on standby,
but the table should appear on the standby, i guess


4) create unlogged table on Primary again.
  =# CREATE UNLOGGED TABLE tbl2(i int);

when I executed 4), any response is not back to my psql. and I canceled the
query, I got messages bellow.
---
Cancel request sent
WARNING:  canceling wait for synchronous replication due to user request
DETAIL:  The transaction has already committed locally, but may not have
been replicated to the standby.
CREATE TABLE
---
and the table has been created.

I think It's strange behavior(a canceled table has been created).

actually, you're not cancelling the creation... the table has been
created and the wal is being sent to the standby (because the standby
is a synchronous standby, it keeps waiting until the standby aknlowdge
to have received the wal), so what you are cancelling now is the
primary waiting for the standby...


btw, i guess we should be defaulting to asynchronous standbys (ie:
synchronous_commit=local)




--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs

Reply via email to