Daniel Farina wrote:
> After mulling over this some more, I am less on the fence about how
> unfortunate it is that Postgres cannot restart when doing an
> "exclusive" base backup: I think it is a severe anti-feature that
> should gradually be retired.
This anti-feature was introduced with
http://
Hello, This is the new version of the patch.
Your patch introduced new WAL record type XLOG_END_OF_RECOVERY to
mark the chenge point of TLI. But I think the information is
already stored in history files and already ready to use in
current code.
I looked into your first patch and looked over the
Hi,
PostgreSQL 9.2 Windows build is having trouble with the XML support:
http://postgresql.1045698.n5.nabble.com/9-2-beta1-libxml2-can-t-be-loaded-on-Windows-td5710672.html
postgres=# SELECT xml 'bar';
ERROR: could not set up XML error handler
HINT: This probably indicates that the version of li
On 17 June 2012 18:30, Kevin Grittner wrote:
> Gurjeet Singh wrote:
>> Dean Rasheed wrote:
>
>> in HEAD:
>>> ... (actual time=1390.037..1390.037 rows=0 loops=1)
>>> Trigger for constraint fk_table_e_fkey: time=210.184 calls=9
>>> Total runtime: 1607.626 ms
>
>>> With this patch:
>>> ... (actu
On 17 June 2012 18:48, Tom Lane wrote:
> Gurjeet Singh writes:
>> On Sat, Jun 16, 2012 at 9:50 AM, Dean Rasheed
>> wrote:
>> I find it interesting that 'actual time' for top level 'Update on fk_table'
>> is always higher in patched versions, and yet the 'Total runtime' is lower
>> for the patche
On 06/15/2012 03:59 PM, Jeff Davis wrote:
On Wed, 2012-06-13 at 23:10 +0200, Miroslav Šimulčík wrote:
I have working patch for postgresql version 9.0.4, but it needs
refactoring before i can submit it, because some parts don't
meet formatting requirements yet. And yes, changes are large, so it
On 16.06.2012 09:04, Amit kapila wrote:
I don't think so. C doesn't ref count its pointers.
You are right I have misunderstood.
I don't think that lock tags have good human readable formats, and just
a pointer dump probably wouldn't be much use when something that can
never happen has happene
On 18 June 2012 04:21, Josh Kupershmidt wrote:
> +1 for the idea. I find the existing behavior rather confusing,
> particularly the fact that a schema-qualified function name will be
> tab-completed, i.e. this works.
>
> DROP FUNCTION my_schema.my
>
> but then, as your second example above shows,
On 10.06.2012 23:39, Jeff Janes wrote:
The attached patch fixes that by remembering up to 10 local locks, and
pushing them up specifically rather than digging through the entire
lock table. If the list overflows, then it reverts to the old
behavior of digging through the entire local lock table.
Hackers,
While experimenting with gistchoose I achieve interesting results about
relation of gistchoose behaviour and gist index bloat.
I've created following testcase for reproducing gist index bloating:
1) Create test table with 100 points from geonames
# create table geotest (id serial, poi
On Monday, June 18, 2012 02:43:26 AM Steve Singer wrote:
> On 12-06-13 01:27 PM, Andres Freund wrote:
> > The previous mail contained a patch with a mismerge caused by reording
> > commits. Corrected version attached.
> >
> > Thanks to Steve Singer for noticing this quickly.
>
> Attached is a mor
On Sat, Jun 16, 2012 at 5:38 PM, Tom Lane wrote:
>
> A small flaw in this plan is that in pg_constraint.confmatchtype,
> MATCH_UNSPECIFIED is stored as 'u'. In a green field I'd just rename
> that to 's' for SIMPLE, but it seems possible that this would confuse
> client-side code such as pg_dump
On 15.06.2012 00:38, Andres Freund wrote:
On Thursday, June 14, 2012 11:19:00 PM Heikki Linnakangas wrote:
On 13.06.2012 14:28, Andres Freund wrote:
Features:
- streaming reading/writing
- filtering
- reassembly of records
Reusing the ReadRecord infrastructure in situations where the code that
Gurjeet Singh writes:
> The other candidate to look for possible breakage would be pgAdmin. As Amit
> says, there might be code out in the wild that does look at this column, so
> not worth breaking them for this small gain.
Well, I already did it the other way ;-). It's probably not that big a
Dean Rasheed writes:
> I think that the patch already covers the most common use case (in my
> experience) but we may as well get as much out of it as we can while
> we're here.
Yeah. The cases involving nulls are probably really rather unlikely
altogether, but it seems a tad silly to fix only s
On Monday, June 18, 2012 01:51:45 PM Heikki Linnakangas wrote:
> On 15.06.2012 00:38, Andres Freund wrote:
> > On Thursday, June 14, 2012 11:19:00 PM Heikki Linnakangas wrote:
> >> On 13.06.2012 14:28, Andres Freund wrote:
> >>> Features:
> >>> - streaming reading/writing
> >>> - filtering
> >>> -
On Thu, Mar 22, 2012 at 5:26 PM, Daniel Farina wrote:
> Some time ago I reported bug 6291[0], which reported a Xid wraparound,
> both as reported in pg_controldata and by txid_current_snapshot.
> Unfortunately, nobody could reproduce it.
>
> Today, the same system of ours just passed the wraparoun
> A better error message would be nice, but I don't think it's worth that
> much. resowner.c doesn't currently know about the internals of LOCALLOCk
> struct or lock tags, and I'd prefer to keep it that way. Let's just
> print the pointer's address, that's what we do in many other
> correspondi
Misa Simic wrote:
> 2012/6/17 Kevin Grittner
>> Can someone provide a practical example of a "foreign key with
>> array" use case? The only situations I'm able to think of right
>> now are the same cases where you would now use a table with
>> primary keys of two tables to provide a many-to-ma
Hi Peter,
On Friday, June 15, 2012 12:42:12 AM Peter Eisentraut wrote:
> Here is my first patch for the transforms feature. This is a mechanism
> to adapt data types to procedural languages. The previous proposal was
> here: http://archives.postgresql.org/pgsql-hackers/2012-05/msg00728.php
>
>
On 13 June 2012 19:28, Andres Freund wrote:
> This adds a new configuration parameter multimaster_node_id which determines
> the id used for wal originating in one cluster.
Looks good and it seems this aspect at least is commitable in this CF.
Design decisions I think we need to review are
* N
On Mon, Jun 18, 2012 at 3:56 AM, Dean Rasheed wrote:
> On 18 June 2012 04:21, Josh Kupershmidt wrote:
>> As a side note unrelated to this patch, I also dislike how function
>> name tab-completions will not fill in the opening parenthesis, which
>> makes for unnecessary work for the user, as one
Hi Simon,
On Monday, June 18, 2012 05:35:40 PM Simon Riggs wrote:
> On 13 June 2012 19:28, Andres Freund wrote:
> > This adds a new configuration parameter multimaster_node_id which
> > determines the id used for wal originating in one cluster.
>
> Looks good and it seems this aspect at least is
On Thursday, June 14, 2012 03:50:28 PM Robert Haas wrote:
> On Wed, Jun 13, 2012 at 7:28 AM, Andres Freund
wrote:
> > This is locally defined in lots of places and would get introduced
> > frequently in the next commits. It is expected that this can be defined
> > in a header-only manner as soon
On 18 June 2012 00:38, Tom Lane wrote:
> The only reason we test "a = b" and not "a < b || a > b"
> is that the latter is at least twice as expensive to evaluate.
Perhaps I've been unclear. I meant to write "(!(a < b) && !(b < a))",
and not "(a < b && b < a)". The former is not tautological when
On 18 June 2012 16:59, Peter Geoghegan wrote:
> Perhaps more importantly, I cannot recreate any of these problems on
> my Fedora 16 machine. Even with hu_HU on LATIN2, Tom's original test
> case (from 2005, on a Fedora 4 machine) cannot be recreated. So it may
> be that they've tightened these thi
On Wednesday, June 13, 2012 06:53:17 PM Jeff Davis wrote:
> On Wed, 2012-06-13 at 13:53 +0300, Peter Eisentraut wrote:
> > The --help output for the -N option was copy-and-pasted wrongly.
> >
> > The message issued when using -N is also a bit content-free. Maybe
> > something like
> >
> > "Runni
On Thu, Jun 14, 2012 at 7:29 AM, Shigeru HANADA
wrote:
> I'd like to propose pgsql_fdw, FDW for PostgreSQL, as a contrib module
> in core, again. This patch is basically rebased version of the patches
> proposed in 9.2 development cycle, and contains some additional changes
> such as concern abou
On Mon, Jun 18, 2012 at 5:42 PM, Kyotaro HORIGUCHI
wrote:
> What do you think about this?
What happens if the server skips an end-of-recovery checkpoint, is promoted to
the master, runs some write transactions, crashes and restarts automatically
before it completes checkpoint? In this case, the s
Excerpts from Tom Lane's message of sáb jun 16 02:41:00 -0400 2012:
> Amit kapila writes:
> > The suggested patch improves the logic to recover corrupt control file. So
> > that is the reason I felt it will be relevant to do this patch.
>
> Well, we invented pg_resetxlog with the thought that
Alvaro Herrera writes:
> Excerpts from Tom Lane's message of sáb jun 16 02:41:00 -0400 2012:
>> Well, we invented pg_resetxlog with the thought that it might be useful
>> for such situations, but I'm not sure offhand that we've ever seen a
>> field report of corrupted pg_control files.
> Hm, wha
On Mon, 2012-06-18 at 19:34 +0900, Vlad Arkhipov wrote:
> What's wrong with SPI/timetravel extension for system versioning?
> http://www.postgresql.org/docs/9.1/static/contrib-spi.html
>
> We are heavily using system-versioned and application-time period
> tables in our enterprise products (most o
On Sun, Jun 17, 2012 at 12:29:53PM -0400, Tom Lane wrote:
> The fly in the ointment with any of these ideas is that the "configure
> list" is not a list of exact cipher names, as per Magnus' comment that
> the current default includes tests like "!aNULL". I am not sure that
> we know how to evalua
Excerpts from Boszormenyi Zoltan's message of vie may 11 03:54:13 -0400 2012:
> Hi,
>
> another rebasing and applied the GIT changes in
> ada8fa08fc6cf5f199b6df935b4d0a730aaa4fec to the
> Windows implementation of PGSemaphoreTimedLock.
Hi,
I gave the framework patch a look. One thing I'm not s
> AFAIR you can create pg_control from scratch already with pg_resetxlog.
> The hard part is coming up with values for the counters, such as the
> next WAL location. Some of them such as next OID are pretty harmless
> if you don't guess right, but I'm worried that wrong next WAL could
> make thing
On Thu, Jun 14, 2012 at 5:58 PM, Andres Freund wrote:
>> 1. Use a 64-bit segment number, instead of the log/seg combination. And
>> don't waste the last segment on each logical 4 GB log file. The concept
>> of a "logical log file" is now completely gone. XLogRecPtr is unchanged,
>> but it should n
On 18.06.2012 21:00, Robert Haas wrote:
On Thu, Jun 14, 2012 at 5:58 PM, Andres Freund wrote:
1. Use a 64-bit segment number, instead of the log/seg combination. And
don't waste the last segment on each logical 4 GB log file. The concept
of a "logical log file" is now completely gone. XLogRecPt
On Fri, Jun 15, 2012 at 9:22 AM, Ants Aasma wrote:
> Exactly. I think the first question for this patch should be whether
> this use-case is worth the complexity of the patch. I can't imagine
> any really compelling use cases that need an arbitrary distinct subset
> of results.
Me neither.
> The
On Monday, June 18, 2012 08:08:14 PM Heikki Linnakangas wrote:
> On 18.06.2012 21:00, Robert Haas wrote:
> > On Thu, Jun 14, 2012 at 5:58 PM, Andres Freund
wrote:
> >>> 1. Use a 64-bit segment number, instead of the log/seg combination. And
> >>> don't waste the last segment on each logical 4 GB
On Mon, Jun 18, 2012 at 2:08 PM, Heikki Linnakangas
wrote:
> On 18.06.2012 21:00, Robert Haas wrote:
>> On Thu, Jun 14, 2012 at 5:58 PM, Andres Freund
>> wrote:
1. Use a 64-bit segment number, instead of the log/seg combination. And
don't waste the last segment on each logical 4 GB
On 18.06.2012 21:13, Andres Freund wrote:
On Monday, June 18, 2012 08:08:14 PM Heikki Linnakangas wrote:
The page header contains an XLogRecPtr (LSN), so if we change it we'll
have to deal with pg_upgrade. I guess we could still keep XLogRecPtr
around as the on-disk representation, and convert b
On mån, 2012-06-18 at 18:05 +0200, Andres Freund wrote:
> - defaulting to initdb -N in the regression suite is not a good imo,
> because that way the buildfarm won't catch problems in that area...
>
The regression test suite also starts postgres with fsync off. This is
good, and I don't want to h
n with it
Done.
Regards,
Jeff Davis
initdb-fsync-20120618.patch.gz
Description: GNU Zip compressed 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 Monday, June 18, 2012 08:32:54 PM Heikki Linnakangas wrote:
> On 18.06.2012 21:13, Andres Freund wrote:
> > On Monday, June 18, 2012 08:08:14 PM Heikki Linnakangas wrote:
> >> The page header contains an XLogRecPtr (LSN), so if we change it we'll
> >> have to deal with pg_upgrade. I guess we cou
ncerns.
Regards,
Jeff Davis
initdb-fsync-20120618-2.patch.gz
Description: GNU Zip compressed 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 Monday, June 18, 2012 08:39:47 PM Jeff Davis wrote:
> On Mon, 2012-06-18 at 18:05 +0200, Andres Freund wrote:
> > Quick review:
> > - defaulting to initdb -N in the regression suite is not a good imo,
> > because that way the buildfarm won't catch problems in that area...
> I removed the -N as y
On 18.06.2012 21:45, Andres Freund wrote:
On Monday, June 18, 2012 08:32:54 PM Heikki Linnakangas wrote:
On 18.06.2012 21:13, Andres Freund wrote:
On Monday, June 18, 2012 08:08:14 PM Heikki Linnakangas wrote:
The page header contains an XLogRecPtr (LSN), so if we change it we'll
have to deal
Excerpts from Alex Hunsaker's message of vie feb 10 16:53:05 -0300 2012:
> Seems like we missed the fact that we still did SvUTF8_on() in sv2cstr
> and SvPVUTF8() when turning a perl string into a cstring.
Hmm, this patch belongs into back branches too, right? Not just the
current development t
On Wed, Feb 1, 2012 at 5:23 AM, Chetan Suttraway
wrote:
> Hi All,
>
> This is regarding the TODO item :
> "Add SPI_gettypmod() to return a field's typemod from a TupleDesc"
>
> The related message is:
> http://archives.postgresql.org/pgsql-hackers/2005-11/msg00250.php
>
> This basical
On Mon, 2012-06-18 at 20:57 +0200, Andres Freund wrote:
> > > - defaulting to initdb -N in the regression suite is not a good imo,
> > > because that way the buildfarm won't catch problems in that area...
> > I removed the -N as you suggest. How much does performance matter on the
> > buildfarm?
>
Out of (mostly idle) curiousity, when exactly does a transaction commit,
especially with respect to a TCP connection that a pathological demon will
cut off at the worst possible moment?
The thing is, I'm using PostgreSQL as a queue, using asynchronous
notifications and following the advice of M
On Monday, June 18, 2012 09:32:25 PM Jeff Davis wrote:
> > > > - could the copydir.c and initdb.c versions of walkdir/sync_fname et
> > > > al be unified?
> > >
> > > There's a lot of backend-specific code in the copydir versions, like
> > > using ereport() and CHECK_FOR_INTERRUPTS(). I gave a bri
Excerpts from Jeff Davis's message of lun jun 18 15:32:25 -0400 2012:
> On Mon, 2012-06-18 at 20:57 +0200, Andres Freund wrote:
> > Btw, I just want to have said this, although I don't think its particularly
> > relevant as it doesn't affect correctness: Its possible to have a system
> > where
Chetan Suttraway wrote:
> This is regarding the TODO item:
> "Prevent the specification of conflicting transaction read/write
> options"
>
> listed at:
> http://wiki.postgresql.org/wiki/Todo
Here's my review of this patch.
Basic stuff:
- Patch applies OK
- Compiles cl
On Mon, 2012-06-18 at 21:41 +0200, Andres Freund wrote:
> It calls pg_flush_data inside of copy_file which does the posix_fadvise... So
> maybe just put the sync_file_range in pg_flush_data?
Oh, I didn't notice that, thank you.
In that case, it may be good to combine them if possible. I will loo
BTW it doesn't seem that datatype/timestamp.h is really necessary in
timeout.h.
--
Álvaro Herrera
The PostgreSQL Company - Command Prompt, Inc.
PostgreSQL Replication, Consulting, Custom Development, 24x7 support
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make c
On Monday, June 18, 2012 09:19:48 PM Heikki Linnakangas wrote:
> On 18.06.2012 21:45, Andres Freund wrote:
> > On Monday, June 18, 2012 08:32:54 PM Heikki Linnakangas wrote:
> >> On 18.06.2012 21:13, Andres Freund wrote:
> >>> On Monday, June 18, 2012 08:08:14 PM Heikki Linnakangas wrote:
> Th
> PE> Compare the output of pg_config --configure from both installations.
>
> The only differences are 9.1 vs 9.2 in the paths.
Can you check the collations of the two databases? I'm wondering if 9.1
is in "C" collation and 9.2 is something else.
--
Josh Berkus
PostgreSQL Experts Inc.
http:
On Mon, Jun 18, 2012 at 8:50 AM, Andres Freund wrote:
>> * Size of field. 16 bits is enough for 32,000 master nodes, which is
>> quite a lot. Do we need that many? I think we may have need for a few
>> flag bits, so I'd like to reserve at least 4 bits for flag bits, maybe
>> 8 bits. Even if we do
On Monday, June 18, 2012 11:51:27 PM Daniel Farina wrote:
> On Mon, Jun 18, 2012 at 8:50 AM, Andres Freund
wrote:
> >> * Size of field. 16 bits is enough for 32,000 master nodes, which is
> >> quite a lot. Do we need that many? I think we may have need for a few
> >> flag bits, so I'd like to res
> "JB" == Josh Berkus writes:
JB> Can you check the collations of the two databases? I'm wondering if 9.1
JB> is in "C" collation and 9.2 is something else.
Thanks!
pg_dump -C tells me these two differences:
-SET client_encoding = 'SQL_ASCII';
+SET client_encoding = 'UTF8';
-CREATE DA
On Mon, Jun 18, 2012 at 11:50 AM, Andres Freund wrote:
> Hi Simon,
>
> On Monday, June 18, 2012 05:35:40 PM Simon Riggs wrote:
>> On 13 June 2012 19:28, Andres Freund wrote:
>> > This adds a new configuration parameter multimaster_node_id which
>> > determines the id used for wal originating in o
Excerpts from Dimitri Fontaine's message of vie jun 15 16:27:50 -0400 2012:
> The attached patch contains all the infrastructure for event triggers
> and also a first implementation of them for the event "command_start",
> implemented in a single place in utility.c.
>
> The infrastructure is abo
2012/6/18 Kevin Grittner
> The many-to-one case seems like it is better handled in the other
> direction -- with the referenced table holding the set of valid keys
> and the referencing table holding the single key. (I believe the
> general case of this is what Jeff called an "inclusion constrai
On Fri, Jun 15, 2012 at 1:58 PM, Jeff Janes wrote:
> Do we need the retry flag (applies to two places)? If oldblkno is
> still InvalidBlockNumber then it can't equal blkno.
I was a bit concerned that blkno = BUCKET_TO_BLKNO(metap, bucket)
might set blkno to InvalidBlockNumber, thus possibly mess
There was a regression introduced in 9.2 that effects the creation and
loading of lots of small tables in a single transaction.
It affects the loading of a pg_dump file which has a large number of
small tables (10,000 schemas, one table per schema, 10 rows per
table). I did not test other schema
On Sat, Jun 16, 2012 at 3:03 PM, Steve Singer wrote:
> I feel that in-core support to capture changes and turn them into change
> records that can be replayed on other databases, without relying on triggers
> and log tables, would be good to have.
>
> I think we want some flexible enough that peop
On Sat, Jun 16, 2012 at 7:43 AM, Andres Freund wrote:
>> > Hm. Yes, you could do that. But I have to say I don't really see a point.
>> > Maybe the fact that I do envision multimaster systems at some point is
>> > clouding my judgement though as its far less easy in that case.
>> Why? I don't thi
On Sat, Jun 16, 2012 at 2:56 PM, Fabien COELHO wrote:
>> The argument for defaulting to NOTICE is the same as it's always been:
>> that those messages are really intended for novices, and a pretty good
>> definition of a novice is somebody who doesn't know how to (or that he
>> should) change the
On Sat, Jun 16, 2012 at 6:25 PM, Jeff Janes wrote:
>> Well, this fell through the cracks, because I forgot to add it to the
>> January CommitFest. Here it is again, rebased.
>
> This applies and builds cleanly and passes make check (under enable-cassert).
>
> Not test or docs are needed for a pat
On 12-06-18 07:30 AM, Andres Freund wrote:
Hrmpf #666. I will go through through the series commit-by-commit again to
make sure everything compiles again. Reordinging this late definitely wasn't a
good idea...
I pushed a rebased version with all those fixups (and removal of the
zeroRecPtr patch
On 12-06-18 11:50 AM, Andres Freund wrote:
Hi Simon,
I think we need to agree on the parameter name. It currently is
'multimaster_node_id'. In the discussion with Steve we got to
"replication_node_id". I don't particularly like either.
Other suggestions?
Other things that come to mind (for n
On Mon, Jun 18, 2012 at 5:08 AM, Talha Bin Rizwan
wrote:
> PostgreSQL 9.2 Windows build is having trouble with the XML support:
> http://postgresql.1045698.n5.nabble.com/9-2-beta1-libxml2-can-t-be-loaded-on-Windows-td5710672.html
>
> postgres=# SELECT xml 'bar';
> ERROR: could not set up XML erro
On Mon, Jun 18, 2012 at 12:24 PM, Merlin Moncure wrote:
> I can't help but wonder (having been down the contrib/core/extension
> road myself) if it isn't better to improve the facilities to register
> and search for qualified extensions (like Perl CPAN) so that people
> looking for code to improve
On Sun, Feb 19, 2012 at 12:10 PM, Pavel Stehule wrote:
> Hello
>
> I found so this extremely simple patch should be useful.
>
> It helps for pattern SELECT fx();
>
> There was thread about it.
Hi Pavel,
I signed up to be reviewer for this patch, and finally got around to
taking a look. This threa
On Mon, Mar 19, 2012 at 1:01 PM, Alvaro Herrera
wrote:
> I'm rather of the contrary opinion -- surely if we're going to complete
> function names, we should only complete those that are in schemas in the
> path; similarly for column names.
I think it makes sense to only include currently-visible
Amit Kapila writes:
>> AFAIR you can create pg_control from scratch already with pg_resetxlog.
>> The hard part is coming up with values for the counters, such as the
>> next WAL location. Some of them such as next OID are pretty harmless
>> if you don't guess right, but I'm worried that wrong ne
Leon Smith writes:
> Out of (mostly idle) curiousity, when exactly does a transaction commit,
> especially with respect to a TCP connection that a pathological demon will
> cut off at the worst possible moment?
It's committed when the XLOG_XACT_COMMIT WAL record reaches disk,
if by "committed" y
Andres Freund writes:
> On Monday, June 18, 2012 11:51:27 PM Daniel Farina wrote:
>> What's the cost of going a lot higher? Because if one makes enough
>> numerical space available, one can assign node identities without a
>> coordinator, a massive decrease in complexity.
> It would increase the
> And it doesn't seem right for ResourceOwnerRemember/ForgetLock to have to
accept a NULL owner.
I am not sure, if it can ever enter into this flow without resowner as
mentioned in jeff comments
for session level locks. If it cannot enter then it is okay.
> Please take a look to see if I brok
On 19.06.2012 09:02, Amit Kapila wrote:
Please take a look to see if I broke something.
In you previous mail you agreed with level as ERROR for elog message in
function ResourceOwnerForgetLock(..) function,
but in your modification you have used PANIC, is there any specific reason
for it.
Robert Haas writes:
> There might be something to the idea of demoting a few of the things
> we've traditionally had as NOTICEs, though. IME, the following two
> messages account for a huge percentage of the chatter:
> NOTICE: CREATE TABLE will create implicit sequence "foo_a_seq" for
> serial
On mån, 2012-06-18 at 17:57 -0400, James Cloos wrote:
> > "JB" == Josh Berkus writes:
>
> JB> Can you check the collations of the two databases? I'm wondering if 9.1
> JB> is in "C" collation and 9.2 is something else.
>
> Thanks!
>
> pg_dump -C tells me these two differences:
>
> -SET c
Peter Eisentraut writes:
> On mån, 2012-06-18 at 17:57 -0400, James Cloos wrote:
>> I presume that lc_ctype is the significant difference?
> It certainly makes some difference, but it's a bit shocking that makes
> things that much slower.
If James is testing text-comparison-heavy operations, it
84 matches
Mail list logo