On Sat, Mar 17, 2012 at 05:28:11PM -0700, Daniel Farina wrote:
Noah offered me these comments:
This patch still changes the policy for pg_terminate_backend(), and it does
not fix other SIGINT senders like processCancelRequest() and ProcSleep().
?If
you're concerned about PID-reuse races,
On Mon, Mar 19, 2012 at 09:49:32PM +0200, Peter Eisentraut wrote:
On m??n, 2012-03-19 at 02:35 +, Peter Geoghegan wrote:
I see your point of view. I suppose I can privately hold onto the test
suite, since it might prove useful again.
I would still like to have those tests checked in,
On Mon, Mar 19, 2012 at 06:41:39PM +0100, Marco Nenciarini wrote:
Attached is v5, which should address all the remaining issues.
Looks clean to me.
On Fri, Mar 16, 2012 at 11:33:12PM -0400, Noah Misch wrote:
If the cost doesn't exceed O(F log P), where F is the size of the FK table
On Thu, Dec 09, 2010 at 09:48:25AM +, Simon Riggs wrote:
On Fri, 2010-12-03 at 21:43 +0200, Heikki Linnakangas wrote:
On 29.11.2010 08:10, Noah Misch wrote:
I have a hot_standby system and use it to bear the load of various
reporting
queries that take 15-60 minutes each
When the caller knows the smaller string length, memcmp and strncmp are
functionally equivalent. Since memcmp need not watch each byte for a NULL
terminator, it often compares a CPU word at a time for better performance. The
attached patch changes use of strncmp to memcmp where we have the
texteq, textne, byteaeq and byteane detoast their arguments, then check for
equality of length. Unequal lengths imply the answer trivially; given equal
lengths, the functions proceed to compare the actual bytes. We can skip
detoasting entirely when the lengths are unequal. The attached patch
On Tue, Dec 21, 2010 at 10:15:41PM -0500, Robert Haas wrote:
A little benchmarking reveals that on my system (MacOS X 10.6.5) it
appears that strncmp() is faster for a 4 character string, but
memcmp() is faster for a 5+ character string.
Good call; I hadn't considered that possibility.
So I
ALTER TABLE ALTER TYPE always rewrites the table heap and its indexes. In some
cases, we can determine that doing so is unhelpful, and that the conversion
shall always succeed:
CREATE DOMAIN loosedom AS text;
CREATE TABLE t (c varchar(2));
ALTER TABLE t ALTER c TYPE varchar(4);
ALTER TABLE t
On Wed, Dec 29, 2010 at 10:56:39AM -0500, Robert Haas wrote:
On Dec 29, 2010, at 7:56 AM, Noah Misch n...@leadboat.com wrote:
Having thought on it
more, though, it actually seems best to attempt the verification scan
*every*
time. In most ineligible conversions, an inequality
On Wed, Dec 29, 2010 at 11:16:23AM -0500, Tom Lane wrote:
Noah Misch n...@leadboat.com writes:
ALTER TABLE ALTER TYPE always rewrites the table heap and its indexes. In
some
cases, we can determine that doing so is unhelpful, and that the conversion
shall always succeed:
I wish
On Wed, Dec 29, 2010 at 02:01:28PM -0500, Tom Lane wrote:
Robert Haas robertmh...@gmail.com writes:
On Dec 29, 2010, at 11:16 AM, Tom Lane t...@sss.pgh.pa.us wrote:
I really really dislike the notion of a verification scan: it's
basically work that is going to be useless if it fails.
I
On Wed, Dec 29, 2010 at 11:14:37PM -0500, Robert Haas wrote:
On Wed, Dec 29, 2010 at 6:46 PM, Noah Misch n...@leadboat.com wrote:
Perhaps. ?A few kooky rows is indeed common, but we're talking about a
specific
breed of kookiness: 99.9% of the rows have identical bits after an ALTER
TYPE
On Thu, Dec 30, 2010 at 12:57:45AM -0500, Robert Haas wrote:
On Thu, Dec 30, 2010 at 12:24 AM, Noah Misch n...@leadboat.com wrote:
On Wed, Dec 29, 2010 at 11:14:37PM -0500, Robert Haas wrote:
I think for any pair of types (T1, T2) we should first determine
whether we can skip the scan
On Fri, Dec 31, 2010 at 12:34:50AM -0500, Robert Haas wrote:
On Thu, Dec 30, 2010 at 8:35 PM, Noah Misch n...@leadboat.com wrote:
4. A FuncExpr node has answers given by the bitwise-AND of its funcexempt
field
and the answers from its first argument.
Why its first argument?
funcexempt
On Mon, Jan 03, 2011 at 10:23:03PM -0500, Robert Haas wrote:
Can you add this to the currently-open CommitFest, so we don't lose track of
it?
https://commitfest.postgresql.org/action/commitfest_view/open
Done.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make
Hi Pavel,
On Tue, Jan 04, 2011 at 03:13:11PM +0100, Pavel Stehule wrote:
I looked on patch
Thanks.
does work toast_raw_datum_size on packed varlena corectly?
Yes, as best I can tell.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
On Thu, Dec 30, 2010 at 08:35:34PM -0500, Noah Misch wrote:
On Thu, Dec 30, 2010 at 12:57:45AM -0500, Robert Haas wrote:
On Thu, Dec 30, 2010 at 12:24 AM, Noah Misch n...@leadboat.com wrote:
On Wed, Dec 29, 2010 at 11:14:37PM -0500, Robert Haas wrote:
I think for any pair of types (T1, T2
On Thu, Jan 06, 2011 at 12:24:19AM -0500, Robert Haas wrote:
I still think you're better off focusing first on the case where we
can skip the whole nine yards, and doing this stuff as a follow-on
patch. Trying to do too many things, especially possibly
controversial stuff, especially in the
When ALTER TABLE rewrites a table, it reindexes, but the reindex does not
revalidate UNIQUE/EXCLUDE constraints. This behaves badly in cases like this,
neglecting to throw an error on the new UNIQUE violation:
CREATE TABLE t (c numeric UNIQUE);
INSERT INTO t VALUES (1.1),(1.2);
ALTER TABLE t
This patch removes ALTER TYPE rewrites in cases we can already prove valid. I
add a function GetCoerceExemptions() that walks an Expr according to rules
discussed in the design thread, simplified slightly pending additions in the
next patch. See the comment at that function for a refresher. I
Add exemptor functions to avoid rewrites for conversions involving the temporal
data types. I needed a find-last-set function for the interval_scale exemptor
function, so I imported one from FreeBSD. To improve timestamp-timestamptz
when the timezone is UTC/GMT, I compare the current timezone
Add exemptor functions for bit and varbit. These are probably the simplest
examples of the full range of optimizations. I would have used them as the test
case in the initial exemptor function patch if it were a more mainstream use
case.
*** a/src/backend/utils/adt/varbit.c
---
Add an exemptor function for numeric. We store the scale in every datum, making
numeric(7,2)-numeric(8,3) unoptimizable. Precision changes work, though.
*** a/src/backend/utils/adt/numeric.c
--- b/src/backend/utils/adt/numeric.c
***
*** 712,717 numeric_send(PG_FUNCTION_ARGS)
---
On Tue, Jan 11, 2011 at 09:24:46AM +, Simon Riggs wrote:
On Sun, 2011-01-09 at 16:59 -0500, Noah Misch wrote:
This begins the patch series for the design I recently proposed[1] for
avoiding
some table rewrites in ALTER TABLE ... ALTER COLUMN ... TYPE. I'm posting
these
patches
On Tue, Jan 11, 2011 at 06:37:33AM -0500, Robert Haas wrote:
On Sun, Jan 9, 2011 at 4:59 PM, Noah Misch n...@leadboat.com wrote:
This begins the patch series for the design I recently proposed[1] for
avoiding
some table rewrites in ALTER TABLE ... ALTER COLUMN ... TYPE. ?I'm posting
On Tue, Jan 11, 2011 at 12:37:28PM +, Simon Riggs wrote:
On Tue, 2011-01-11 at 07:14 -0500, Noah Misch wrote:
These changes do make it harder to guess how much work the ALTER TABLE
will do. Indeed, about 1/4 of my own guesses prior to writing were
wrong. Something like WITHOUT
On Tue, Jan 11, 2011 at 07:27:46AM -0500, Robert Haas wrote:
On Tue, Jan 11, 2011 at 7:14 AM, Noah Misch n...@leadboat.com wrote:
True. ?At least we could completely document the lock choices on the ALTER
TABLE
reference page. ?The no-rewrite cases are defined at arms length from ALTER
On Tue, Jan 11, 2011 at 01:17:23PM +, Simon Riggs wrote:
On Tue, 2011-01-11 at 08:06 -0500, Noah Misch wrote:
On Tue, Jan 11, 2011 at 12:37:28PM +, Simon Riggs wrote:
Given your thoughts above, my preference would be for
EXPLAIN ALTER TABLE to describe the actions that will take
On Tue, Jan 11, 2011 at 09:41:35PM -0500, Robert Haas wrote:
On Tue, Jan 11, 2011 at 7:25 AM, Noah Misch n...@leadboat.com wrote:
On Tue, Jan 11, 2011 at 06:37:33AM -0500, Robert Haas wrote:
On Sun, Jan 9, 2011 at 4:59 PM, Noah Misch n...@leadboat.com wrote:
This begins the patch series
On Tue, Jan 11, 2011 at 10:03:11PM -0500, Robert Haas wrote:
On Sun, Jan 9, 2011 at 5:00 PM, Noah Misch n...@leadboat.com wrote:
When ALTER TABLE rewrites a table, it reindexes, but the reindex does not
revalidate UNIQUE/EXCLUDE constraints. ?This behaves badly in cases like
Hello Joachim,
I'm reviewing this patch for CommitFest 2011-01.
On Fri, Jan 07, 2011 at 06:41:38AM -0500, Joachim Wieland wrote:
On Thu, Dec 30, 2010 at 7:31 AM, Joachim Wieland j...@mcknight.de wrote:
What I am proposing now is the following:
We return snapshot information as a chunk of
and more objects are reported as rebuilt.
If this looks sane, I'll rebase the rest of the patches accordingly.
On Tue, Jan 11, 2011 at 09:41:35PM -0500, Robert Haas wrote:
On Tue, Jan 11, 2011 at 7:25 AM, Noah Misch n...@leadboat.com wrote:
I'm wondering if we should consider moving this call
On Sat, Jan 15, 2011 at 08:57:30AM -0500, Robert Haas wrote:
On Sat, Jan 15, 2011 at 1:30 AM, Noah Misch n...@leadboat.com wrote:
Here's v2 based on your feedback.
I pruned test coverage down to just the highlights. ?By the end of patch
series,
the net change becomes +67
Hello Pavel,
I'm reviewing this patch for CommitFest 2011-01.
The patch seems fully desirable. It appropriately contains no documentation
updates. It contains no new tests, and that's probably fine, too; I can't think
of any corner cases where this would do something other than work correctly
On Sat, Jan 15, 2011 at 02:31:21PM -0500, Robert Haas wrote:
On Sat, Jan 15, 2011 at 10:25 AM, Noah Misch n...@leadboat.com wrote:
Do you value test coverage so little?
If you're asking whether I think real-world usability is more
important than test coverage, then yes.
No, I wasn't asking
On Sun, Jan 16, 2011 at 12:07:44PM -0500, Tom Lane wrote:
Robert Haas robertmh...@gmail.com writes:
On Sat, Jan 15, 2011 at 10:25 AM, Noah Misch n...@leadboat.com wrote:
Do you value test coverage so little?
If you're asking whether I think real-world usability is more
important than
On Sun, Jan 16, 2011 at 06:49:27PM +0100, Pavel Stehule wrote:
I am sending a updated version with little bit more comments. But I am
sure, so somebody with good English have to edit my comments.
Minimally I hope, so your questions will be answered.
Thanks. I edited the comments and white
On Sun, Jan 16, 2011 at 01:05:11PM -0600, Andy Colson wrote:
This is a review of:
https://commitfest.postgresql.org/action/patch_view?id=468
Thanks!
I created myself a more real world test, with a table with indexes and id's
and a large toasted field.
This will make about 600 records
On Sun, Jan 16, 2011 at 10:07:13PM +0100, Pavel Stehule wrote:
I think, so we can have a function or macro that compare a varlena
sizes. Some like
Datum texteq(..)
{
if (!datumsHasSameLength(PG_GETARG_DATUM(0), PG_GETARG_DATUM(1))
PG_RETURN_FALSE();
... actual code ..
On Mon, Jan 17, 2011 at 07:35:52AM +0100, Magnus Hagander wrote:
On Mon, Jan 17, 2011 at 06:51, Itagaki Takahiro
itagaki.takah...@gmail.com wrote:
On Mon, Jan 17, 2011 at 04:05, Andy Colson a...@squeakycode.net wrote:
This is a review of:
On Mon, Jan 17, 2011 at 11:05:09AM +0100, Magnus Hagander wrote:
On Mon, Jan 17, 2011 at 09:13, Itagaki Takahiro
itagaki.takah...@gmail.com wrote:
2011/1/17 KaiGai Kohei kai...@ak.jp.nec.com:
Are you talking about an idea to apply toast id as an alternative key?
No, probably. I'm just
On Mon, Jan 17, 2011 at 02:36:56PM -0600, Jim Nasby wrote:
On Jan 17, 2011, at 9:22 AM, Noah Misch wrote:
Just to be clear, the code already has these length tests today. This patch
just moves them before the detoast.
Any reason we can't do this for other varlena? I'm wondering
On Wed, Jan 19, 2011 at 12:10:16PM -0500, Tom Lane wrote:
Robert Haas robertmh...@gmail.com writes:
On Tue, Jan 18, 2011 at 5:22 PM, Pavel Stehule pavel.steh...@gmail.com
wrote:
opinion isn't strong in this topic. One or twenty useless detoasting
isn't really significant in almost use
Hi Simon,
I'm reviewing this patch for CommitFest 2011-01.
On Sat, Jan 15, 2011 at 10:02:03PM +, Simon Riggs wrote:
On Tue, 2010-12-14 at 19:48 +, Simon Riggs wrote:
REPLACE TABLE ying WITH yang
Patch. Needs work.
First, I'd like to note that the thread for this patch had *four*
On Thu, Jan 20, 2011 at 12:57:23AM +, Simon Riggs wrote:
On Wed, 2011-01-19 at 17:46 -0500, Noah Misch wrote:
I'll go ahead and mark the patch Returned with Feedback.
My understanding of the meaning of that is polite rejection. If you do
that there is no further author comment and we
On Wed, Jan 19, 2011 at 08:55:22PM -0500, Robert Haas wrote:
On Wed, Jan 19, 2011 at 7:57 PM, Simon Riggs si...@2ndquadrant.com wrote:
On Wed, 2011-01-19 at 17:46 -0500, Noah Misch wrote:
I'll go ahead and mark the patch Returned with Feedback.
My understanding of the meaning
On Wed, Jan 19, 2011 at 11:50:12PM -0500, Robert Haas wrote:
On Wed, Jan 12, 2011 at 8:56 AM, Robert Haas robertmh...@gmail.com wrote:
On Wed, Jan 12, 2011 at 8:14 AM, Noah Misch n...@leadboat.com wrote:
Something like the attached?
I haven't really analyzed in this detail, but yes
an assertion failure with this sequence:
BEGIN; SELECT pg_export_snapshot(); ROLLBACK;
SELECT 1;
TRAP: FailedAssertion(!(RegisteredSnapshots 0), File: snapmgr.c, Line:
430)
Perhaps some cleanup is missing from a ROLLBACK path?
On Fri, Jan 14, 2011 at 10:13 PM, Noah Misch n...@leadboat.com
On Thu, Jan 20, 2011 at 10:07:23AM +, Simon Riggs wrote:
On Wed, 2011-01-19 at 17:46 -0500, Noah Misch wrote:
First, I'd like to note that the thread for this patch had *four* me-too
responses to the use case. That's extremely unusual; the subject is
definitely
compelling
On Thu, Jan 20, 2011 at 09:26:29AM -0500, Robert Haas wrote:
My main beef with the Boolean flags is that this kind of thing is not too
clear:
reindex_relation(myrel, false, false, true, true, false, true,
false, false, true);
Unless you have an excellent memory, you can't tell what
On Thu, Jan 20, 2011 at 09:36:11PM +, Simon Riggs wrote:
I agree that the DDL behaviour is wrong and should be fixed. Thank you
for championing that alternative view.
Swapping based upon names only works and is very flexible, much more so
than EXCHANGE could be.
A separate utility
On Sun, Jan 23, 2011 at 12:06:43PM -0500, Tom Lane wrote:
Robert Haas robertmh...@gmail.com writes:
On Sun, Jan 9, 2011 at 5:01 PM, Noah Misch n...@leadboat.com wrote:
As unintended fallout, it's no longer an error to add oids or a column
with a
default value to a table whose rowtype
On Sat, Jan 22, 2011 at 11:32:02AM +0100, Pavel Stehule wrote:
because I am not sure so any complex solution can be done to deadline
for 9.1, I created a patch that is based on Tom ideas - just
explicitly detoast function parameters.
I can confirm that, for your original test case, this yields
On Mon, Jan 24, 2011 at 07:18:47PM -0500, Robert Haas wrote:
On Sun, Jan 9, 2011 at 5:03 PM, Noah Misch n...@leadboat.com wrote:
Here I add the notion of an exemptor function, a property of a cast that
determines when calls to the cast would be superfluous. ?Such calls can be
removed
On Tue, Jan 25, 2011 at 06:40:08PM -0500, Robert Haas wrote:
On Mon, Jan 24, 2011 at 7:10 PM, Noah Misch n...@leadboat.com wrote:
* at1.1-default-composite.patch
Remove the error when the user adds a column with a default value to a table
whose rowtype is used in a column elsewhere.
Can
On Wed, Jan 26, 2011 at 12:35:07AM +0200, Peter Eisentraut wrote:
On tis, 2011-01-25 at 10:14 +0900, Itagaki Takahiro wrote:
and I have an almost empty pg_collation catalog with it:
=# SELECT * FROM pg_collation;
collname | collnamespace | collencoding | collcollate | collctype
On Wed, Jan 26, 2011 at 05:55:37PM -0500, Tom Lane wrote:
I wrote:
... Another issue is that premature
optimization in the parser creates headaches if conditions change such
that a previous optimization is no longer valid --- you may have stored
rules wherein the optimization was already
On Wed, Jan 26, 2011 at 05:32:00PM -0500, Tom Lane wrote:
Robert Haas robertmh...@gmail.com writes:
Well, if you're positive we're eventually going to want this in
pg_proc, we may as well add it now. But I'm not too convinced it's
the right general API. The number of people writing
On Wed, Jan 26, 2011 at 06:29:57PM -0500, Tom Lane wrote:
Noah Misch n...@leadboat.com writes:
If we hook this into eval_const_expressions, it definitely seems
cleaner to attach the auxiliary function to the pg_proc. Otherwise,
we'd reconstruct which cast led to each function call
On Wed, Jan 26, 2011 at 07:44:43PM -0500, Tom Lane wrote:
numeric(8,2) - numeric(7,2)
varbit(8) - varbit(7)
text - xml
But how often do those really come up?
I'll speak from my own experience, having little idea of the larger community
experience on this one. I usually don't even
On Wed, Jan 26, 2011 at 07:52:10PM -0500, Tom Lane wrote:
Noah Misch n...@leadboat.com writes:
text - xml
BTW, that reminds me of something that I think was mentioned way back
when, but absolutely fails to fit into any of the frameworks discussed
here: the mere fact that a type is binary
On Wed, Jan 26, 2011 at 09:35:24AM -0500, Robert Haas wrote:
On Mon, Jan 24, 2011 at 11:13 PM, Noah Misch n...@leadboat.com wrote:
This helps on conversions like varchar(4)-varchar(8) and text-xml.
I've read through this patch somewhat. ?As I believe Tom also
commented previously
On Thu, Jan 27, 2011 at 09:02:26AM -0500, Robert Haas wrote:
OK. I was thinking that instead moving this into
eval_const_expressions(), we just make the logic in
find_coercion_pathway() call the exemptor function (or whatever we
call it) right around here:
switch
On Wed, Jan 26, 2011 at 07:31:40AM -0500, Robert Haas wrote:
I'd also suggest that this big if-block you changed to a case
statement could just as well stay as an if-block. There are only
three cases, and we want to avoid rearranging things more than
necessary. It complicates both review and
On Fri, Jan 28, 2011 at 01:52:32PM -0500, Robert Haas wrote:
On Wed, Jan 26, 2011 at 6:06 PM, Tom Lane t...@sss.pgh.pa.us wrote:
I'm not sure how important that concern is though, because it's hard to
see how any such change wouldn't break existing cast implementation
functions anyway. ?If
Hi Peter,
I'm reviewing this patch as part of CommitFest 2011-01.
On Fri, Jan 14, 2011 at 11:41:46PM +0200, Peter Eisentraut wrote:
I've been going over this patch with a fine-tooth comb for the last two
weeks, fixed some small bugs, added comments, made initdb a little
friendlier, but no
On Fri, Jan 28, 2011 at 04:49:39PM -0500, Noah Misch wrote:
On Fri, Jan 28, 2011 at 01:52:32PM -0500, Robert Haas wrote:
On Wed, Jan 26, 2011 at 6:06 PM, Tom Lane t...@sss.pgh.pa.us wrote:
I'm not sure how important that concern is though, because it's hard to
see how any such change
On Sun, Jan 30, 2011 at 12:36:12PM -0500, Joachim Wieland wrote:
Here is a new version of the patch incorporating most of Noah's
suggestions. The patch now also adds documentation. Since I couldn't
really find a suitable section to document the two new functions, I
added a new one for now. Any
On Wed, Feb 02, 2011 at 11:20:44PM +0200, Peter Eisentraut wrote:
On l??r, 2011-01-29 at 02:52 -0500, Noah Misch wrote:
The new documentation is helpful. It would be useful to document the
implications of marking your user-defined type COLLATABLE. As best I can
tell,
you should only
On Thu, Feb 03, 2011 at 05:53:28PM +0200, Peter Eisentraut wrote:
On tor, 2011-02-03 at 00:10 -0500, Noah Misch wrote:
This is good stuff. I'll send you a new patch in a day or three for
perhaps another round of performance tests. Some of the other
issues
above can perhaps
Robert,
Thanks for the obviously thought-out review.
On Sat, Feb 05, 2011 at 01:29:35AM -0500, Robert Haas wrote:
On Thu, Jan 27, 2011 at 2:48 PM, Noah Misch n...@leadboat.com wrote:
Done as attached. ?This preserves compatibility with our current handling of
composite type dependencies
On Mon, Jan 17, 2011 at 06:33:08PM -0600, Kevin Grittner wrote:
Itagaki Takahiro wrote:
Shigeru HANADA wrote:
Attached patch would avoid this leak by adding per-copy context to
CopyState. This would be overkill, and ResetCopyFrom() might be
reasonable though.
Good catch. I merged
On Sat, Feb 05, 2011 at 10:03:59AM -0500, Robert Haas wrote:
Looking at this still more, it appears that independent of any change
this patch may wish to make, there's a live bug here related to the
foreign table patch I committed back in December. Creating a foreign
table creates an
On Sun, Feb 06, 2011 at 02:15:47AM -0500, Robert Haas wrote:
On Sat, Feb 5, 2011 at 7:44 PM, Noah Misch n...@leadboat.com wrote:
But this is a little unsatisfying, for two reasons. ?First, the error
message will be subtly wrong: we can make it complain about a table or
a type
Let's see if I can summarize the facts we've collected so far. I see four
options based on the discussion:
1. Add PLpgSQL_var.should_be_detoasted; check it in plpgsql_param_fetch().
Essentially Pavel's original patch, only with the check logic moved up from
exec_eval_datum() to
On Sun, Feb 06, 2011 at 07:54:52AM -0500, Robert Haas wrote:
On Sun, Feb 6, 2011 at 4:15 AM, Noah Misch n...@leadboat.com wrote:
That didn't quite work, because there's a caller in typecmds.c that
doesn't have the relation handy. ?So I made it take a relkind and a
name, which works fine
On Sun, Feb 06, 2011 at 08:15:30AM -0500, Robert Haas wrote:
On Sun, Feb 6, 2011 at 5:52 AM, Noah Misch n...@leadboat.com wrote:
1. Add PLpgSQL_var.should_be_detoasted; check it in plpgsql_param_fetch().
Essentially Pavel's original patch, only with the check logic moved up from
On Sun, Feb 06, 2011 at 08:40:44AM -0500, Noah Misch wrote:
On Sun, Feb 06, 2011 at 07:54:52AM -0500, Robert Haas wrote:
Yeeah, that's actually a little ugly. It's actually a domain
over a composite type, not a composite type proper, IIUC. Better
ideas?
There are no domains over
On Sun, Feb 06, 2011 at 12:54:19PM -0500, Robert Haas wrote:
On Sun, Feb 6, 2011 at 12:13 PM, Robert Haas robertmh...@gmail.com wrote:
That's not quite so good for translators, I think.
Another option is that we could just say relation (table, foreign
table, etc...) or type. ?We use the
On Mon, Feb 07, 2011 at 12:04:02AM -0500, Robert Haas wrote:
On Sun, Feb 6, 2011 at 8:18 PM, Noah Misch n...@leadboat.com wrote:
Or how about passing an ObjectType? ?Then we could specify
OBJECT_TABLE, OBJECT_FOREIGN_TABLE, or OBJECT_TYPE.
Could this be done without a several-line blob
On Mon, Feb 07, 2011 at 03:39:39PM +0900, Itagaki Takahiro wrote:
On Sun, Feb 6, 2011 at 09:01, Noah Misch n...@leadboat.com wrote:
Most parse analysis-type bits of DoCopy() move to BeginCopy().
It would be possible to move more FROM-only or TO-only members in BeginCopy
Suppose you create several file_fdw foreign tables, query them together, and
read(2) returns EIO for one of the files:
[local] postgres=# SELECT * FROM ft0, ft1, ft2;
ERROR: could not read from COPY file: Input/output error
The message does not show which foreign table yielded the error. We
On Mon, Feb 07, 2011 at 11:16:18PM -0500, Robert Haas wrote:
So
can we just get rid of should_be_detoasted, and have exec_eval_datum()
or its callers instead test:
!var-isnull var-datatype-typbyval var-datatype-typlen == -1
VARATT_IS_EXTENDED(var-value)
FWIW, this is what I meant by
On Tue, Feb 08, 2011 at 08:00:42AM +0100, Pavel Stehule wrote:
2011/2/8 Noah Misch n...@leadboat.com:
On Mon, Feb 07, 2011 at 11:16:18PM -0500, Robert Haas wrote:
So
can we just get rid of should_be_detoasted, and have exec_eval_datum()
or its callers instead test:
!var-isnull var
On Tue, Feb 08, 2011 at 10:24:03AM -0500, Robert Haas wrote:
Well, Pavel's subsequent reply suggested that he didn't test exactly
this thing, so maybe there's hope.
No hope on that basis, no.
Or maybe not. If Tom thought one branch inside exec_eval_datum() was
going to be too expensive,
code in NextCopyFrom().
On Mon, Feb 7, 2011 at 21:16, Noah Misch n...@leadboat.com wrote:
Perhaps I'm missing something. ??The new API does not expose a processed
count
at all; that count is used for the command tag of a top-level COPY. ??This
part
of the patch is just changing how we
On Wed, Feb 09, 2011 at 02:55:26PM +0900, Itagaki Takahiro wrote:
On Wed, Feb 9, 2011 at 03:49, Noah Misch n...@leadboat.com wrote:
The code still violates the contract of ExecEvalExpr() by calling it with
CurrentMemoryContext != econtext-ecxt_per_tuple_memory.
I'm not sure whether we have
On Thu, Feb 10, 2011 at 12:03:49AM -0500, Tom Lane wrote:
strk s...@keybit.net writes:
I've finally completed the debugging phase and have
a minimal self-contained testcase showing the problem.
It has to do with INITIALLY DEFERRED constraints.
I looked into this and find that the issue
On Sat, Feb 05, 2011 at 10:59:45PM +0100, Rados??aw Smogura wrote:
I do performance tests against orignal JDBC driver and my version in binary
and in text mode. I saw strange results when I was reading varchar values.
Here is some output from simple benchmark
Plain strings speed
[Cc: trimmed]
On Wed, Feb 09, 2011 at 01:45:11PM -0500, Robert Haas wrote:
A few other ones that could use more reviewers include:
key locks
I'll take a look at this one.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
On Thu, Feb 10, 2011 at 06:56:15PM +0900, Itagaki Takahiro wrote:
On Mon, Feb 7, 2011 at 04:10, Stephen Frost sfr...@snowman.net wrote:
I agree that it's logically good design, but we could not accept it
as long as it breaks tools in the real world...
If it does, I think it's pretty clear
On Thu, Nov 15, 2012 at 02:33:21PM +0900, Shigeru Hanada wrote:
On Sat, Oct 20, 2012 at 4:24 PM, Kohei KaiGai kai...@kaigai.gr.jp wrote:
IIRC, the reason why postgresql_fdw instead of pgsql_fdw was
no other fdw module has shorten naming such as ora_fdw for
Oracle.
However, I doubt whether
On Wed, Nov 14, 2012 at 01:27:26PM -0300, Alvaro Herrera wrote:
https://github.com/alvherre/postgres/commit/df2847e38198e99f57e52490e1e9391ebb70d770
(I don't think this is worth a v24 submission).
Are you aware of any defects in or unanswered questions of this version that
would stall your
On Fri, Nov 16, 2012 at 05:31:12PM +0100, Andres Freund wrote:
On 2012-11-16 13:17:47 -0300, Alvaro Herrera wrote:
Andres is on the verge of convincing me that we need to support
singleton FOR SHARE without multixacts due to performance concerns.
I don't really see any arguments against
On Sat, Nov 17, 2012 at 03:20:20PM +0100, Andres Freund wrote:
On 2012-11-16 22:31:51 -0500, Noah Misch wrote:
On Fri, Nov 16, 2012 at 05:31:12PM +0100, Andres Freund wrote:
On 2012-11-16 13:17:47 -0300, Alvaro Herrera wrote:
Andres is on the verge of convincing me that we need
On Sat, Nov 17, 2012 at 05:07:18PM +0100, Andres Freund wrote:
I agree that tripling FOR SHARE cost is risky. Where is the added cost
concentrated? Perchance that multiple belies optimization opportunities.
Good question, let me play a bit.
Ok, I benchmarked around and from what I
On Thu, Nov 29, 2012 at 03:33:59PM -0500, Tom Lane wrote:
I wrote:
So far as I can see, none of the spec-defined EAI_XXX codes map very
nicely to path name too long. Possibly we could return EAI_SYSTEM
and set errno to ENAMETOOLONG, but I'm not sure the latter is very
portable either.
On Sat, Dec 01, 2012 at 07:34:51PM +0100, Andres Freund wrote:
On 2012-12-01 18:27:08 +, Simon Riggs wrote:
On 1 December 2012 16:38, Tom Lane t...@sss.pgh.pa.us wrote:
Simon Riggs si...@2ndquadrant.com writes:
It's hard to know whether your tables will be locked for long periods
On Mon, Dec 03, 2012 at 11:37:17AM +0100, Dimitri Fontaine wrote:
Noah Misch n...@leadboat.com writes:
Acquiring the lock could still take an unpredictable amount of time.
I think there's a new GUC brewing about setting the lock timeout
separately from the statement timeout, right?
Yes
On Mon, Dec 03, 2012 at 01:14:30PM -0500, Andrew Dunstan wrote:
I think it would be reasonable for it to complain if it came across a
PG_VERSION file in an unexpected location.
That sounds like a reliable approach to detecting the hazard. Pseudocode:
chdir(proposed_tablespace_path)
101 - 200 of 1905 matches
Mail list logo
