Re: [BUGS] BUG #7534: walreceiver takes long time to detect n/w breakdown
On Sunday, September 16, 2012 12:14 AM Fujii Masao wrote:
On Sat, Sep 15, 2012 at 4:26 PM, Amit kapila wrote:
> On Saturday, September 15, 2012 11:27 AM Fujii Masao wrote:
> On Fri, Sep 14, 2012 at 10:01 PM, Amit kapila
wrote:
>>
>> On Thursday, September 13, 2012 10:57 PM Fujii Masao
>> On Thu, Sep 13, 2012 at 1:22 PM, Amit Kapila
wrote:
>>> On Wednesday, September 12, 2012 10:15 PM Fujii Masao
>>> On Wed, Sep 12, 2012 at 8:54 PM, wrote:
>>> The following bug has been logged on the website:
>
>> I would like to implement such feature for walreceiver, but there is
one
>> confusion that whether to use
>> same configuration parameter(replication_timeout) for walrecevier as
for
>> master or introduce a new
>> configuration parameter (receiver_replication_timeout).
>>
>I like the latter. I believe some users want to set the different
>timeout values,
>for example, in the case where the master and standby servers are
placed in
>the same room, but cascaded standby is placed in other continent.
>>
Thank you for your suggestion. I have implemented as per your
suggestion to have separate timeout parameter for walreceiver.
The main changes are:
1. Introduce a new configuration parameter
wal_receiver_replication_timeout for walreceiver.
2. In function WalReceiverMain(), check if there is no communication
till wal_receiver_replication_timeout, exit the walreceiver.
This is same as walsender functionality.
>>
As this is a feature, So I am uploading the attached patch in coming
CommitFest.
>>
Suggestions/Comments?
>
>>> You also need to change walsender so that it periodically sends the
heartbeat
>>> message, like walreceiver does each wal_receiver_status_interval.
Otherwise,
>>> walreceiver will detect the timeout wrongly whenever there is no traffic
in the
>>> master.
>
>> Doesn't current keepalive message from walsender will suffice that need?
> No. Though the keepalive interval should be smaller than the timeout,
> IIRC there is
> no way to specify the keepalive interval now.
To define the behavior correctly, according to me there are 2 options now:
Approach-1 :
Document that both(sender and receiver) the timeout parameters should be
greater than wal_receiver_status_interval.
If both are greater, then I think it might never timeout due to Idle.
Approach-2 :
Provide a variable wal_send_status_interval, such that if this is 0, then
the current behavior would prevail and if its non-zero then KeepAlive
message would be send maximum after that time.
The modified code of WALSendLoop will be as follows:
TimestampTz timeout = 0;
longsleeptime = 1; /* 10 s */
intwakeEvents;
/* sleeptime should be equal to wal send interval if
it is not zero otherwise default as 10 sec*/
if (wal_send_status_interval > 0)
{
sleeptime = wal_send_status_interval;
}
wakeEvents = WL_LATCH_SET | WL_POSTMASTER_DEATH |
WL_SOCKET_READABLE | WL_TIMEOUT;
if (pq_is_send_pending())
wakeEvents |= WL_SOCKET_WRITEABLE;
else if (wal_send_status_interval > 0)
{
WalSndKeepalive(output_message);
/* Try to flush pending output to the client
*/
if (pq_flush_if_writable() != 0)
break;
}
/* Determine time until replication timeout */
if (replication_timeout > 0)
{
timeout =
TimestampTzPlusMilliseconds(last_reply_timestamp,
replication_timeout);
if (wal_send_status_interval <= 0)
{
sleeptime = 1 + (replication_timeout
/ 10);
}
}
/* Sleep until something happens or replication
timeout */
WaitLatchOrSocket(&MyWalSnd->latch, wakeEvents,
MyProcPort->sock,
sleeptime);
/*
* Check for replication timeout. Note we ignore
the corner case
* possibility that the client replied just as we
reached the
* timeout ... he's supposed to reply *before* that.
*/
if (replication_timeout > 0 &&
GetCurrentTimestamp() >= timeout)
[BUGS] BUG #7546: Backups on hot standby cancelled despite hot_standby=on
The following bug has been logged on the website: Bug reference: 7546 Logged by: Stuart Bishop Email address: stu...@stuartbishop.net PostgreSQL version: 9.1.5 Operating system: Ubuntu 12.10 Description: I have a primary and a hot standby using streaming replication. The hot standby specifies 'hot_standby_feedback=on' with other replication settings set to default. If a vacuum occurs on the primary while pg_dump is dumping a large table, the pg_dump is cancelled, usually with the following error: ERROR: canceling statement due to conflict with recovery DETAIL: User was holding shared buffer pin for too long. I can excercise this problem with the following script: #!/bin/sh dbname="repl_test" master_port=5432 slave_port=5434 rows=200 slow="pv --rate-limit 20k" createdb -p $master_port $dbname psql -p $master_port -d $dbname -f - < /dev/null) & sleep 5; psql -p $master_port -d $dbname -c "vacuum verbose BigStuff;" -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
[BUGS] BUG #7545: Unresponsive server with error log reporting: "poll() failed: Invalid argument"
The following bug has been logged on the website: Bug reference: 7545 Logged by: Len Tanaka Email address: tanaka...@gmail.com PostgreSQL version: 9.2.0 Operating system: Mac OS X 10.6.8 Description: Multiple log files with same error repeated: poll() failed: Invalid argument Prior to error, in user account in user table doing an insert that has not failed in past. Unresponsive thereafter. Unable to shutdown postmaster. configure: ./configure --with-includes=/sw/include --with-libraries=/sw/lib --with-perl --with-python --with-openssl --with-bonjour --with-pam --with-krb5 --with-ldap --enable-thread-safety --with-libxml --with-libxslt --enable-dtrace make check passed all tests. Thanks for any help, reverted to 9.1.5 and no similar problem. Len -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
[BUGS] BUG #7548: pg_upgrade still requires pg_config
The following bug has been logged on the website: Bug reference: 7548 Logged by: Reinhard Max Email address: m...@suse.de PostgreSQL version: 9.1.5 Operating system: openSUSE Description: It looks like the attempt to remove pg_upgrade's dependency on pg_config (http://git.postgresql.org/gitweb/?p=postgresql.git;a=commit;h=2815574) was incomplete, since contrib/pg_upgrade/exec.c still contains the line validate_exec(cluster->bindir, "pg_config"); which makes pg_upgrade refuse to run when pg_config can't be found. -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] Postgres JDBC-hibernate Problem
Thanks Craig, We were able to make the necessary adjustments to the way Hibernate manages the data types differently in version 4.1.6, so we got pass this error. Now we have to tackle the a problem with the hibernate 4.1.6 batcher process no longer allowing us to ingest data into the database. We are getting the "nested transactions not supported error", even though the java developers are telling me that they have only a single commit at the end of their logical transaction. Caused by: org.hibernate.TransactionException: nested transactions not supported at org.hibernate.engine.transaction.spi.AbstractTransactionImpl.begin(AbstractT ransactionImpl.java:152) at org.hibernate.internal.SessionImpl.beginTransaction(SessionImpl.java:1396) at im.app.empl.service.ingest.EmployeeWriter.handleEmployeeSegment(EmployeeWrit er.java:309) at im.app.empl.service.ingest.EmployeeWriter$3.onEvent(EmployeeWriter.java:116) at im.app.empl.service.ingest.EmployeeWriter$3.onEvent(EmployeeWriter.java:113) at org.bushe.swing.event.ThreadSafeEventService.publish(ThreadSafeEventService. java:971) ... 5 more -Original Message- From: pgsql-bugs-ow...@postgresql.org [mailto:pgsql-bugs-ow...@postgresql.org] On Behalf Of Craig Ringer Sent: Monday, September 17, 2012 12:39 AM To: Freddie Burgess Cc: pgsql-bugs@postgresql.org Subject: Re: [BUGS] Postgres JDBC-hibernate Problem On 09/12/2012 12:18 AM, Freddie Burgess wrote: > We have upgraded from PostgreSQL 8.4.3 to PostgreSQL 9.1.4 and we are > getting the following errors when attempting to auto-gen schema DDL. You've changed quite a bit at once, so it's a bit hard to narrow down. Does the error occur when you run with the new PgJDBC and PostGIS libraries against the *old* database server? What about if you run with the old libraries against the new database server? This might not work for other reasons, but is worth trying. If it works, that suggests a regression in PgJDBC or PostGIS's client library. -- Craig Ringer -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
[BUGS] BUG #7549: max_connections check should query master when starting standby
The following bug has been logged on the website: Bug reference: 7549 Logged by: Petteri Räty Email address: pet...@petteriraty.eu PostgreSQL version: 9.2.0 Operating system: Linux or OS X Description: On a streaming hot standby slave starting postgres: LOG: database system was interrupted while in recovery at log time 2012-09-17 21:29:31 EEST HINT: If this has occurred more than once some data might be corrupted and you might need to choose an earlier recovery target. LOG: entering standby mode FATAL: hot standby is not possible because max_connections = 20 is a lower setting than on the master server (its value was 100) LOG: startup process (PID 51494) exited with exit code 1 LOG: aborting startup due to startup process failure It was indeed the case that the limit was lower on the slave but to resolve it I lowered the setting on the master: postgres=# SHOW max_connections; max_connections - 20 (1 row) The slave should allow resolving the issue by not only changes on the slave side but by checking if the master has been updated as well. Regards, Petteri -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
[BUGS] BUG #7550: NULL result when coercing a subquery result into an array
The following bug has been logged on the website: Bug reference: 7550 Logged by: Tom Forbes Email address: t...@tomforb.es PostgreSQL version: 9.2.0 Operating system: Windows 8 Description: Hello, I wasn't sure how to title this report so apologies if it is incorrect or misleading. I have two queries: http://pgsql.privatepaste.com/7d1473defa http://pgsql.privatepaste.com/85e1d43b7a The first query returns NULL and the second one returns an int[] with 623 elements in it. The only difference between the two queries is the last string - 'J. P. Bickella' returns NULL and 'J. P. Bickell' returns an int[]. The base query with no values can be found here: http://pgsql.privatepaste.com/1ebe2d7646 And the EXPLAIN ANALYZE VERBOSE of the queries can be found here: http://pgsql.privatepaste.com/a4b8b622c5 <-- Returns int[] http://pgsql.privatepaste.com/525fda6340 <-- Returns NULL In summary: Changing the last (or second to last) element of the second IN clause causes the query to return an array as expected, whereas setting it to 'J. P. Bickella' causes it to return NULL. Executing the query without wrapping it in an array() returns the expected results. If needed I can host the database this query is executing on for people to download upon request, but it is 1.2gb in size. -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #7550: NULL result when coercing a subquery result into an array
t...@tomforb.es writes: > I have two queries: > http://pgsql.privatepaste.com/7d1473defa > http://pgsql.privatepaste.com/85e1d43b7a > The first query returns NULL and the second one returns an int[] with 623 > elements in it. The only difference between the two queries is the last > string - 'J. P. Bickella' returns NULL and 'J. P. Bickell' returns an > int[]. That's ... bizarre. I assume you were running this same query without issues on earlier PG versions? Which? > If needed I can host the database this query is executing on for people to > download upon request, but it is 1.2gb in size. I suspect that you could reproduce the problem with a much smaller extract from the table, perhaps a couple thousand rows. Please try to create a self-contained test case along those lines --- it'll be easier all around than dealing with 1GB of data. regards, tom lane -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #7549: max_connections check should query master when starting standby
On Tue, Sep 18, 2012 at 3:51 AM, wrote: > The following bug has been logged on the website: > > Bug reference: 7549 > Logged by: Petteri Räty > Email address: pet...@petteriraty.eu > PostgreSQL version: 9.2.0 > Operating system: Linux or OS X > Description: > > On a streaming hot standby slave starting postgres: > > > LOG: database system was interrupted while in recovery at log time > 2012-09-17 21:29:31 EEST > HINT: If this has occurred more than once some data might be corrupted and > you might need to choose an earlier recovery target. > LOG: entering standby mode > FATAL: hot standby is not possible because max_connections = 20 is a lower > setting than on the master server (its value was 100) > LOG: startup process (PID 51494) exited with exit code 1 > LOG: aborting startup due to startup process failure > > It was indeed the case that the limit was lower on the slave but to resolve > it I lowered the setting on the master: > > postgres=# SHOW max_connections; > max_connections > - > 20 > (1 row) > > The slave should allow resolving the issue by not only changes on the slave > side but by checking if the master has been updated as well. If you change the max_connections on the master, you need to take a fresh backup from the master and start the standby from it. Regards, -- Fujii Masao -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #7549: max_connections check should query master when starting standby
On 17.9.2012 16.57, Fujii Masao wrote: > On Tue, Sep 18, 2012 at 3:51 AM, wrote: >> The following bug has been logged on the website: >> >> Bug reference: 7549 >> Logged by: Petteri Räty >> Email address: pet...@petteriraty.eu >> PostgreSQL version: 9.2.0 >> Operating system: Linux or OS X >> Description: >> >> On a streaming hot standby slave starting postgres: >> >> >> LOG: database system was interrupted while in recovery at log time >> 2012-09-17 21:29:31 EEST >> HINT: If this has occurred more than once some data might be corrupted and >> you might need to choose an earlier recovery target. >> LOG: entering standby mode >> FATAL: hot standby is not possible because max_connections = 20 is a lower >> setting than on the master server (its value was 100) >> LOG: startup process (PID 51494) exited with exit code 1 >> LOG: aborting startup due to startup process failure >> >> It was indeed the case that the limit was lower on the slave but to resolve >> it I lowered the setting on the master: >> >> postgres=# SHOW max_connections; >> max_connections >> - >> 20 >> (1 row) >> >> The slave should allow resolving the issue by not only changes on the slave >> side but by checking if the master has been updated as well. > > If you change the max_connections on the master, you need to take a > fresh backup from the master and start the standby from it. > > Regards, > If that's the case then would make sense to document it in connection to the output. I wouldn't have guessed that to be the case. Regards, Petteri -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
[BUGS] BUG #7551: Analyse of array domain types
The following bug has been logged on the website: Bug reference: 7551 Logged by: Diego de Lima Email address: diego_de_l...@hotmail.com PostgreSQL version: 9.2.0 Operating system: Centos 6 Description: When executing a vacuum full analyse of a column typed as a domain with source type as an array (varchar(64)[], for example), the command abort with: ERROR: array_typanalyze was invoked for non-array type 29692 I guess postgres ins't recognizing the domain as an array correctly, somewhere in the process. -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #7550: NULL result when coercing a subquery result into an array
Ok, I will try. I apologize, I made a mistake in the original post: 'J. P. Bickella' returns the correct array and 'J. P. Bickell' returns NULL. That's what you get for posting in a hurry! This is the first time I have run this query, so I don't know if it affects previous versions. ~Tom On Mon, Sep 17, 2012 at 9:38 PM, Tom Lane wrote: > t...@tomforb.es writes: >> I have two queries: >> http://pgsql.privatepaste.com/7d1473defa >> http://pgsql.privatepaste.com/85e1d43b7a > >> The first query returns NULL and the second one returns an int[] with 623 >> elements in it. The only difference between the two queries is the last >> string - 'J. P. Bickella' returns NULL and 'J. P. Bickell' returns an >> int[]. > > That's ... bizarre. I assume you were running this same query without > issues on earlier PG versions? Which? > >> If needed I can host the database this query is executing on for people to >> download upon request, but it is 1.2gb in size. > > I suspect that you could reproduce the problem with a much smaller > extract from the table, perhaps a couple thousand rows. Please try > to create a self-contained test case along those lines --- it'll be > easier all around than dealing with 1GB of data. > > regards, tom lane -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] how to proccess record returning null
What I want to do is, CREATE OR REPLACE FUNCTION clean() RETURNS void AS $$ DECLARE r record; BEGIN FOR r in select distinct(id) from temp loop If r.id is null or r.id ='' Then Insert into table_1 select * from temp; else Insert into table_1 select * from temp where sequence_number=r.id; end if; end loop; END; $$ LANGUAGE plpgsql; If 'id' is null then I want to insert all the records from table 'temp' to 'table_1' But if 'id' is not null I want to insert the data corresponding to those id's from table 'temp' to 'table_1'. Since id's are null or empty sting, control is not going inside the loop and as a result no data is inserted from table 'temp' to table 'table_1'. Currently I have come up with following workaround where null value is checked separately out of loop. CREATE OR REPLACE FUNCTION clean() RETURNS void AS $$ DECLARE r record; BEGIN if (select distinct(id) from temp ) is null thenInsert into table_1 select * from temp; end if; FOR r in select distinct(id) from temp loop Insert into table_1 select * from temp where sequence_number=r.id; end loop; END; $$ LANGUAGE plpgsql; But I think this is inefficient way of coding. Do you have any better alternative to this ? I hope I am clear. -- View this message in context: http://postgresql.1045698.n5.nabble.com/how-to-proccess-record-returning-null-tp5723932p5724361.html Sent from the PostgreSQL - bugs mailing list archive at Nabble.com. -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
[BUGS] Incorrect Sort Using Index Scan
Hello,
I have recently upgraded to PostgreSQL 9.2.0 and one of my queries is now
giving incorrectly sorted results due, I believe, to the new index-only scan in
9.2.0. The below table is a table of currency FX rates by date.
template1=# \d fx0;
Table "public.fx0"
Column | Type | Modifiers
-+--+---
date| date | not null
fromcur | character varying(3) | not null
fx | numeric(16,8)| not null
tocur | character varying(3) | not null
Indexes:
"pk_fx0" PRIMARY KEY, btree (date, fromcur, tocur)
This query correctly sorts the chosen two currencies by date;
> SELECT * FROM fx0 WHERE fromcur IN ('AUD','JPY') ORDER BY date desc;
date| fromcur | fx | tocur
+-++---
2012-09-14 | JPY | 0.01276592 | USD
2012-09-14 | AUD | 1.05741440 | USD
2012-09-13 | JPY | 0.01291478 | USD
2012-09-13 | AUD | 1.04486224 | USD
2012-09-12 | AUD | 1.04491173 | USD
2012-09-12 | JPY | 0.01284250 | USD
2012-09-11 | JPY | 0.01285457 | USD
2012-09-11 | AUD | 1.04324956 | USD
<...snip...>
template1=# explain select * FROM fx0 where fromcur IN ('AUD','JPY') ORDER BY
date desc;
QUERY PLAN
--
Sort (cost=21139.98..21181.31 rows=16530 width=19)
Sort Key: date
-> Seq Scan on fx0 (cost=0.00..19981.83 rows=16530 width=19)
Filter: ((fromcur)::text = ANY ('{AUD,JPY}'::text[]))
(4 rows)
Now I will add a simple condition that date >='2012-09-11'. The output should
exactly match the (truncated) results above:
template1=# select * FROM fx0 where fromcur IN ('AUD','JPY') and date
>='2012-09-11' ORDER BY date desc;
date| fromcur | fx | tocur
+-++---
2012-09-14 | JPY | 0.01276592 | USD
2012-09-13 | JPY | 0.01291478 | USD
2012-09-12 | JPY | 0.01284250 | USD
2012-09-11 | JPY | 0.01285457 | USD
2012-09-14 | AUD | 1.05741440 | USD
2012-09-13 | AUD | 1.04486224 | USD
2012-09-12 | AUD | 1.04491173 | USD
2012-09-11 | AUD | 1.04324956 | USD
(8 rows)
Note however that the table was NOT sorted by date, but by fromcur
(descending), then date. Let's look at the explain:
template1=# explain select * FROM fx0 where fromcur IN ('AUD','JPY') and date
>='2012-09-11' ORDER BY date desc;
QUERY PLAN
Index Scan Backward using pk_fx0 on fx0 (cost=0.00..40.54 rows=12 width=19)
Index Cond: ((date >= '2012-09-11'::date) AND ((fromcur)::text = ANY
('{AUD,JPY}'::text[])))
(2 rows)
The first (correct) query used a Seq Scan, and the second (incorrect) a Index
Scan, leading me to believe there's a problem with the Index Scan in this query
and/or table design.
Please let me know if I can provide any other information.
Regards,
Robert McGehee
PS. I analyzed, vacuumed, reindexed, clustered this table, and even made a a
brand new copy, but the problem persists.
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #7552: where clause gets ignored on one of view fields
and...@tchijov.com writes: > In a view (can provide source upon request) where condition on one of > columns gets ignored by select. No errors at all. Select runs as if the > condition is not present. Where conditions on other columns work as > expected. You really think this is sufficient detail for somebody to fix the problem? https://wiki.postgresql.org/wiki/Guide_to_reporting_problems regards, tom lane -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
[BUGS] BUG #7552: where clause gets ignored on one of view fields
The following bug has been logged on the website: Bug reference: 7552 Logged by: Andrei Tchijov Email address: and...@tchijov.com PostgreSQL version: 9.2.0 Operating system: Ubuntu 11.10 Description: In a view (can provide source upon request) where condition on one of columns gets ignored by select. No errors at all. Select runs as if the condition is not present. Where conditions on other columns work as expected. The very same view functions as it should in 9.1 and 9.0. -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] Postgres JDBC-hibernate Problem
On 09/18/2012 01:23 AM, Freddie Burgess wrote: Thanks Craig, We were able to make the necessary adjustments to the way Hibernate manages the data types differently in version 4.1.6, so we got pass this error. Now we have to tackle the a problem with the hibernate 4.1.6 batcher process no longer allowing us to ingest data into the database. We are getting the "nested transactions not supported error", even though the java developers are telling me that they have only a single commit at the end of their logical transaction. Look at the PostgreSQL logs and see. It's easier to trace if you set log_line_prefix to something like: log_line_prefix = '' which produces significantly more verbose logs but makes it easier to, using the pid and txix/vtxid info, work out how different logged statements fit into transactions. -- Craig Ringer -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #7551: Analyse of array domain types
diego_de_l...@hotmail.com writes: > ERROR: array_typanalyze was invoked for non-array type 29692 > I guess postgres ins't recognizing the domain as an array correctly, > somewhere in the process. Oh dear, where's my brown paper bag? :-( Fixed, thanks for the report! regards, tom lane -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] Incorrect Sort Using Index Scan
"McGehee, Robert" writes: > I have recently upgraded to PostgreSQL 9.2.0 and one of my queries is now > giving incorrectly sorted results due, I believe, to the new index-only scan > in 9.2.0. The below table is a table of currency FX rates by date. Hmm, no it's not about index-only scans (your query isn't even using one). I think this got broken in my commit 9e8da0f75731aaa7605cf4656c21ea09e84d2eb1, which turned =ANY into a native index qualification type for btree. I thought that the output could still be considered sorted by the index's sort order, but this example proves that that's not so. Need to think a bit more carefully about that --- maybe we can only assume sorted output when the =ANY qual is for the first index column. Or maybe we can't assume it at all. regards, tom lane -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #7549: max_connections check should query master when starting standby
On 09/18/2012 07:57 AM, Fujii Masao wrote: If you change the max_connections on the master, you need to take a fresh backup from the master and start the standby from it. WTF, really? What else breaks the replication and forces a re-clone? -- Craig Ringer -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #7549: max_connections check should query master when starting standby
On 18.09.2012 09:46, Craig Ringer wrote: On 09/18/2012 07:57 AM, Fujii Masao wrote: If you change the max_connections on the master, you need to take a fresh backup from the master and start the standby from it. WTF, really? No. It's enough to bump up max_connections on the standby, and restart. - Heikki -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
