Try
SHOW search_path;
On both the good and bad connection. Is it possible you have some code
setting it and leaving it set incorrectly?
--
greg
On 12 Oct 2013 23:17, "John R Pierce" wrote:
> On 10/9/2013 10:35 AM, nbudu...@gmail.com wrote:
>
>> Basically, at some point a query, update or inser
On Tue, Aug 13, 2013 at 2:50 PM, wrote:
> I do have a copy of the data directory with a duplicate row in
> cluster_ressource, in case anyone wants to dive into it.
Could you run the following?
select ctid,xmin,xmax,primarykey from tab where primarykey = 'duplicatevalue'
And also show the \d ta
On Tue, Aug 13, 2013 at 2:50 PM, wrote:
> The following bug has been logged on the website:
>
> Bug reference: 8382
> Logged by: Curd Reinert
> Email address: curd.rein...@ppi.de
> PostgreSQL version: 9.0.5
The current bug-fix release for Postgres 9 is 9.0.13. There was an
ext
On Wed, Aug 7, 2013 at 1:50 PM, Sebastian Kornehl
wrote:
> Do you have any idea how to close these xa transactions without restarting
> the whole db?
Restarting the database wouldn't accomplish anything. Prepared transactions
are persistent across reboots.
http://www.postgresql.org/docs/9.3/sta
On Sun, Aug 4, 2013 at 10:03 AM, wrote:
> Not really a bug but a?
Questions can be sent to pgsql-gene...@postgresql.org
> I have been using you enterprisedb
Then you should contact enterprisedb for support or use their forums.
> It install easy with XAMPP but I can not get it to load with you
On Mon, Jul 29, 2013 at 10:19 PM, Klaus Ita wrote:
> My feeling is, that 'something' got confused with hot-standby and
> wal_archiving leading to this situation, that seems to be partially xfs
> caused?? xfs_repair mentionned some missing files, that pg did not
> expect to have (maybe truncate
On Wed, Jun 26, 2013 at 12:57 AM, Tom Lane wrote:
> (Though if it is, it's not apparent why such
> failures would only be manifesting on the pg_xlog files and not for
> anything else.)
Well data files are only ever written to in 8k chunks. Maybe these
errors are only occuring on >8k xlog records
On Wed, Jun 12, 2013 at 9:58 AM, wrote:
> denis=# select 1 as a, unnest('{2,3}'::int[]) as b, unnest('{4,5}'::int[])
set returning functions in the target list of the select don't behave
the way you're thinking. What you probably want to do is move the
unnest() to the FROM clause:
select 1 as a
On Wed, Jun 12, 2013 at 9:58 AM, wrote:
> denis=# select 1 as a, unnest('{2,3}'::int[]) as b, unnest('{4,5}'::int[])
set returning functions in the target list of the select don't behave
the way you're thinking. What you probably want to do is move the
unnest() to the FROM clause:
select 1 as a
On Sun, May 5, 2013 at 9:01 PM, Marti Raudsepp wrote:
> A STABLE function may call an IMMUTABLE function, but not the other way
> around.
Well no, an immutable function can and may call a stable (or even
volatile) function. Postgres won't stand in your way. It's probably a
bad idea unless it's c
On Sat, Mar 30, 2013 at 2:01 PM, wrote:
> uses all available memory (32GB). pts_key is an integer and the table
> contains about 500 million rows.
Please post the schema definition and all the log messages that occur
from this. If it Postgres runs out memory it should include a dump of
the memo
On Mon, Aug 13, 2012 at 7:17 PM, Adam Mackler wrote:
>
> Next, uncomment the final UNION four lines from the end. When I do
> that I then get a two row result. I'm not an expert on recursive
> CTEs, but I don't believe a UNION should decrease the number of rows
> returned.
I haven't dug through
On Wed, Apr 25, 2012 at 4:06 PM, Kevin Grittner
wrote:
> A CHECK constraint using a volatile function is potentially valid
> and useful, IMO. Think about a column which is supposed to record
> the moment of an event which has occurred. It could make sense to
> ensure that the timestamptz value i
On Wed, Apr 25, 2012 at 11:33 AM, wrote:
> Seeing as Postgres does not allow sub-queries in CHECK constraints yet, it
> doesn't make any sense to me for it to allow function calls, since functions
> can perform queries.
This is why functions must be marked as one of VOLATILE, STABLE, or
IMMUTABL
On Fri, Apr 13, 2012 at 8:40 PM, wrote:
> I am doing a large query so I limit the query to 550 but I get 88 rows
> returned. I increase this to 900 and get 136 rows returned ..
> explain Plan ...
Please send the query with and without the LIMIT.
It might also help to send more such as t
On Wed, Apr 11, 2012 at 2:04 AM, Tom Lane wrote:
> rnysm...@yahoo.com writes:
>> This month, we upgrade the libpq5 from 8.4.7 to 8.4.11.(libpq-dev
>> 8.4.11-0ubuntu0.11.04) Our service program become unstable after upgrading.
>
> It seems rather improbable that a deadlock inside glibc would be ou
On Thu, Sep 29, 2011 at 4:22 AM, Peter Eisentraut wrote:
>> Not sure what to do about this. Is it okay to suppose that collation
>> can be ignored when matching to a collation-less index?
>
> That sounds correct on first reading.
>
Doesn't this depend on the semantics of the ? operator?
Hypothe
On Tue, Sep 20, 2011 at 8:52 PM, Tom Lane wrote:
> However, it would
> be interesting to know what Oracle etc do with NaN and Infinity,
> assuming they even support such numbers.
Note that it looks like NUMBER cannot store either Infinity or NaN.
They can only occur in BINARY_FLOAT and BINARY_DOU
On Tue, Jun 7, 2011 at 3:33 PM, Tom Lane wrote:
> Greg Stark writes:
>> On Jun 3, 2011 4:20 PM, "Tom Lane" wrote:
>>> I'm inclined to write this off as "so don't do that". There's nothing
>>> that pg_dump can do to make this w
On Jun 3, 2011 4:20 PM, "Tom Lane" wrote:
>
> > [ view definition now fails due to multiple "id_a" columns ]
>
> I'm inclined to write this off as "so don't do that". There's nothing
> that pg_dump can do to make this work: it has to use the USING syntax
> for the join, and that doesn't offer any
On Sat, Apr 16, 2011 at 8:21 AM, Mark Kirkwood
wrote:
>
> I guess you have answered my first question - i.e yes this should eat
> massive amount of ram as written - however are you sure there is no memory
> leaking going on here?
The planner doesn't try to free up memory while it's working, it
ge
On Thu, Mar 31, 2011 at 11:33 PM, Kevin Grittner
wrote:
> Greg Stark wrote:
>
>> your query does require reading all the data.
>
> Huh? It requires reading all the data from at least *one* of the
> tables.
The query he posted a plan for was:
EXPLAIN ANALYZE select oi.i
On Wed, Mar 30, 2011 at 7:32 PM, Lawrence Cohan wrote:
> Please see updated attachment that includes the tables involved in the simple
> query below and all their indexes. We believe that the performance issue is
> due to the query not using any index but doing seq scans instead and this is
> v
On Fri, Mar 25, 2011 at 8:48 PM, Tom Lane wrote:
> Interesting, but I don't understand/believe your argument as to why this
> is a bad idea or fixed-size extents are better. It sounds to me just
> like the typical Oracle DBA compulsion to have a knob to twiddle. A
> self-adjusting enlargement be
On Fri, Mar 25, 2011 at 7:43 PM, Tom Lane wrote:
> I don't recall any particular discussion of making the user contend with
> that. My thought would be to do something like enlarging the table by
> 10% anytime we need to extend it. The main issue here is where to cause
> that to happen. An indi
On Fri, Mar 25, 2011 at 9:47 AM, Raman Sharma wrote:
> ERROR: could not extend relation "test_table": No space left on device
> HINT: Check free disk space.
>>
> But i have 27 GB space in my disk where it loaded and running query
Have you checked df -i ?
Also, this may seem like a silly questi
On Mon, Mar 7, 2011 at 11:55 PM, Mark Kirkwood
wrote:
> stuff | 23957 | 2011-03-08 06:02:02.659159+13 | VACUUM ANALYZE;
>
For what it's worth VACUUM ANALYZE does have to take an additional
lock to update the statistics. It should rarely cause any problems but
it is a possibility.
When you d
On Thu, Feb 24, 2011 at 7:31 PM, Merlin Moncure wrote:
> the root issue I think here is that the string version of the double
> precision math is approximated:
No, it's simpler than that, all double precision math is approximated.
The root issue is that 2183.67 is not representable in a floating
On Tue, Feb 22, 2011 at 8:48 AM, Daniel Farina wrote:
> The modern namespace OID is
> 378382, which is in line with a smooth monotonic increase over time.
Wait, what? namespace OID is the OID of the schema. The OID of an
object doesn't change over the lifetime of the object, it's a unique
identi
On Tue, Feb 22, 2011 at 7:14 AM, Mark Kirkwood
wrote:
> On 22/02/11 19:47, Heikki Linnakangas wrote:
>>
>> A long query on the same table can block vacuum. Vacuum needs to take a
>> so-called "cleanup lock" on each page, which means that it has to wait until
>> no other backend holds a pin on the
On Fri, Dec 3, 2010 at 4:50 AM, Tom Lane wrote:
> Even if you're willing to
> assume that the dictionary being used is the one defined by this
> module, that dictionary depends on external configuration files
> which are easily changeable.
Don't we have precedent for this in assuming that things
On Mon, Nov 15, 2010 at 4:51 PM, Tom Lane wrote:
> Actually, after consuming a bit more caffeine, I see what Yeb is on about.
> Even though the system in general doesn't make much of a distinction
> between zero-element arrays of different dimensionalities, there *are*
> functions that can disting
On Sat, Oct 30, 2010 at 11:23 AM, Tom Lane wrote:
>
> Anybody want to try Oracle, DB2, etc?
Oracle seems to behave like us:
SQL> select * from (select 1 as x from dual) where 1=1and x=1;
X
--
1
--
greg
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.or
On Thu, Oct 28, 2010 at 5:20 PM, Tom Lane wrote:
> I experimented a bit with mysql's behavior, and it seems that (at least
> in 5.1.51) what they do is treat "1and" or "2or" as if it were an
> identifier. They're definitely not throwing an error, at least not on
>
I guess the eleant question is
On Mon, Oct 25, 2010 at 8:03 AM, Tom Lane wrote:
> Perhaps. The new implementation of VACUUM FULL is really more like a
> CLUSTER, or one of the rewriting variants of ALTER TABLE. Should all
> of those operations result in an update of last_vacuum? From an
> implementation standpoint it's diffi
On Thu, Aug 5, 2010 at 7:28 PM, Alvaro Herrera
wrote:
>
> The scope is further reduced by the fact that this only seems to happen
> on Windows, and then only when the antivirus is messing around with the
> files.
So I suspect this could be triggered lots of ways. Imagine a ZFS
volume that runs ou
On Thu, Aug 5, 2010 at 12:55 PM, Hitesh Bhambhani
wrote:
> [HiteshB] I have noted your recommendation and will work with our Product
> Management to upgrade to the latest and greatest. Although we can't change
> the version that the customer has installed (8.2.9-1).
>
The latest and greatest is
On Thu, Aug 5, 2010 at 5:18 AM, Pavel Stehule wrote:
> The same problem can be with custom aggregates :( so this syntax isn't
> too robust. We can support Oracle's syntax in future releases, where
> syntax divide aggregate call and ORDER BY clause.
>
What syntax is that?
--
greg
--
Sent via p
On Wed, Aug 4, 2010 at 10:47 PM, Hitesh Bhambhani wrote:
>
> PostgreSQL version: 8.2.9-1
Firstly, the current release of 8.2 is 8.2.17. There are a long list
of bugs fixed in those intervening releases including one involving
vacuum truncating relations. I don't think it's the same problem but I
On Wed, Aug 4, 2010 at 11:19 PM, Tom Lane wrote:
> What we are doing here, IMO, is not just changing string_agg() but
> instituting a project policy that we are not going to offer built-in
> aggregates with the same names and different numbers of arguments ---
> otherwise the problem will come rig
On Tue, Aug 3, 2010 at 3:33 AM, Tom Lane wrote:
> Although this is the worst case, you could easily get overflows from
> intervals with ordinary endpoints that are sufficiently far apart.
Oh, duh, this is pretty obvious in retrospect.
> Since this is a nearly-dead legacy datatype, I can't get ex
On Mon, Aug 2, 2010 at 7:16 PM, John Regehr wrote:
> : Op: -, Reason : Signed Subtraction Overflow,
> BINARY OPERATION: left (int32): 2147483644 right (int32): -2147483648
>
> : Op: -, Reason : Signed Subtraction Overflow,
> BINARY OPERATION: left (int32): 2147483644 right (int32): -2147483648
>
On Mon, Jun 21, 2010 at 12:41 PM, Yuhui wrote:
>
> The following bug has been logged online:
>
> Bug reference: 5516
> Logged by: Yuhui
> Email address: xingyu...@gmail.com
> PostgreSQL version: 8.3,8.2,8.1
> Operating system: Linux,Windows
> Description: Memory grows u
On Mon, Jun 14, 2010 at 11:28 AM, Shinji Nakajima wrote:
> PostgreSQL version: 8.3.8
> Description: missing chunk number 0 for toast value X in
> pg_toast_X
>
> I delete a record, and the system restores, but prime cause is unknown.
> Will this be a bug of the databases?
Probably.
On Mon, Jun 7, 2010 at 5:36 PM, Piergiorgio Buongiovanni
wrote:
> I reused the previous command to re-set the sequence value to the right one,
> but I see that the START value is now 59100. I reused the previous command
> another time and the START value is now 30440.
>
> I think this is a bug. I
On Mon, Jun 7, 2010 at 3:52 PM, Robert Haas wrote:
>> Is there a way to make values of "undefined" type pass through the SELECT
>> DISTINCT filter (getting checked for uniqueness) but remain "undefined" if
>> all the values supplied for the column are "undefined"?
The concept of "uniqueness" de
On Fri, Jun 4, 2010 at 11:15 PM, Farid Zidan wrote:
> Now this not rocket science, it's simple insert statement where we do not
> want duplicates inserted. Works on 10 other DBMSs.
>
I find usually when one person is arguing something is complex and
someone else is arguing it's simple it's the pe
On Fri, Jun 4, 2010 at 7:18 PM, Farid Zidan wrote:
> If a simple SQL statement works on 9+ different databases
For what it's worth are you sure it works as you expect in these other
databases?
I suspect what they're doing is doing a DISTINCT of the text values
and then converting the results. Th
On Wed, May 12, 2010 at 2:44 AM, Tom Lane wrote:
> I think what you are describing is a kernel bug. There's not a lot
> we can do about it if the send() call hangs. Considering the kernel
> already knows the connection is closed (per the CLOSE_WAIT state shown
> by netstat) the send() should ret
On Fri, May 28, 2010 at 2:02 PM, Sakari Maaranen wrote:
> The documentation says that the best way to use autovacuum is to let the
> database vacuum often. However when the tables are very large, this can take
> a very long time.
>
In addition to Tom's comments, as of 8.4 this is no longer true a
On Wed, May 12, 2010 at 1:01 PM, Peter Eisentraut wrote:
> The problem with the bool type is that it could have different sizes on
> different systems. Which will lead to problems. I doubt that that
> problem exists with int4.
>
I could imagine macros that do the wrong thing if the types they u
On Tue, May 11, 2010 at 8:47 PM, Tom Lane wrote:
> Alex Hunsaker writes:
>
>> You mean i'd get the pleasure of 'fixing' all my 3rd party C modules?
>
> Yeah, it's the implications for 3rd-party modules that make me not want
> to do this. A search & replace on our own code base is one thing, but
On Sun, May 9, 2010 at 6:04 PM, Tom Lane wrote:
> Huh? We build just fine on C99 compilers, AFAIK. Or are you saying
> that we should try to adopt 's definition of bool? The
> problem there is, again, that we don't know what width that will be.
No, I'm saying we should use something like pgboo
On Sun, May 9, 2010 at 5:58 PM, Tom Lane wrote:
> Yeah, I know those #if's are there, but whether they actually do
> anything useful is highly questionable. There is no reason to assume
> that a compiler's built-in version of bool will be bit-compatible with
> ours. And changing the width of boo
yes, that's on the todo list.you can search back in the archives for
discussions on how to do this without making the code difficult to debug.
this is a bug but it's a longstanding known bug inan area where we have
lots of known limitations and nobody is too excited about spending lots of
effort
2010/2/26 Oleg Serov :
> Up! Anybody will answer about the patch?
The patch causes the inheritance history to be lost. If you
subsequently drop the column form the parent it'll be kept on the
child because it was explicitly declared when you created the child.
In the original structure if you drop
On Fri, Jan 22, 2010 at 2:02 PM, Greg Stark wrote:
> The question arises why Postgres can't automatically detect that this
> query is equivalent.
Hm, actually rereading your query it's not technically equivalent.
Since you weren't grouping on contact.id or contact_type.co
On Thu, Jan 21, 2010 at 9:27 PM, Allen Johnson wrote:
> What I noticed in the production query was that ~1000ms was spent on
> sorting alone. The hack query reduced that to ~400ms. I should also
> note that there was plenty of work_mem and that the sort was not
> hitting disk.
>
The "hack" form a
What postgres version?
In any case there is not enough information here to identify what
happened. What does "not all key references had been cleaned up" mean?
What commands did you run and what results did they have?
On Tue, Jan 12, 2010 at 4:26 PM, Ted Clark wrote:
> BUG #2197: PostgreSQL erro
On Sat, Jan 2, 2010 at 1:37 PM, hubert depesz lubaczewski
wrote:
> CONSTRAINT overlapping_times EXCLUDE USING GIST (
> box(
> point( extract(epoch FROM from_ts at time zone 'UTC'),
> extract(epoch FROM from_ts at time zone 'UTC') ),
> point( extract(epoch FROM to_t
On Mon, Dec 21, 2009 at 5:04 PM, Ankit Kumar wrote:
> Thanks for your response. Hibernate works well when I change the DB to SQL
> server but somehow the moment I point to Postgresql it start generating
> OutOfMemory. Is there some configuration at DB end to ensure it starts using
> the cursors.
On Sun, Dec 20, 2009 at 1:12 PM, Jyrki Wahlstedt
wrote:
> Trying to make a universal build leads to following:
> /usr/bin/gcc-4.2 -no-cpp-precomp -O2 -arch x86_64 -arch i386 -Wall
>
I'm not sure where you've gone wrong but I know others facing the same
problem have found that they need to run con
On Mon, Dec 21, 2009 at 12:54 PM, Ankit Kumar wrote:
> I am running a Criteria.scroll() on postgresql on a DB containing 2M
> records. The memory keeps increasing and finally it generates an
> OutOfMemoryException. Please can you advice how to fix this.
>
> Postgresql DB version: 8.4
> Postgresql
On Tue, Dec 15, 2009 at 5:18 PM, Robert Haas wrote:
> I suppose that I could fix this by getting rid of my swap partition
> altogether, but that seems a rather extreme solution, and it's
> certainly not the way most UNIX/Linux systems I run across are
> configured, if for no other reason than that
On Tue, Dec 15, 2009 at 4:16 PM, Robert Haas wrote:
> I didn't know that, but it I think by the time malloc returns 0
> usually other bad things are happening. I don't think that's really
> an answer.
Only if, as Craig said and you disputed, you have overcommit enabled
or lots of swap.
There is
On Tue, Dec 15, 2009 at 3:44 PM, Robert Haas wrote:
> This is an
> issue that other people have run into in the past, and I don't think
> we have a good solution. I wonder if we should put some kind of a
> limit in place so that queries like this will at least fail relatively
> gracefully with a
On Mon, Nov 9, 2009 at 9:48 AM, digitaldeath wrote:
> Everybody is doing SELECT only on "adc" table, so why deadlocks if there
> are no write attempts on any row?
Well the deadlock error does include the information about what
queries deadlocked. In newer versions it includes the full text of the
It's your "fault" though I don't know how you would know that without
knowing a lot about how postgres handles internal locking.
The problem is that the creat table as select * from adc takes a share
lock on adc then later the rename table upgrades the lock. This is
always a deadlock risk.
On Fri, Oct 30, 2009 at 11:22 AM, Stefan Kaltenbrunner
wrote:
> ok I now see why you (and I) failed to reproduce the problem - it only
> causes clusters/databases to crash that were actually generated using the
> upthread mentioned script. it does NOT fail using a dump generated by a
> database th
On Thu, Oct 29, 2009 at 2:14 PM, Stefan Kaltenbrunner
wrote:
> ExecHashJoinSaveTuple (tuple=0xb49c8870, hashvalue=3316173823,
> fileptr=0x96185a8) at nodeHashjoin.c:775
> 775 BufFile *file = *fileptr;
>
That back trace doesn't make much sense. That function only has one
call site a
So one of the elephants in the room in this (rather dead-end)
discussion is that one of the things "unknown" is good for is the fact
that most clients don't bind their parameter types to specific types.
Doing so is extremely cumbersome in just about every interface because
it forces you to think ab
On Wed, Sep 2, 2009 at 3:44 PM, Jeff Davis wrote:
> On Wed, 2009-09-02 at 08:57 -0500, Kevin Grittner wrote:
>> > (a) leaving a literal as "unknown" until you've finished
>> > inferring types (current behavior)
>> > (b) casting every unknown to text immediately, and then trying to
>> >
On Wed, Aug 26, 2009 at 10:12 PM, Alvaro Herrera wrote:
>
> The frustrating thing about this, is that we complain over and over, and
> hub.org email setup keeps breaking every so often.
The problem is not that it keeps breaking -- that's normal. The
problem is that it breaks and he's not aware bec
On Wed, Aug 26, 2009 at 7:59 PM, Gergely
Czuczy wrote:
> AFAIK exim generates a bounce to test the address, and for that I'm
> getting a reject saying that the user is unknown for the VERP address.
>
> Aug 26 04:02:05 hostname exim[70819]: H=mx1.hub.org
> [200.46.208.106] sender verify fail for
>
On Wed, Aug 26, 2009 at 7:29 AM, Gergely
Czuczy wrote:
>
> The following bug has been logged online:
>
> Bug reference: 5012
> Logged by: Gergely Czuczy
> Email address: gergely.czu...@harmless.hu
> PostgreSQL version: 8.4
> Operating system: FreeBSD
> Description: maili
On Wed, Aug 26, 2009 at 4:38 PM, Craig
Ringer wrote:
> If it is in fact postgres.exe that crashes at some point, it'd also
> *REALLY* help to have a backtrace of the crash.
If Postgres crashes due to running out of memory it prints a memory
dump to its log which would (hopefully) make it clear whe
On Mon, Aug 24, 2009 at 11:38 PM, Peter Eisentraut wrote:
> On mån, 2009-08-24 at 23:07 +0100, Greg Stark wrote:
>> I think it's a conceit to think we always fix bugs immediately.
>
> I completely agree with that one. The claim that we don't need a bug
> tracker
On Mon, Aug 24, 2009 at 10:16 PM, Peter Eisentraut wrote:
>
> Well, all you'd really need is that if you close a bug, you indicate
> that say via an email header
>
> X-PG-Bugs-Close: 12345
>
> and then spice up the archives display to show that somehow. But the
> chances of getting people to use t
On Mon, Aug 24, 2009 at 8:03 PM, Alvaro
Herrera wrote:
> Personally I still think debbugs would suit us perfectly, but 1. I don't
> have time to handle it, 2. nobody else believes this, 3. the debbugs
> developers are not very interested in helping us use it.
I've been shouting about debbugs forev
On Sun, Aug 23, 2009 at 4:48 AM, Craig
Ringer wrote:
> Interestingly, though, the test program does appear to be leaking - at
> least, the peak working set slowly climbs. It's all private working set. Not
> sure why yet since the memory use looks like it _should_ be constant.
How does the return v
On Wed, Aug 19, 2009 at 4:50 PM, Shivesh
Wangrungvichaisri wrote:
> 8) In our real application, since we INSERT a large amount of data per
> query, as well as SELECT a large amount of data per query, the memory leak
> is much worse, and postgres.exe crashes after its memory consumption has
> reache
2009/8/22 Radoslaw Zielinski :
> $ seq 11 | xargs -ti psql bug -c "select {}, (x).* from (select
> bt_page_items('promocje_pkey',{}) as x ) as y"
> [...]
> psql bug -c select 11, (x).* from (select bt_page_items('promocje_pkey',11)
> as x ) as y
> ERROR: block number out of range
Sorry, I f
2009/8/22 Radoslaw Zielinski :
> bug=# select length(opis_szczeg) from promocje where id = 4300;
> ERROR: missing chunk number 0 for toast value 120741 in pg_toast_29644
Sorry, what datatype is this again? And what encoding?
Perhaps I should have said octet_length() instead of length().
--
2009/8/21 Radoslaw Zielinski :
> Greg Stark [2009-08-21 18:38]:
> [...]
>> the toast table. Not unless you can dump the whole index and find
>> pointers in there or can find the details in the wal log.
>
> You mean the primary key index? How do I dump it?
Actually I me
2009/8/21 Radoslaw Zielinski :
> Greg Stark [2009-08-21 18:03]:
>> On Fri, Aug 21, 2009 at 4:04 PM, Radoslaw Zielinski
>> wrote:
>>> This particular row currently has last_modified="2009-08-11", but table_log
>>> says it has been updated on "2009-
On Fri, Aug 21, 2009 at 5:15 PM, Alvaro
Herrera wrote:
> I wonder if this could be explained by xid=6179 not marked as committed
> in clog. I'd try flipping that bit and see what happens ...
Well nothing's going to help much now. Firstly, once the hint bit gets
set nothing second-guesses that and
On Fri, Aug 21, 2009 at 5:03 PM, Greg Stark wrote:
> On Fri, Aug 21, 2009 at 4:04 PM, Radoslaw Zielinski
> wrote:
>
> Here's a dump of that page btw.
... [crap word-wrapped by gmail]
Sorry, clearly gmail sucks for posting things that you actually care
about how they're fo
On Fri, Aug 21, 2009 at 4:04 PM, Radoslaw Zielinski wrote:
> This particular row currently has last_modified="2009-08-11", but table_log
> says it has been updated on "2009-08-12" -- so, data loss.
These are all very low transaction ids. you say it was a week of
production before this happened?
> Description: Optimizer does not use function-based index for an order
> by
> Details:
>
> Subject line says it all.
The optimizer makes an educated guess about whether to use indexes or
not. Without more information it's impossible to second-guess it.
You might want to ask on pgsql-gener
On Wed, Aug 12, 2009 at 3:15 AM, Tom Lane wrote:
> "Ian Turner" writes:
>> The following queries are equivalent, because there are no integers between
>> 5 and 6 and because the BETWEEN operator contemplates a closed range.
>> SELECT * FROM example WHERE pk IN (5,6);
>> SELECT * FROM example WHERE
On Wed, Jul 29, 2009 at 11:34 AM, Ole Tange wrote:
> EXPLAIN tells me the LEFT JOIN does table scan as well. It seems the
> primary reason why your LEFT JOIN is faster than my 3 line alternative
> is because I do DELETEs, which is slow. So thank you for the LEFT JOIN
> idea.
If you don't want the
On Fri, Jul 24, 2009 at 6:02 AM, Tom Lane wrote:
> I think the only thing we could do about it is downgrade the implicit
> casts to "name", which seems like a cure worse than the disease ---
> it'd interfere with searches in the system catalogs.
We could try to avoid user-visible functions like cu
I don't think it even has to be so specific. We should just always
rewrite bool <> bool into bool = NOT bool.
Hmm. That only has a 50/50 chance of creating an indexable clause.
Perhaps we could even rewrite it as "a = NOT b AND NOT a = b".
--
Greg
On 2009-07-17, at 3:21 PM, Tom Lane wro
On Thu, Jul 16, 2009 at 9:07 PM, Roman Kononov wrote:
>
> test=# create table junk(i int);
> CREATE TABLE
> test=# select * from junk left outer join (select coalesce(i,1) as x,
> coalesce(i,2) as y from junk) t on coalesce(i,3)=x and coalesce(i,4)=y and
> coalesce(i,5)=x;
> ERROR: too few pathkey
On Mon, Jul 6, 2009 at 7:20 PM, Bruce Momjian wrote:
> I feel like someone should take a flame-thrower to that file. ;-)
If you were half the man you used to be would you?
--
greg
http://mit.edu/~gsstark/resume.pdf
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make change
On Mon, Jul 6, 2009 at 5:40 PM, Peter Headland wrote:
> presence
> of a '(' character anywhere at all in the string literal triggers the
> problem. For example 'abc(def'.
Except according to that explain analyze 'abc(def' ran exactly the
speed as 'abc()def'.
This all seems much more likely to dep
On Sun, Jul 5, 2009 at 5:10 PM, Greg Stark wrote:
> On Sun, Jul 5, 2009 at 4:28 PM, Tom Lane wrote:
>> when i done dump->restore i
>>> have surprise,
>>> Column ordering was changed.
>>
>> This is not a bug, it's the intended behavior.
>
> I t
On Sun, Jul 5, 2009 at 4:28 PM, Tom Lane wrote:
> when i done dump->restore i
>> have surprise,
>> Column ordering was changed.
>
> This is not a bug, it's the intended behavior.
I thought that was a bug, just one that was too hard to fix for the
problems it caused. It might be more fixable if we
On Fri, Jun 26, 2009 at 1:44 AM, Tom Lane wrote:
> Maybe putting "o" into the options in doc/Makefile is a good
> idea.
I wonder why we have tarballs inside of tarballs. Why not just have
the files directly in a subdirectory of the install tarball already?
> I'm wondering why we've not had compl
On Wed, Jun 10, 2009 at 4:32 PM, Simon Bertrang wrote:
> On Wed, Jun 10, 2009 at 05:20:00PM +0200, Simon Bertrang wrote:
>> On Wed, Jun 10, 2009 at 10:05:36AM -0400, Tom Lane wrote:
>> > Greg Stark writes:
>> > > This seems really weird. Firstly, doesn't Op
1 - 100 of 105 matches
Mail list logo
