Re: [PATCHES] Improve shutdown during online backup, take 4
Tom Lane wrote: I've attached a patch that works for me. I hope I got it right. Applied with additional cleanup. You hadn't thought very carefully about additional state transitions that would have to be introduced into the postmaster state machine to support a new state --- for example, as coded a SIGINT delivered to the postmaster after SIGTERM would fail to do anything at all, when of course it really ought to force us into fast shutdown. Also, it's not really that hard to disallow non-superusers from connecting in PM_WAIT_BACKUP state. Thank you for helping. You know, this is my first patch for server code. I know that I still have a lot to learn until I grok how all that works together. Yours, Laurenz Albe -- Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-patches
Re: [PATCHES] win32mak_patch
Hiroshi Saito wrote: Hi. Eh? It is strange... http://winpg.jp/~saito/pg_work/WIN32_BUILD_INF/psql_win32.mak Actually, it is required although psql is built. Have I missed something? Note that building psql this way really isn't supported anymore :-) Anyway. If you get references to it, you need to pull in port/dirmod.c into psql as well. Normally, it would get this through libpgport, but it looks like your custom makfile is pulling the files in directly instead. So adding dirmod to the list of stuff from src/port should hopefully fix your problem. //Magnus -- Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-patches
Re: [PATCHES] win32mak_patch
Hi. Thanks! - Original Message - From: Magnus Hagander [EMAIL PROTECTED] Hiroshi Saito wrote: Hi. Eh? It is strange... http://winpg.jp/~saito/pg_work/WIN32_BUILD_INF/psql_win32.mak Actually, it is required although psql is built. Have I missed something? Note that building psql this way really isn't supported anymore :-) Yes, It is only a script for my check. :-) Anyway. If you get references to it, you need to pull in port/dirmod.c into psql as well. Normally, it would get this through libpgport, but it looks like your custom makfile is pulling the files in directly instead. So adding dirmod to the list of stuff from src/port should hopefully fix your problem. Um, win32.mak of libpq needed to add dirmod.c -- libpq.lib(fe-connect.obj) : error LNK2001: (snip-sjis message) _pgwin32_safestat Then, Is containing in libpq wrong? I'm confused for a while... Regards, Hiroshi Saito -- Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-patches
Re: [PATCHES] generate_subscripts
Pavel Stehule escribió: This patch contains generate_subscripts functions, that generate series of array's subscripts of some dimension: Committed, thanks. -- Alvaro Herrerahttp://www.CommandPrompt.com/ The PostgreSQL Company - Command Prompt, Inc. -- Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-patches
Re: [PATCHES] Removing typename from A_Const (was: Empty arrays with ARRAY[])
Brendan Jurd escribió: Here's my attempt to remove the typename field from A_Const. There were a few places (notably flatten_set_variable_args() in guc.c, and typenameTypeMod() in parse_type.c) where the code expected to see an A_Const with a typename, and I had to adjust for an A_Const within a TypeCast. Nonetheless, there was an overall net reduction of 34 lines of code, so I think this was a win. Do say ... why don't we do away with A_Const altogether and just replace it with Value? After this patch, I don't see what's the difference. -- Alvaro Herrerahttp://www.CommandPrompt.com/ PostgreSQL Replication, Consulting, Custom Development, 24x7 support -- Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-patches
Re: [PATCHES] Removing typename from A_Const (was: Empty arrays with ARRAY[])
Alvaro Herrera [EMAIL PROTECTED] writes: Brendan Jurd escribió: Here's my attempt to remove the typename field from A_Const. There were a few places (notably flatten_set_variable_args() in guc.c, and typenameTypeMod() in parse_type.c) where the code expected to see an A_Const with a typename, and I had to adjust for an A_Const within a TypeCast. Nonetheless, there was an overall net reduction of 34 lines of code, so I think this was a win. Do say ... why don't we do away with A_Const altogether and just replace it with Value? After this patch, I don't see what's the difference. They're logically different things, and after I get done putting a parse location field into A_Const, they'll still be physically different too. regards, tom lane -- Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-patches
Re: [HACKERS] [PATCHES] Removing typename from A_Const (was: Empty arrays with ARRAY[])
Tom Lane escribió: Alvaro Herrera [EMAIL PROTECTED] writes: Brendan Jurd escribi�: Here's my attempt to remove the typename field from A_Const. There were a few places (notably flatten_set_variable_args() in guc.c, and typenameTypeMod() in parse_type.c) where the code expected to see an A_Const with a typename, and I had to adjust for an A_Const within a TypeCast. Nonetheless, there was an overall net reduction of 34 lines of code, so I think this was a win. Do say ... why don't we do away with A_Const altogether and just replace it with Value? After this patch, I don't see what's the difference. They're logically different things, and after I get done putting a parse location field into A_Const, they'll still be physically different too. Aha. Are you working from Brendan's patch? I was going to commit it. -- Alvaro Herrerahttp://www.CommandPrompt.com/ PostgreSQL Replication, Consulting, Custom Development, 24x7 support -- Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-patches
Re: [HACKERS] [PATCHES] Removing typename from A_Const (was: Empty arrays with ARRAY[])
Alvaro Herrera [EMAIL PROTECTED] writes: Tom Lane escribió: They're logically different things, and after I get done putting a parse location field into A_Const, they'll still be physically different too. Aha. Are you working from Brendan's patch? I was going to commit it. Sure, go ahead. I was going to add the parse location at the same time, but it can perfectly well be done as a separate patch. regards, tom lane -- Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-patches
Re: [HACKERS] [PATCHES] Removing typename from A_Const (was: Empty arrays with ARRAY[])
Tom Lane escribió:
Alvaro Herrera [EMAIL PROTECTED] writes:
Tom Lane escribió:
They're logically different things, and after I get done putting a parse
location field into A_Const, they'll still be physically different too.
Aha. Are you working from Brendan's patch? I was going to commit it.
Sure, go ahead. I was going to add the parse location at the same time,
but it can perfectly well be done as a separate patch.
I came up with the attached patch. I added the location bits (although
I am unsure if I got the locations right in the parser), but they are
unused -- figuring out how to use them would take me longer than I can
to spend on this.
--
Alvaro Herrerahttp://www.CommandPrompt.com/
PostgreSQL Replication, Consulting, Custom Development, 24x7 support
Index: src/backend/nodes/copyfuncs.c
===
RCS file: /home/alvherre/Code/cvs/pgsql/src/backend/nodes/copyfuncs.c,v
retrieving revision 1.392
diff -c -p -r1.392 copyfuncs.c
*** src/backend/nodes/copyfuncs.c 14 Apr 2008 17:05:33 - 1.392
--- src/backend/nodes/copyfuncs.c 28 Apr 2008 20:20:44 -
*** _copyAConst(A_Const *from)
*** 1639,1645
break;
}
! COPY_NODE_FIELD(typename);
return newnode;
}
--- 1639,1645
break;
}
! COPY_SCALAR_FIELD(location);
return newnode;
}
Index: src/backend/nodes/equalfuncs.c
===
RCS file: /home/alvherre/Code/cvs/pgsql/src/backend/nodes/equalfuncs.c,v
retrieving revision 1.321
diff -c -p -r1.321 equalfuncs.c
*** src/backend/nodes/equalfuncs.c 14 Apr 2008 17:05:33 - 1.321
--- src/backend/nodes/equalfuncs.c 28 Apr 2008 16:17:02 -
*** _equalParamRef(ParamRef *a, ParamRef *b)
*** 1691,1701
static bool
_equalAConst(A_Const *a, A_Const *b)
{
! if (!equal(a-val, b-val)) /* hack for in-line Value field */
! return false;
! COMPARE_NODE_FIELD(typename);
!
! return true;
}
static bool
--- 1691,1697
static bool
_equalAConst(A_Const *a, A_Const *b)
{
! return equal(a-val, b-val); /* hack for in-line Value field */
}
static bool
Index: src/backend/nodes/outfuncs.c
===
RCS file: /home/alvherre/Code/cvs/pgsql/src/backend/nodes/outfuncs.c,v
retrieving revision 1.325
diff -c -p -r1.325 outfuncs.c
*** src/backend/nodes/outfuncs.c 13 Apr 2008 20:51:20 - 1.325
--- src/backend/nodes/outfuncs.c 28 Apr 2008 17:24:10 -
*** _outAConst(StringInfo str, A_Const *node
*** 1945,1951
appendStringInfo(str, :val );
_outValue(str, (node-val));
! WRITE_NODE_FIELD(typename);
}
static void
--- 1945,1951
appendStringInfo(str, :val );
_outValue(str, (node-val));
! WRITE_INT_FIELD(location);
}
static void
Index: src/backend/parser/gram.y
===
RCS file: /home/alvherre/Code/cvs/pgsql/src/backend/parser/gram.y,v
retrieving revision 2.612
diff -c -p -r2.612 gram.y
*** src/backend/parser/gram.y 14 Apr 2008 17:05:33 - 2.612
--- src/backend/parser/gram.y 28 Apr 2008 19:48:16 -
*** static bool QueryIsRule = FALSE;
*** 91,101
static Node *makeColumnRef(char *relname, List *indirection, int location);
static Node *makeTypeCast(Node *arg, TypeName *typename);
! static Node *makeStringConst(char *str, TypeName *typename);
! static Node *makeIntConst(int val);
! static Node *makeFloatConst(char *str);
! static Node *makeAConst(Value *v);
! static A_Const *makeBoolAConst(bool state);
static FuncCall *makeOverlaps(List *largs, List *rargs, int location);
static void check_qualified_name(List *names);
static List *check_func_name(List *names);
--- 91,102
static Node *makeColumnRef(char *relname, List *indirection, int location);
static Node *makeTypeCast(Node *arg, TypeName *typename);
! static Node *makeStringConst(char *str, int location);
! static Node *makeStringConstCast(char *str, TypeName *typename, int location);
! static Node *makeIntConst(int val, int location);
! static Node *makeFloatConst(char *str, int location);
! static Node *makeAConst(Value *v, int location);
! static Node *makeBoolAConst(bool state, int location);
static FuncCall *makeOverlaps(List *largs, List *rargs, int location);
static void check_qualified_name(List *names);
static List *check_func_name(List *names);
*** set_rest: /* Generic SET syntaxes: */
*** 1112,1118
n-kind = VAR_SET_VALUE;
n-name = client_encoding;
if ($2 != NULL)
! n-args = list_make1(makeStringConst($2, NULL));
else
n-kind = VAR_SET_DEFAULT;
$$ = n;
--- 1113,1119
n-kind = VAR_SET_VALUE;
n-name = client_encoding;
if ($2 != NULL)
! n-args = list_make1(makeStringConst($2, @2));
else
Re: [HACKERS] [PATCHES] Removing typename from A_Const (was: Empty arrays with ARRAY[])
Alvaro Herrera escribió: Tom Lane escribió: Alvaro Herrera [EMAIL PROTECTED] writes: Tom Lane escribió: They're logically different things, and after I get done putting a parse location field into A_Const, they'll still be physically different too. Aha. Are you working from Brendan's patch? I was going to commit it. Sure, go ahead. I was going to add the parse location at the same time, but it can perfectly well be done as a separate patch. I came up with the attached patch. I added the location bits (although I am unsure if I got the locations right in the parser), but they are unused -- figuring out how to use them would take me longer than I can to spend on this. Hmm, I'm now wondering if the location should be added to Value as well, so that it can be passed down to Const? -- Alvaro Herrerahttp://www.CommandPrompt.com/ The PostgreSQL Company - Command Prompt, Inc. -- Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-patches
Re: [HACKERS] [PATCHES] Removing typename from A_Const (was: Empty arrays with ARRAY[])
Alvaro Herrera [EMAIL PROTECTED] writes: I came up with the attached patch. I wasn't envisioning anything anywhere near this invasive. We only need locations on constants in a few contexts, I think. BTW, you broke _equalAConst() ... it was a bad idea anyway to recast it on the assumption that there would never again be more than one field. regards, tom lane -- Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-patches
Re: [HACKERS] [PATCHES] Removing typename from A_Const (was: Empty arrays with ARRAY[])
Tom Lane escribió: Alvaro Herrera [EMAIL PROTECTED] writes: I came up with the attached patch. I wasn't envisioning anything anywhere near this invasive. We only need locations on constants in a few contexts, I think. Aha. OK, I'll commit the original patch and let you deal with the rest of it :-) BTW, you broke _equalAConst() ... it was a bad idea anyway to recast it on the assumption that there would never again be more than one field. Oops, sorry, I had intended to revert that part and forgot. -- Alvaro Herrerahttp://www.CommandPrompt.com/ PostgreSQL Replication, Consulting, Custom Development, 24x7 support -- Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-patches
Re: [HACKERS] [PATCHES] Removing typename from A_Const (was: Empty arrays with ARRAY[])
Alvaro Herrera [EMAIL PROTECTED] writes: Hmm, I'm now wondering if the location should be added to Value as well, so that it can be passed down to Const? Just for the record, we don't want it in Const. Parse locations are only useful in the raw grammar output, mainly because they aren't helpful unless you still have the original query string laying about. regards, tom lane -- Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-patches
Re: [PATCHES] [HACKERS] Proposed patch - psql wraps at window width
I have updated the documentation for this patch. I consider it ready to
apply. I think it is as close to a middle ground as we are going to
get. Further adjustment will have to happen when we have more reports
from the field.
---
Bruce Momjian wrote:
I have moved this discussion to hackers in hopes of getting more
feedback, and moved the patch to a static URL:
ftp://momjian.us/pub/postgresql/mypatches/wrap
This patch adds a new '\pset format wrapped' mode that wraps long values
to fit the table on the user's screen, or in '\pset columns' columns in
an output to file or pipe. The documentation additions are at the top
of the patch.
Sample:
\pset format wrapped
Output format is wrapped.
\pset columns 70
Target column width for wrap format is 70.
SELECT 1, 2, repeat('a', 80), repeat('b', 80), E'a\nb\nc', 1
FROM generate_series(1,2)\g
?column? | ?column? | repeat | repeat| ?column? | ?column?
--+--++-+--+--
1 |2 | aa | bbb | a|1
; aa ; bbb : b
; aa ; bbb : c
; aa ; bbb
; aa ; bbb
; aa ; bbb
; aa ; bbb
; aa ; bbb
1 |2 | aa | bbb | a|1
; aa ; bbb : b
; aa ; bbb : c
; aa ; bbb
; aa ; bbb
; aa ; bbb
; aa ; bbb
; aa ; bbb
(2 rows)
You will notice:
o I have pulled up newline values to appear in the same rows
as the wrapped text
o Colons are used on the left for newline values
o Semicolons are used on the left for wrapped values
o There are no vertical bars for values that don't extend
to the wrapped or newline rows. This is how our
newline display has always worked so it was copied
by the wrapped code
o The left column has no indicator of wrapping or newlines
because there is no left border
We could use dashes to indicated wrapped values, but we don't. It would
be nice if someone could do some multi-byte testing of this,
particularly for characters that have a display width greater than one.
I think this patch is ready for application.
Should 'wrapped' be the default for certain operations, like \df?
'wrapped' mode is really good for a table that would fit the screen
width except for a few wide values.
--
Bruce Momjian [EMAIL PROTECTED]http://momjian.us
EnterpriseDB http://enterprisedb.com
+ If your life is a hard drive, Christ can be your backup. +
Index: doc/src/sgml/ref/psql-ref.sgml
===
RCS file: /cvsroot/pgsql/doc/src/sgml/ref/psql-ref.sgml,v
retrieving revision 1.199
diff -c -c -r1.199 psql-ref.sgml
*** doc/src/sgml/ref/psql-ref.sgml 30 Mar 2008 18:10:20 - 1.199
--- doc/src/sgml/ref/psql-ref.sgml 29 Apr 2008 01:24:44 -
***
*** 1513,1519
listitem
para
Sets the output format to one of literalunaligned/literal,
! literalaligned/literal, literalhtml/literal,
literallatex/literal, or literaltroff-ms/literal.
Unique abbreviations are allowed. (That would mean one letter
is enough.)
--- 1513,1520
listitem
para
Sets the output format to one of literalunaligned/literal,
! literalaligned/literal, literalwrapped/literal,
! literalhtml/literal,
literallatex/literal, or literaltroff-ms/literal.
Unique abbreviations are allowed. (That would mean one letter
is enough.)
***
*** 1525,1531
is intended to create output that might be intended to be read
in by other programs (tab-separated, comma-separated).
quoteAligned/quote mode is the standard, human-readable,
! nicely formatted text output that is default.
Re: [PATCHES] [HACKERS] Proposed patch - psql wraps at window width
Bruce Momjian wrote: I have updated the documentation for this patch. I consider it ready to apply. I think it is as close to a middle ground as we are going to get. Further adjustment will have to happen when we have more reports from the field. I heard a pretty compelling argument to make wrapped part of aligned, and thus I think the patch is ready to go only after adjusting the user-facing syntax: \pset border 2 \pset format aligned Output format is aligned, no wrapping. \pset format aligned autowrap Output format is aligned, with automatic wrapping to the window width for terminals. \pset format aligned 80 Output format is aligned, with a target width of 80 characters. \a Output format is unaligned, no wrapping. \a Output format is aligned, with a target width of 80 characters. If the wrapping code can't fit the column headings in the wrap width, it gives up and produces aligned output. To do otherwise is totally unreadable. Please give the patch a try, before complaining about this particular aspect of it. -- Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-patches
