[BUGS] BUG #8215: pg_dump includes table out of order in SQL dump
The following bug has been logged on the website: Bug reference: 8215 Logged by: Isaac Morland Email address: ijmor...@uwaterloo.ca PostgreSQL version: 9.2.4 Operating system: Server: Ubuntu 12.04; Client: Mac OS X 10.5.8 Description: My understanding is that pg_dump is supposed to include tables in SQL dumps in alphabetical order by table name. If this is wrong then this bug may be invalid and I apologize. In a dump of a particular schema, I'm getting a particular table always coming first. Renaming it to other names does not affect its placement in the output. By contrast, renaming other tables does change their location in the resulting output. I've tried a few things to try to figure out what might be different about the problem table with no success so far. This is a schema-only dump (--schema-only). -- 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 #8198: ROW() literals not supported in an IN clause
On Wed, Jun 5, 2013 at 7:58 AM, Amit Kapila amit.kap...@huawei.com wrote:
On Wednesday, June 05, 2013 5:34 AM Rafał Rzepecki wrote:
On Tue, Jun 4, 2013 at 12:35 PM, Amit Kapila amit.kap...@huawei.com
wrote:
On Saturday, June 01, 2013 9:37 PM
Row type literals constructed with ROW() cause an error when used in
an IN clause (string literals casted appropriately are allowed).
This
is especially problematic since many client libraries use these
literals to pass values of row-type arguments, hence making it
impossible to use them in IN-clause queries.
If I'm right, the proper fix would be (patch 0001; caution, not
tested):
--- a/src/backend/parser/parse_expr.c
+++ b/src/backend/parser/parse_expr.c
@@ -1203,10 +1203,9 @@ transformAExprIn(ParseState *pstate, A_Expr *a)
Node *rexpr = (Node *) lfirst(l);
Node *cmp;
- if (haveRowExpr)
+ if (haveRowExpr IsA(lexpr, RowExpr))
{
- if (!IsA(lexpr, RowExpr) ||
- !IsA(rexpr, RowExpr))
+ if (!IsA(rexpr, RowExpr))
ereport(ERROR,
(errcode(ERRCODE_SYNTAX_ERROR),
errmsg(arguments of row IN must all
be row expressions),
Since the restriction seems a rather arbitrary (at least I fail to see
any reason for it), it can be removed altogether (patch 0002, not
tested as well):
--- a/src/backend/parser/parse_expr.c
+++ b/src/backend/parser/parse_expr.c
@@ -1203,20 +1203,12 @@ transformAExprIn(ParseState *pstate, A_Expr *a)
Node *rexpr = (Node *) lfirst(l);
Node *cmp;
- if (haveRowExpr)
- {
- if (!IsA(lexpr, RowExpr) ||
- !IsA(rexpr, RowExpr))
- ereport(ERROR,
-
(errcode(ERRCODE_SYNTAX_ERROR),
- errmsg(arguments of row IN must
all be row expressions),
-
parser_errposition(pstate, a-location)));
+ if (IsA(lexpr, RowExpr) IsA(rexpr, RowExpr))
cmp = make_row_comparison_op(pstate,
a-name,
(List *)
copyObject(((RowExpr *) lexpr)-args),
((RowExpr *) rexpr)-args,
a-location);
- }
else
cmp = (Node *) make_op(pstate,
a-
name,
I had tried, both your patches have passed all regression tests (tested on
Windows). I feel fixing it in a way similar to your Patch-1 would be
more appropriate as with Patch-1 it can generate meaningful error message for
some cases like below:
postgres=# select * from the_table where ROW('abc','def') in
(row('foo','bar')::the_row,12);
ERROR: arguments of row IN must all be row expressions
LINE 1: select * from the_table where ROW('abc','def') in (row('foo'...
Perhaps you're right, rare cases when you want to do something like
'ROW('abc','def') in (row('foo','bar')::the_row, a_column)' are, I
suppose, so exotic that working around this restriction probably won't
be much of a hassle.
--
Rafał Rzepecki
--
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 #8192: On very large tables the concurrent update with vacuum lag the hot_standby replica
On Tue, Jun 4, 2013 at 5:57 AM, Federico Campoli feder...@brandwatch.comwrote: I'm sorry, just guessing it could be a loop. The read remains stuck on the same segment. On my testbox I have at least 1 minute to 20 Mb/s. On the live system the peak is 124 Mb/s for 2 to 3 minutes without any progress in the wal reply. I've attached the part of postgresql's log with debug2 from my sandbox when that happens. It looks like it is making progress, just very slowly. Basically I think every WAL record that needs it to be replayed triggers the random read of some data block which is not already cached on the standby. In warm standby everything is fine no lag at all. OK, then I don't think I can reproduce it. The spiky replay I see is the same whether the standby is hot or warm. Cheers, Jeff
Re: [BUGS] BUG #8215: pg_dump includes table out of order in SQL dump
ijmor...@uwaterloo.ca writes: My understanding is that pg_dump is supposed to include tables in SQL dumps in alphabetical order by table name. That's the default behavior as long as there are no ordering constraints that would dictate doing something else. You haven't provided enough info to tell whether there's such a constraint in your case ... 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 #8216: TO_DATE does not support th format provided
The following bug has been logged on the website:
Bug reference: 8216
Logged by: Sunitha Mudumba
Email address: sunitha.mudu...@blss.com.au
PostgreSQL version: 9.2.4
Operating system: Windows
Description:
To_date does not throw an error when an invalid date is provided to it
select to_date('10-30-2012','dd-MM-');
It is not forcing the format on the date, instead it stores 2014-06-14.
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
