Hi,
with the FOR e IN SELECT UNNEST(a) construct there is an issue again related
to the unresting of composite type arrays:
BEGIN;
CREATE TYPE truple AS (i integer, a text, b text);
DO $SQL$
DECLARE
start_time timestamp;
t truple;
ta truple[] := ARRAY( select ROW(s.i, 'A' || (s.i)::text,
On Tue, Oct 5, 2010 at 17:21, Craig Ringer cr...@postnewspapers.com.au wrote:
OK, it's pretty much ready for proper testing now. If a few people are happy
with the results and think it's a good idea I'll chuck it in the commitfest
app.
As built, the crash dump handler works with a stock
On 21.11.2010 15:18, Robert Haas wrote:
On Sat, Nov 20, 2010 at 4:07 PM, Tom Lanet...@sss.pgh.pa.us wrote:
Robert Haasrobertmh...@gmail.com writes:
So what DO we need to guard against here?
I think the general problem can be stated as process A changes two or
more values in shared memory
format() function is very useful to construct formatted text,
but it doesn't support embedded formatter unlike sprintf() in C.
Of course, we can use to_char() functions for each argument value,
but embedded formatter would be more readable.
I'd like to propose %{...}s syntax, where
On Mon, Nov 15, 2010 at 03:33, Greg Stark st...@mit.edu wrote:
This is an update to my earlier patch to add getrusage resource
tracking to EXPLAIN ANALYZE.
With this patch you get something like:
QUERY PLAN
Hello
this patch remove a multiple detoasting of varlena values in plpgsql.
It is usable mainly for iteration over longer array directly loaded
from relation.
It's doesn't have a impact on semantic or behave - it's just eliminate
some performance trap.
sample: table 1 rows one column with
Hello
There is little bit complication. There are no one to_char function
- so you cannot to use DirectFunctionCall API.
but I am not against to this proposal.
regards
Pavel
2010/11/22 Itagaki Takahiro itagaki.takah...@gmail.com:
format() function is very useful to construct formatted text,
On 11/22/2010 07:46 AM, Pavel Stehule wrote:
Hello
this patch remove a multiple detoasting of varlena values in plpgsql.
It is usable mainly for iteration over longer array directly loaded
from relation.
It's doesn't have a impact on semantic or behave - it's just eliminate
some performance
2010/11/22 Andrew Dunstan and...@dunslane.net:
On 11/22/2010 07:46 AM, Pavel Stehule wrote:
Hello
this patch remove a multiple detoasting of varlena values in plpgsql.
It is usable mainly for iteration over longer array directly loaded
from relation.
It's doesn't have a impact on
Excerpts from David Fetter's message of dom nov 21 21:17:12 -0300 2010:
Given its small and isolated nature, I was hoping we could get this in
sooner rather than later. As I understand it, CFs are there to review
patches that take significant effort for even a committer to
understand, so
On Wed, Nov 17, 2010 at 7:08 PM, Jaime Casanova ja...@2ndquadrant.com wrote:
On Thu, Sep 30, 2010 at 7:46 AM, Pavel Stehule pavel.steh...@gmail.com
wrote:
Hello
this patch implement a new iteration construct - iteration over an
array. The sense of this new iteration is:
* a simple and
On Mon, Nov 22, 2010 at 6:37 AM, Magnus Hagander mag...@hagander.net wrote:
Do we want to backpatch it into contrib/? Adding a new module there
seems kind of wrong - probably better to keep the source separate and
just publish the DLL files for people who do debugging?
If this works without
On Mon, Nov 22, 2010 at 6:21 AM, Valentine Gogichashvili
val...@gmail.com wrote:
Hi,
with the FOR e IN SELECT UNNEST(a) construct there is an issue again related
to the unresting of composite type arrays:
[ example ]
Is it a bug or a feature?
It looks like the problem in this example is that
On Mon, Nov 22, 2010 at 8:39 AM, Jaime Casanova ja...@2ndquadrant.com wrote:
On Wed, Nov 17, 2010 at 7:08 PM, Jaime Casanova ja...@2ndquadrant.com wrote:
On Thu, Sep 30, 2010 at 7:46 AM, Pavel Stehule pavel.steh...@gmail.com
wrote:
Hello
this patch implement a new iteration construct -
On Sat, Nov 20, 2010 at 9:00 AM, Steve Singer ssinger...@sympatico.cawrote:
Submission Review:
Tests
The expected output for the regression tests you added don't match
what I'm getting when I run the tests with your patch applied.
I think you just need
On Mon, Nov 22, 2010 at 12:40 PM, Magnus Hagander mag...@hagander.net wrote:
I tried building this under windows, and got a bunch of errors.
Thanks!
--
greg
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
Robert Haas robertmh...@gmail.com writes:
However, I am not clear what benefit we get from moving this into core
in 9.1. If it's still going to require a full postmaster restart, the
GUC you have to change may as well be shared_preload_libraries as a
new one.
+1. I am not in favor of
On Mon, Nov 22, 2010 at 9:49 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
However, I am not clear what benefit we get from moving this into core
in 9.1. If it's still going to require a full postmaster restart, the
GUC you have to change may as well be
Itagaki Takahiro itagaki.takah...@gmail.com writes:
I'd like to propose %{...}s syntax, where format('%{xxx}s', arg)
is equivalent to format('%s', to_char(arg, 'xxx')). I think the
approach is better than implement C-like formatter because we
can reuse existing to_char() functions for the
Itagaki Takahiro itagaki.takah...@gmail.com writes:
I checked cfparser.v2.patch.
Thanks for reviewing it!
It exports the static parseRecoveryCommandFileLine() in xlog.c
as the global cfParseOneLine() in cfparser.c without modification.
It generates one warning, but it can be easily fixed.
On mån, 2010-11-22 at 12:37 +0100, Magnus Hagander wrote:
Do we want to backpatch it into contrib/?
It's not a bug fix or an upgrading aid, so no.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
Peter Eisentraut pete...@gmx.net writes:
On mån, 2010-11-22 at 12:37 +0100, Magnus Hagander wrote:
Do we want to backpatch it into contrib/?
It's not a bug fix or an upgrading aid, so no.
I'm less than thrilled about back-patching this, too. It seems to fly
in the face of all our historical
On Mon, Nov 22, 2010 at 16:33, Tom Lane t...@sss.pgh.pa.us wrote:
Peter Eisentraut pete...@gmx.net writes:
On mån, 2010-11-22 at 12:37 +0100, Magnus Hagander wrote:
Do we want to backpatch it into contrib/?
It's not a bug fix or an upgrading aid, so no.
I'm less than thrilled about
On Mon, Nov 22, 2010 at 15:15, Robert Haas robertmh...@gmail.com wrote:
On Mon, Nov 22, 2010 at 6:37 AM, Magnus Hagander mag...@hagander.net wrote:
Do we want to backpatch it into contrib/? Adding a new module there
seems kind of wrong - probably better to keep the source separate and
just
On Mon, Nov 22, 2010 at 18:36, Dimitri Fontaine dimi...@2ndquadrant.fr wrote:
* Can we export ParseConfigFile() in guc-file.l rather than
parseRecoveryCommandFileLine()?
Should we then consider recovery.conf entries as ordinary GUCs? That
would allow to connect to a standby and issue 'show
This bug report:
http://archives.postgresql.org/pgsql-bugs/2010-11/msg00139.php
shows that this patch was ill-considered:
http://archives.postgresql.org/pgsql-committers/2010-06/msg00013.php
and this later attempt didn't fix it, because it still misbehaves in
HEAD:
Magnus Hagander mag...@hagander.net writes:
on-by-default is what we gain. I think that's fairly big...
Only if that's actually what we want, which is far from clear in this
corner. There are good reasons why most Linux distros configure daemons
not to dump core by default. It's annoying when
On Tue, Nov 23, 2010 at 01:27, Tom Lane t...@sss.pgh.pa.us wrote:
This bug report:
http://archives.postgresql.org/pgsql-bugs/2010-11/msg00139.php
shows that this patch was ill-considered:
http://archives.postgresql.org/pgsql-committers/2010-06/msg00013.php
and this later attempt didn't fix
On 20.11.2010 06:10, Joachim Wieland wrote:
2010/11/19 José Arthur Benetasso Villanovajose.art...@gmail.com:
The md5.c and kwlookup.c reuse using a link doesn't look nice either.
This way you need to compile twice, among others things, but I think
that its temporary, right?
No, it isn't.
Itagaki Takahiro itagaki.takah...@gmail.com writes:
On Tue, Nov 23, 2010 at 01:27, Tom Lane t...@sss.pgh.pa.us wrote:
I'm inclined to think that we should just change all the
truncate_identifier calls to warn=false, and forget about providing
identifier-truncated warnings here. Â It's too
On 11/22/2010 11:51 AM, Tom Lane wrote:
Itagaki Takahiroitagaki.takah...@gmail.com writes:
On Tue, Nov 23, 2010 at 01:27, Tom Lanet...@sss.pgh.pa.us wrote:
I'm inclined to think that we should just change all the
truncate_identifier calls to warn=false, and forget about providing
Heikki Linnakangas heikki.linnakan...@enterprisedb.com writes:
But I'm not actually sure we should be preventing mix match of files
from different dumps. It might be very useful to do just that sometimes,
like restoring a recent backup, with the contents of one table replaced
with older
On Mon, Nov 22, 2010 at 9:55 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Itagaki Takahiro itagaki.takah...@gmail.com writes:
I'd like to propose %{...}s syntax, where format('%{xxx}s', arg)
is equivalent to format('%s', to_char(arg, 'xxx')). I think the
approach is better than implement C-like
Andrew Dunstan and...@dunslane.net writes:
On 11/22/2010 11:51 AM, Tom Lane wrote:
Perhaps a reasonable compromise is to issue the truncation warnings when
an overlength name is being *entered* into the connection table, but not
for simple lookups.
Can't we distinguish a name from a conninfo
On Mon, Nov 22, 2010 at 10:17 AM, Peter Eisentraut pete...@gmx.net wrote:
On mån, 2010-11-22 at 12:37 +0100, Magnus Hagander wrote:
Do we want to backpatch it into contrib/?
It's not a bug fix or an upgrading aid, so no.
I don't see why an upgrading aid would be worthy of back-patching, but
On 11/22/2010 12:08 PM, Tom Lane wrote:
Andrew Dunstanand...@dunslane.net writes:
On 11/22/2010 11:51 AM, Tom Lane wrote:
Perhaps a reasonable compromise is to issue the truncation warnings when
an overlength name is being *entered* into the connection table, but not
for simple lookups.
Robert Haas robertmh...@gmail.com writes:
On Mon, Nov 22, 2010 at 9:55 AM, Tom Lane t...@sss.pgh.pa.us wrote:
And lastly, AFAICS there
is no way to do what you suggest without some really ugly kluges
in the parser --- I think the function parsing code would have to
have special cases to make
Andrew Dunstan and...@dunslane.net writes:
On 11/22/2010 12:08 PM, Tom Lane wrote:
No, because = isn't disallowed in names ...
Ok, true, but it still might not be a bad heuristic to use for issuing a
warning on lookup.
The fine manual says that using = in a connection name might be unwise
Robert Haas robertmh...@gmail.com writes:
I don't see why an upgrading aid would be worthy of back-patching, but
not a debugging aid. I'd certainly prioritize those in the other
order.
I think the sort of upgrading aid Peter has in mind is the kind where
it's entirely useless if it's not
On 11/22/2010 12:21 PM, Tom Lane wrote:
Andrew Dunstanand...@dunslane.net writes:
On 11/22/2010 12:08 PM, Tom Lane wrote:
No, because = isn't disallowed in names ...
Ok, true, but it still might not be a bad heuristic to use for issuing a
warning on lookup.
The fine manual says that using
On Mon, Nov 22, 2010 at 12:30 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
I don't see why an upgrading aid would be worthy of back-patching, but
not a debugging aid. I'd certainly prioritize those in the other
order.
I think the sort of upgrading aid
Magnus Hagander mag...@hagander.net writes:
* On Unix, the core file is dropped in the database directory, we
don't have a separate directory for crashdumps. If we want to be
consistent, we should do that here too. I do think that storing them
in a directory like crashdumps is better, but I
On Mon, Nov 22, 2010 at 12:17 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
On Mon, Nov 22, 2010 at 9:55 AM, Tom Lane t...@sss.pgh.pa.us wrote:
And lastly, AFAICS there
is no way to do what you suggest without some really ugly kluges
in the parser --- I
Robert Haas robertmh...@gmail.com writes:
I am as conservative about back-patching as anybody here, but
debugging on Windows is not an easy thing to do, and I strongly
suspect we are going to point people experiencing crashes on Windows
to this code whether it's part of our official
On 22.11.2010 19:47, Robert Haas wrote:
I am as conservative about back-patching as anybody here, but
debugging on Windows is not an easy thing to do, and I strongly
suspect we are going to point people experiencing crashes on Windows
to this code whether it's part of our official distribution
2010/11/22 Robert Haas robertmh...@gmail.com:
On Mon, Nov 22, 2010 at 12:17 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
On Mon, Nov 22, 2010 at 9:55 AM, Tom Lane t...@sss.pgh.pa.us wrote:
And lastly, AFAICS there
is no way to do what you suggest without
On Mon, Nov 22, 2010 at 18:46, Tom Lane t...@sss.pgh.pa.us wrote:
Magnus Hagander mag...@hagander.net writes:
* However, when storing it in crashdumps, I think the code would need
to create that directory if it does not exist, doesn't it?
If it didn't do so, then manual creation/removal of
On Mon, Nov 22, 2010 at 18:54, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
I am as conservative about back-patching as anybody here, but
debugging on Windows is not an easy thing to do, and I strongly
suspect we are going to point people experiencing crashes on
On Mon, Nov 22, 2010 at 18:56, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
On 22.11.2010 19:47, Robert Haas wrote:
I am as conservative about back-patching as anybody here, but
debugging on Windows is not an easy thing to do, and I strongly
suspect we are going to point
Magnus Hagander mag...@hagander.net writes:
On Mon, Nov 22, 2010 at 18:46, Tom Lane t...@sss.pgh.pa.us wrote:
... I haven't looked at the patch but this
discussion makes it sound like the dumper is dependent on an
uncomfortably large amount of backend code being functional.
No, it's
On Mon, Nov 22, 2010 at 19:39, Tom Lane t...@sss.pgh.pa.us wrote:
Magnus Hagander mag...@hagander.net writes:
On Mon, Nov 22, 2010 at 18:46, Tom Lane t...@sss.pgh.pa.us wrote:
... I haven't looked at the patch but this
discussion makes it sound like the dumper is dependent on an
uncomfortably
On mån, 2010-11-22 at 19:56 +0200, Heikki Linnakangas wrote:
This whole thing makes me wonder: is there truly no reliable, simple
method to tell Windows to create a core dump on crash, without writing
custom code for it. I haven't seen one, but I find it amazing if there
isn't. We can't be
On Mon, Jun 14, 2010 at 1:19 AM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
I *think* that the answer to this parenthesized question is no.
When we vacuum a page, we set the LSN on both the heap page and the
visibility map page. Therefore, neither of them can get written to
On Mon, Nov 15, 2010 at 12:09 PM, Greg Smith g...@2ndquadrant.com wrote:
So my task list is:
0) Rebase against the HEAD that just code related to this touched today
1) Assume that log_checkpoints is sufficient control over whether the timing
overhead added is worth collecting, and therefore
On Mon, Nov 22, 2010 at 1:28 PM, Magnus Hagander mag...@hagander.net wrote:
I think the reasonable options are either don't backpatch at all or
backpatch the same way as we put it in HEAD, which is probably
included in backend. I agree that sticking it in contrib is a
half-measure that we
On tor, 2010-11-18 at 21:37 +0200, Heikki Linnakangas wrote:
Have you done any performance testing? Functions like text_cmp can be
a hotspot in sorting, so any extra overhead there might be show up in
tests.
Without having optimized it very much yet, the performance for a 1GB
ORDER BY is
*
On mån, 2010-11-22 at 11:58 +0900, Itagaki Takahiro wrote:
* COLLATE information must be explicitly passed by caller in the patch,
but we might forgot the handover when we write new codes. Is it possible
to pass it automatically, say using a global variable? If we could do so,
existing
On 10-11-22 09:37 AM, Gurjeet Singh wrote:
On Sat, Nov 20, 2010 at 9:00 AM, Steve Singer ssinger...@sympatico.ca
mailto:ssinger...@sympatico.ca wrote:
Submission Review:
Tests
The expected output for the regression tests you added don't
Hello
I spent last two days a searching how to solve this problem better.
Probably I removed a issue with toasting. But I found other issue,
that wasn't discussed before. This issue is only seq access to items
via array_seek function. I though about some variable that stores a
last accessed
On 22.11.2010 19:07, Tom Lane wrote:
Heikki Linnakangasheikki.linnakan...@enterprisedb.com writes:
But I'm not actually sure we should be preventing mix match of files
from different dumps. It might be very useful to do just that sometimes,
like restoring a recent backup, with the contents of
On Sun, Nov 21, 2010 at 11:48 PM, Fujii Masao masao.fu...@gmail.com wrote:
--
If you suspect a bug in Hot Standby, please set
trace_recovery_messages = DEBUG2
in postgresql.conf and repeat the action
Always useful to know
* max_connections
* current number of sessions
*
Itagaki Takahiro itagaki.takah...@gmail.com writes:
No. My suggestion was just to use the internal parser.
What about something like the attached, cfparser.v3.patch?
If that looks ok, do we want to add some documentation about the new
lexer capabilities? Also, for what good reason would we want
I have been working on a plugin for GiST that has some unusual features:
* The data type for both Node and Leaf keys is large (typically 4222
bytes on 32-bit; 4230 bytes on 64-bit).
* Due to the large size the storage class is EXTENDED (main would only
degrade to EXTENDED in any case).
One minor correction:
postgres=# explain select count(*) from fps2 f1 join fps2 f2 on
f1.fingerprint = f2.fingerprint;
QUERY PLAN
Aggregate
On Mon, Nov 22, 2010 at 3:36 PM, Pavel Stehule pavel.steh...@gmail.com wrote:
So, please, I know, so you and Tom are busy, but try to spend a few
time about this problem before you are definitely reject this idea.
If I were to spend more time on this problem, what exactly would I
spend that
Excerpts from Dimitri Fontaine's message of lun nov 22 18:12:39 -0300 2010:
Itagaki Takahiro itagaki.takah...@gmail.com writes:
No. My suggestion was just to use the internal parser.
What about something like the attached, cfparser.v3.patch?
If that looks ok, do we want to add some
Excerpts from Alvaro Herrera's message of lun nov 22 18:59:52 -0300 2010:
Hmm, the first thought that comes to mind is that the GucContext param
to ParseConfigFile is unused and can be removed. This is probably an
oversight from when include files were introduced in 2006.
Committed and
Excerpts from Dimitri Fontaine's message of lun nov 22 18:12:39 -0300 2010:
Itagaki Takahiro itagaki.takah...@gmail.com writes:
No. My suggestion was just to use the internal parser.
What about something like the attached, cfparser.v3.patch?
the handling of relative vs absolute paths is
Hi,
When we lock on a Xid or VirtualXid, there's no way to obtain clear
information on the reason for locking. Consider the following example:
CREATE TABLE foo (a int);
Session 1:
BEGIN;
SELECT 1;
-- we now have a snapshot
Session 2:
CREATE INDEX CONCURRENTLY foo_a ON foo(a);
This blocks
Patch attached.
Best,
David
enum_value.patch
Description: Binary data
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On 11/22/2010 06:36 PM, David E. Wheeler wrote:
Patch attached.
Thanks, I'll look at this shortly. I think it needs a little bit more,
which I'll do. In particular, we should now avoid using the word 'value'
to refer to the internal representation of an enum - that will just be
confusing.
Alvaro Herrera alvhe...@alvh.no-ip.org writes:
A much more common ocurrence is tuple locks. We block in an Xid in that
case; and this has been a frequent question in the mailing lists and
IRC.
I think it would be very nice to be able to report something to the
user; however, I'm not seeing
David E. Wheeler da...@kineticode.com writes:
Patch attached.
Most of those changes seem like they make it less readable, not more so.
In particular I don't find it an improvement to replace textual label
with textual value. I think of value as meaning some abstract
notion of a particular enum
I've done some *very* preliminary review of this patch now. I think
that the way to move forward is to first commit the work surrounding
changes to pg_amop, including suitable changes to CREATE/ALTER OPERATOR
CLASS/FAMILY so that there's a way to put the new info into the table.
The system won't
On 11/22/2010 06:57 PM, Tom Lane wrote:
David E. Wheelerda...@kineticode.com writes:
Patch attached.
Most of those changes seem like they make it less readable, not more so.
In particular I don't find it an improvement to replace textual label
with textual value. I think of value as
Andrew Dunstan and...@dunslane.net writes:
On 11/22/2010 06:57 PM, Tom Lane wrote:
Maybe instead of textual label, we should say name? But that
doesn't seem like quite le mot juste either. label is actually a
pretty good word for the text representation of an enum value.
Oh my boots and
On Mon, Nov 22, 2010 at 7:46 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Andrew Dunstan and...@dunslane.net writes:
On 11/22/2010 06:57 PM, Tom Lane wrote:
Maybe instead of textual label, we should say name? But that
doesn't seem like quite le mot juste either. label is actually a
pretty good
On Nov 22, 2010, at 4:46 PM, Tom Lane wrote:
Oh my boots and buttons. I think we're splitting some very fine hairs
here. A few weeks back you were telling us that label wasn't a very good
word and shouldn't be sanctified in the SQL.
It isn't a very good word for the abstract value, IMO,
I wrote:
As far as the syntax of CREATE/ALTER OPERATOR CLASS/FAMILY is concerned,
I like Robert's proposal (OPERATOR ... FOR ORDER or FOR SEARCH) better
than Teodor's, though we don't need the multiple-purposes-per-entry
aspect of it. This is mainly because it looks more easily extensible
if
All,
Whatever we pick, someone will be confused by it and about equal numbers
regardless. Let's just stick with the current patch.
Or we could call it extraint conclusions. ;-)
--
-- Josh Berkus
PostgreSQL Experts Inc.
... or maybe not, because when we call XactLockTableWait, we've already
established that we've accepted to sleep.
Thoughts?
Other than this being a sincere need, no.
--
-- Josh Berkus
PostgreSQL Experts Inc.
On 11/22/10 5:38 PM, Josh Berkus wrote:
All,
Whatever we pick, someone will be confused by it and about equal numbers
regardless. Let's just stick with the current patch.
... original patch. Sorry. Let's not fiddle with the names.
Or we could call it extraint conclusions. ;-)
On Mon, Nov 22, 2010 at 5:55 PM, Alvaro Herrera alvhe...@alvh.no-ip.org wrote:
Hi,
When we lock on a Xid or VirtualXid, there's no way to obtain clear
information on the reason for locking. Consider the following example:
CREATE TABLE foo (a int);
Session 1:
BEGIN;
SELECT 1;
-- we now
On Mon, Nov 22, 2010 at 8:32 PM, Tom Lane t...@sss.pgh.pa.us wrote:
The reason I bring this up now is that it affects the decision as to
what the unique key for pg_amop ought to be. Instead of having an
enum purpose column, maybe we should consider that the unique key
is (operator oid,
On Sun, Nov 21, 2010 at 4:47 PM, Dimitri Fontaine
dimi...@2ndquadrant.fr wrote:
Robert Haas robertmh...@gmail.com writes:
On Sat, Nov 20, 2010 at 11:23 PM, Robert Haas robertmh...@gmail.com wrote:
Ah, nuts. I see now there's a v7. Never mind...
OK. I looked at the right version, now.
Robert Haas robertmh...@gmail.com writes:
On Mon, Nov 22, 2010 at 8:32 PM, Tom Lane t...@sss.pgh.pa.us wrote:
On balance I'm inclined to leave the unique key as per previous proposal
(with a purpose column) and add the which-sort-order-is-that
information as payload columns that aren't part of
2010/11/22 Robert Haas robertmh...@gmail.com:
On Mon, Nov 22, 2010 at 3:36 PM, Pavel Stehule pavel.steh...@gmail.com
wrote:
So, please, I know, so you and Tom are busy, but try to spend a few
time about this problem before you are definitely reject this idea.
If I were to spend more time on
On Tue, Nov 23, 2010 at 05:55:28AM +0100, Pavel Stehule wrote:
ok, I can only recapitulate so this feature was proposed cca two
months ago, and minimally Tom and maybe you did agreement - with
request on syntax - do you remember? I am little bit tired so this
agreement was changed when I
2010/11/23 David Fetter da...@fetter.org:
On Tue, Nov 23, 2010 at 05:55:28AM +0100, Pavel Stehule wrote:
ok, I can only recapitulate so this feature was proposed cca two
months ago, and minimally Tom and maybe you did agreement - with
request on syntax - do you remember? I am little bit tired
On 22.11.2010 23:18, Peter Tanski wrote:
Whatever test I use for Same(), Penalty() and Consistent() does not seem
to affect the problem significantly. For now I am only using
Consistent() as a check for retrieval.
I believe it's not possible to lose leaf tuples with incorrectly defined
gist
On Mon, 22 Nov 2010, Itagaki Takahiro wrote:
On Fri, Oct 15, 2010 at 03:40, Rados?aw Smogura
rsmog...@softperience.eu wrote:
Regarding JDBC in the CF process -- other interfaces are handled
there. I haven't seen one patch this size for JDBC since I've been
involved, let alone two competing
On 19.11.2010 23:46, Joachim Wieland wrote:
FATAL: too many KnownAssignedXids. head: 0, tail: 0, nxids: 9978,
pArray-maxKnownAssignedXids: 6890
Hmm, that's a lot of entries in KnownAssignedXids.
Can you recompile with WAL_DEBUG, and run the recovery again with
wal_debug=on ? That will print
92 matches
Mail list logo
