The following bug has been logged online:
Bug reference: 2723
Logged by: Simon
Email address: [EMAIL PROTECTED]
PostgreSQL version: 8.0 - 1.2.1
Operating system: windows XP
Description:Provider / driver connection for VB.NET
Details:
Hello, I'm Simon I beg for
ed output.
If you wish, you may use UNION ALL, which avoids the DISTINCT step, but
this would not guarantee that the ordering would be anything at all, as
before.
Bottom line: If you care about the ordering of rows returned by a query,
you should use ORDER BY to specify the desired result
The following bug has been logged online:
Bug reference: 5664
Logged by: simon
Email address: xuboc...@163.com
PostgreSQL version: 8.3.11
Operating system: suse 10 Linux omu 2.6.16.60-0.54.5-bigsmp #1 SMP Fri Sep
Description:index "idx000_mytable19"
good idea. It is already on the TODO,
described as "materialized views", though I like your name for it also,
since that is the main use case.
http://www.postgresql.org/docs/faqs.TODO.html
--
Simon Riggs www.2ndQuadrant.com
PostgreSQL Training, Services and Support
--
Sent via pgsql-b
http://myns.com/ns']]) from test;
> -- bad
> select xpath('name(/my:a/*[last()])', test, ARRAY[ARRAY['my',
> 'http://myns.com/ns']]) from test;
What error messages are you getting?
Why do you think this should work? Best post a test case using another
tool,
ves.postgresql.org/pgsql-bugs/1998-06/msg00049.php
My perceptions may not match others...
--
Simon Riggs www.2ndQuadrant.com
PostgreSQL Training, Services and Support
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
On Tue, 2008-08-05 at 18:00 -0500, Jaime Casanova wrote:
> On 8/5/08, Tom Lane <[EMAIL PROTECTED]> wrote:
> > Simon Riggs <[EMAIL PROTECTED]> writes:
> > > I've never seen anyone scan backwards like this at all in practical use.
> >
> > &
| 0
> n_live_tup | 162
> n_dead_tup | 0
> last_vacuum |
> last_autovacuum |
> last_analyze | 2008-09-24 15:13:13.423424-04
> last_autoanalyze |
>
>
> So question i have is, is this normal operation,why we need to analyze
> twice to updates
selessly. If idle, it shouldn't even
> appear
> in powertop's profile.
--
Simon Riggs www.2ndQuadrant.com
PostgreSQL Training, Services and Support
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
On Mon, 2009-01-05 at 12:21 +0100, Martin Pitt wrote:
> Hi Simon,
>
> Simon Riggs [2009-01-05 10:57 +]:
> > Is this 11 per minute, or 11 per second?
>
> Per second.
Seems consistent with wal_writer_delay = 200ms and bgwriter_delay =
200ms, plus some other minor nois
ouldn't prevent us from restarting the whole server. Plus, if we have
to use pg_resetxlog to get us out of trouble it isn't going to help much
with diagnosis. We can rebuild indexes once server is up.
--
Simon Riggs www.2ndQuadrant.com
PostgreSQL Training, Services and Support
ently.
I'd rather have a database that works, but has a corrupt index than one
that won't come up at all.
--
Simon Riggs www.2ndQuadrant.com
PostgreSQL Training, Services and Support
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make c
On Thu, 2009-01-08 at 14:19 -0500, Tom Lane wrote:
> Simon Riggs writes:
> > On Thu, 2009-01-08 at 13:40 -0500, Tom Lane wrote:
> >> No, that seems utterly unsafe to me. We'd have a corrupt index and
> >> nothing to cause it to get repaired.
>
> > We
On Thu, 2009-01-08 at 15:04 -0500, Tom Lane wrote:
> Simon Riggs writes:
> > On Thu, 2009-01-08 at 14:19 -0500, Tom Lane wrote:
> >> If the btree in question is a critical system index, your value of
> >> "work" is going to be pretty damn small.
>
>
eigh any likely
> benefit.
Agreed. It's too confusing the other way.
The manual entry wasn't changed from my original submission
unfortunately.
--
Simon Riggs www.2ndQuadrant.com
PostgreSQL Training, Services and Support
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
On Thu, 2009-01-15 at 12:43 -0500, Bruce Momjian wrote:
> OK, do you have updated wording?
We are not changing the code, so Heikki's wording is appropriate since
it matches the code.
--
Simon Riggs www.2ndQuadrant.com
PostgreSQL Training, Services and Support
--
Sent v
The following bug has been logged online:
Bug reference: 4620
Logged by: Simon Keen
Email address: simon.k...@eglimited.co.uk
PostgreSQL version: 8.3.5
Operating system: Ubuntu Linux
Description:Unexpected(doc'd) side effects of using serial and rules
Details
access to NEW and OLD it means row level triggers and the performance
issues they bring with changes in large numbers of rows.
Cheers
Simon Keen
-Original Message-
From: Tom Lane [mailto:t...@sss.pgh.pa.us]
Sent: 18 January 2009 16:35
To: Simon Keen
Cc: pgsql-bugs@postgresql.org
Subject: Re
her than from the sequence of actions.
A more useful thing might be to do an xlog switch before we do the
shutdown checkpoint at end of recovery. That gives the same sequence of
actions without modifying the existing sequence of activities for
backups, which is delicate enough for me to not want t
On Thu, 2009-05-07 at 17:54 +0300, Heikki Linnakangas wrote:
> Simon Riggs wrote:
> > On Thu, 2009-05-07 at 12:15 +0300, Heikki Linnakangas wrote:
> >
> >> Yeah, I think you're right. If you omit pg_xlog from the base backup,
> >> as we recommend in the ma
s fragile and I would prefer a more
explicit solution. Recording the timeline history permanently with each
server would be a sensible and useful thing (IIRC DB2 does this).
--
Simon Riggs www.2ndQuadrant.com
PostgreSQL Training, Services and Support
--
Sent via pgsql-bugs mailin
eSQL on a new BSD version, but if you upgrade
PostgreSQL and use VACUUM instead you will see improvement.
--
Simon Riggs www.2ndQuadrant.com
PostgreSQL Training, Services and Support
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscript
ot enough, since findNewestTimeLine() is
> still based on the premise that *all* the history files exist.
> So, as Simon says, we should clearly say that a history file
> must not be deleted from the archive. Or, we should create
> a new solution.
I will feel safer if we keep history
we just access
the appropriate local directory. Call it pg_history or pg_timeline etc..
Not under pg_xlog!
There is no particular reason to send history files to the archive,
since new ones are only ever generated at the end of an archive
recovery.
Now that we increment the timeline more oft
On Fri, 2009-05-15 at 12:56 +0100, Simon Riggs wrote:
> There is no particular reason to send history files to the archive,
> since new ones are only ever generated at the end of an archive
> recovery.
It also clears up a long standing confusion between backup history files
and timelin
x27;s document that timeline files should not be deleted from the
archive iff there exists a base backup made during a lower numbered
timeline.
--
Simon Riggs www.2ndQuadrant.com
PostgreSQL Training, Services and Support
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
On Fri, 2009-05-15 at 15:41 +0300, Heikki Linnakangas wrote:
> Simon Riggs wrote:
> > On Fri, 2009-05-15 at 12:56 +0100, Simon Riggs wrote:
> >
> >> There is no particular reason to send history files to the archive,
> >> since new ones are only ever g
in a
> > WAL file that contains records from a lower numbered timeline.
>
> Ah, sorry.
No worries. Thanks for reporting the original bug and for staying
involved while we think of how to handle the problems it highlights.
--
Simon Riggs www.2ndQuadrant.com
Postgr
blem and the rules by which we can work
out exactly which history files to keep, I think it is safer to say that
we must keep all history files.
--
Simon Riggs www.2ndQuadrant.com
PostgreSQL Training, Services and Support
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postg
docs. What would be the objection to
that?
And you guys wonder why I get frustrated trying to fix things.
--
Simon Riggs www.2ndQuadrant.com
PostgreSQL Training, Services and Support
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to
On Fri, 2009-05-15 at 17:39 +0300, Heikki Linnakangas wrote:
> > We've asked for some additional docs. What would be the objection to
> > that?
>
> I'm certainly not opposed to improving docs.
OK, so will you update the docs as requested?
--
Simon Riggs
's one reason for all the debate.
No problem in receiving feedback, just want to be able to understand it
sufficiently well to be able to enhance it.
--
Simon Riggs www.2ndQuadrant.com
PostgreSQL Training, Services and Support
--
Sent via pgsql-bugs mailing list (pgsql-bugs@p
't even begun to think of what such tools might look like.
That's OK. Wanting it to be different is the first step. I want to
improve it as well, though without removing features.
--
Simon Riggs www.2ndQuadrant.com
PostgreSQL Training, Services and Support
--
Sent via pgs
better if there was a section on remvong files from the
archive.
Do I really need to write a patch to say that, have you formally review
it, then change the wording to what you would have written in the first
place and then commit? Really? How many years do all of us have to work
together befo
umentation's rather offhand
> statement about this,
Cool
> but let's clarify it correctly.
Of course.
--
Simon Riggs www.2ndQuadrant.com
PostgreSQL Training, Services and Support
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
e but use
-Wl,-Bdynamic instead. This became necessary with 8.4, otherwise
psql won't start because lazy binding fails.
The good news though is that i'm running 8.4beta2 successfully on
-current OpenBSD/amd64 with this.
Kind regards,
Simon
Inde
and how to solve it?
>
Not sure if this is a bug (i've seen it too) but you can solve it by
using template0:
$ createdb -E UTF8 -T template0 foo
Regards,
Simon
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
On Wed, Jun 10, 2009 at 02:19:30PM +0100, Greg Stark wrote:
> On Wed, Jun 10, 2009 at 10:25 AM, Simon Bertrang wrote:
> >
> > the following patch does two things on OpenBSD:
>
> Thank you.
>
>
> > 1) Add missing libs to the krb5/com_err check that are required.
... it does have kerberos
> enabled ...
>
Indeed a good question. I'm comparing the config and build logs but
nothing jumped into my face yet. I should fire up my sparc64 to have the
same arch as spoonbill for comparison... configure flags differ too...
i'll let you know whe
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 OpenBSD use ELF? Shouldn't
> > > the library pull in the indi
fferent trigger
> event types. Patch attached.
Thanks for fixing Greg.
--
Simon Riggs www.2ndQuadrant.com
PostgreSQL Training, Services and Support
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
x86_64
> Description:bgwriter fails to fsync the file in recovery mode
> Details:
Looking at it now.
--
Simon Riggs www.2ndQuadrant.com
PostgreSQL Training, Services and Support
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription
ents of startup's pendingOpsTable will be ignored.
That looks to me to be a serious bug.
--
Simon Riggs www.2ndQuadrant.com
PostgreSQL Training, Services and Support
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgre
n lose data when an
> archive recovery crashes after a restartpoint.
Yes, that's what I see also. Patch attached.
--
Simon Riggs www.2ndQuadrant.com
PostgreSQL Training, Services and Support
Index: src/backend/access/transam/xlog.c
is coded. 2PC seems to assume that if a file still exists
we must be in recovery and its OK to ignore.
Clean? We've changed the conditions under which the unlink needs to be
registered and !InArchiveRecovery defines the changed conditions
precisely.
--
Simon Riggs www.2ndQu
course, to avoid derailing the schedule.
Please define "temporarily". Will it be re-enabled in 8.4.1, assuming we
find an acceptable fix?
> It's
> obviously not been adequately thought through or tested.
Hmmm...
--
Simon Riggs www.2ndQuadrant.com
PostgreSQL
CKPOINT_IS_SHUTDOWN |
CHECKPOINT_FORCE |
CHECKPOINT_WAIT)
else
should make the startup process wait for bgwriter to complete the
checkpoint. But we need to set LocalRecoveryInProgress appropriately
also.
--
Simon Riggs www.2ndQuadrant.com
PostgreSQL Training, S
> restartpoint, which will flush any fsync requests bgwriter has
> accumulated, before doing the actual checkpoint in the startup
> process.
That looks fine.
> This is completely untested still, but does anyone immediately see any
> more problems?
Nothing seen.
--
Simon Riggs
On Thu, 2009-06-25 at 19:20 +0300, Heikki Linnakangas wrote:
> Simon Riggs wrote:
> >
> But we need to set LocalRecoveryInProgress appropriately
> > also.
>
> Yeah, the trouble is to tell bgwriter that it's OK for it to create the
> checkpoint, which includes w
is now.
I didn't read the parts of the patch that were described as being from
my patch. Heikki, please tell me if you change things... it means I have
to be both patch author and reviewer. Perhaps just separate patches, so
we can review them independently.
--
Simon Riggs
On Thu, 2009-06-25 at 12:43 -0400, Tom Lane wrote:
> What about "revert the patch"?
That's probably just as dangerous.
Much easier to just avoid that state altogether, if you must.
--
Simon Riggs www.2ndQuadrant.com
PostgreSQL Training, Services and Support
to cause the final mdsync to fail?
>
> Yes, I just noticed that myself, testing it for the first time. That
> check needs to be suppressed in the startup checkpoint.
Better to do it as it was in my patch. We can turn off/on then.
--
Simon Riggs www.2ndQuadrant.com
PostgreSQ
ily true for some reason, but it doesn't sound
like it is a safe assumption. I would guess it's using isRedo as an
implicit override rather than using the correct meaning of the variable.
--
Simon Riggs www.2ndQuadrant.com
PostgreSQL Training, Services and Support
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
eems we
should correct the caller rather than change the API and potentially
effect all callers.
--
Simon Riggs www.2ndQuadrant.com
PostgreSQL Training, Services and Support
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subs
On Thu, 2009-06-25 at 21:59 +0300, Heikki Linnakangas wrote:
> I think my initial analysis of this bug was bogus.
Perhaps, but the pendingOpsTable issue is a serious one, so we haven't
wasted our time by fixing it.
--
Simon Riggs www.2ndQuadrant.com
PostgreSQL Training,
On Thu, 2009-06-25 at 15:10 -0400, Tom Lane wrote:
> Are you (Heikki and Simon) in a position to finish these things today?
Certainly will try.
--
Simon Riggs www.2ndQuadrant.com
PostgreSQL Training, Services and Support
--
Sent via pgsql-bugs mailing list (pgsql-b
n accumulating such requests.
> * need to do something about IsRecovery tests that will now be executed
> in bgwriter
Yes
> * need to fix mistaken code in FinishPreparedTransaction
Yes
--
Simon Riggs www.2ndQuadrant.com
PostgreSQL Training, Services and Support
--
Sent vi
ecovery can also be replaced by
RecoveryIsInProgress()
So, yes, there are some places where InRecovery is used in code executed
by the bgwriter, but the correct fix is to use RecoveryIsInProgress().
It is a hack to try to set the InRecovery state flag in bgwriter and one
that would change the clea
r point of how we code the fix
to the bug we do have.
--
Simon Riggs www.2ndQuadrant.com
PostgreSQL Training, Services and Support
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
On Thu, 2009-06-25 at 17:11 -0400, Tom Lane wrote:
> Simon Riggs writes:
> > So, yes, there are some places where InRecovery is used in code executed
> > by the bgwriter, but the correct fix is to use RecoveryIsInProgress().
>
> Agreed, but this gets us no closer to sol
e its way to disk. The code in 8.4
does a few things to improve that but the base problem persists and
revoking code won't change that. We should describe the issue in the
docs and leave it at that - there is no particular reason to believe
anybody would want to do such a thing.
--
Simon Riggs
hy any of this has been done.
At this stage of RC, I expected you to post the patch and have the other
2 people working actively on this issue review it before you commit.
--
Simon Riggs www.2ndQuadrant.com
PostgreSQL Training, Services and Support
--
Sent via pgsql-bugs mailin
On Thu, 2009-06-25 at 18:40 -0400, Tom Lane wrote:
> Simon Riggs writes:
> > On Fri, 2009-06-26 at 00:37 +0300, Heikki Linnakangas wrote:
> >> Ok, I've committed the above fixes everyone agreed on.
>
> > At this stage of RC, I expected you to post the patch
On Thu, 2009-06-25 at 19:16 -0400, Tom Lane wrote:
> Simon Riggs writes:
> > On the patch, the kluge to set InRecovery is unnecessary and confusing.
>
> I'll look into a better way to do that tonight. Did you have any
> specific improvement in mind?
Yes, all already m
On Thu, 2009-06-25 at 20:25 -0400, Tom Lane wrote:
> Simon Riggs writes:
> > On Thu, 2009-06-25 at 19:16 -0400, Tom Lane wrote:
> >> Simon Riggs writes:
> >>> On the patch, the kluge to set InRecovery is unnecessary and confusing.
> >>
> >> I&#x
> of the standby server, because that affects the failover time, for example.
An important point.
The update rate "should" be once per clock cycle at most and should
occur in bgwriter not startup. If there is evidence of a problem then I
would support reducing the update rate. The pur
On Fri, 2009-06-26 at 05:14 +0100, Simon Riggs wrote:
> On Thu, 2009-06-25 at 20:25 -0400, Tom Lane wrote:
> > What I am thinking is that instead of the hack of clearing
> > LocalRecoveryInProgress to allow the current process to write WAL,
> > we should have a s
gt; This doesn't matter too much yet but it will for hot standby.
IIUC you think it is safest to *not* write hint bits during Hot Standby?
So we would treat all commits as async commits?
--
Simon Riggs www.2ndQuadrant.com
PostgreSQL Training, Services and Support
--
Sent vi
that the value of the node is unset.
That means XLOG_GIN_INSERT_LISTPAGE always has specNode == 0 and so
triggers the assertion failure.
--
Simon Riggs www.2ndQuadrant.com
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www
On Tue, 2009-09-15 at 09:41 +0300, Heikki Linnakangas wrote:
> Simon Riggs wrote:
> > In recovery of GIN operations using CVS HEAD I see consistently
> >
> > TRAP: FailedAssertion("!(((bool) ((spcNode) != ((Oid) 0", File:
> > "tablespace.c",
On Tue, 2009-09-15 at 14:31 -0400, Tom Lane wrote:
> Simon Riggs writes:
> > On Tue, 2009-09-15 at 09:41 +0300, Heikki Linnakangas wrote:
> >> This means that the WAL replay of that record type has never been tested
> >> correctly :-(.
>
> > This must have b
On Tue, 2009-09-15 at 15:34 -0400, Tom Lane wrote:
> Simon Riggs writes:
> > On Tue, 2009-09-15 at 14:31 -0400, Tom Lane wrote:
> >> I've pointed out before that the regression tests are not particularly
> >> meant to provide an exhaustive test of WAL recovery.
On Tue, 2009-09-15 at 12:09 -0400, Tom Lane wrote:
> I'm working on this now.
Thanks to you and Heikki for fixing this while I worked around it.
--
Simon Riggs www.2ndQuadrant.com
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subs
tion test for use in
superuser().
--
Simon Riggs www.2ndQuadrant.com
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
The following bug has been logged online:
Bug reference: 5344
Logged by: Simon Ng
Email address: simon94...@yahoo.com
PostgreSQL version: 8.1.11
Operating system: RedHat Linux
Description:pg_restore some foreign keys missing
Details:
from server1 with Postgres
gadmin.org/support/list.php
I think we need to work on a distribution mechanism for such requests,
rather than trouble bug reporters with our bureaucracy. pgAdmin has been
bundled with Postgres for some time now.
--
Simon Riggs www.2ndQuadrant.com
--
Sent via pgsql-bugs mailin
gt; WARNING: PD_ALL_VISIBLE flag was incorrectly set in relation
> "pgbench_tellers" page 0
> WARNING: PD_ALL_VISIBLE flag was incorrectly set in relation
> "pgbench_tellers" page 1
Understandable.
Time to remove vacuum_defer_cleanup_age, I think.
--
Simon R
, I propose
removing it.
Would you agree or disagree with the suggested removal?
--
Simon Riggs www.2ndQuadrant.com
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
On Wed, 2010-03-10 at 17:55 -0500, Tom Lane wrote:
> Simon Riggs writes:
> >>> Time to remove vacuum_defer_cleanup_age, I think.
> >>
> >> Umm, so what's the bug?
>
> > Whether you call it a bug or just an annoyance is debatable, but the
> &
On Wed, 2010-03-10 at 17:12 -0800, Josh Berkus wrote:
> On 3/10/10 3:26 PM, Simon Riggs wrote:
> > OK, that's enough to not remove it. I was aware of more negative
> > thoughts and conscious of my own feelings about it being a kluge.
>
> Well, it *is* a kludge, but
a kluge, that's why.
It's also my 3rd choice of solution behind fine-grained lock conflicts
(1st) which would avoid many issues and master/standby in lock step
(2nd).
Having said that I'm much in favour of providing a range of options and
then letting users tell us what w
POSTGRESQL BUG REPORT TEMPLATE
Your name : Simon Banton
Your email address : [EMAIL PROTECTED
roblem and so I'm not sure if people will spend
time on trying to make that work.
Use an indirect key or some other mechanism, such as Inserting into
another table and renaming them.
--
Simon Riggs
EnterpriseDB http://www.enterprisedb.com
--
as a result of the regular expression comparison. As a result the
planner thinks it can choose a nested loops scan, though ends up doing
1892 seq scans of persons, when it thought it would do only one.
The under estimation is a known issue. Posting to -perform for the
record.
--
The following bug has been logged online:
Bug reference: 2521
Logged by: Simon, Attila
Email address: [EMAIL PROTECTED]
PostgreSQL version: 8.1.4
Operating system: MS Windows XP (the worst)
Description:pg_restore is hanging
Details:
We have dumped a database with
part of the query clause for all values of the parameter.
So its best to look for some other static definition of the index.
I'll submit a doc patch.
--
Simon Riggs
EnterpriseDB http://www.enterprisedb.com
---(end of broadcast)---
TI
said. I see no security problem as a result of this
behaviour.
--
Simon Riggs
EnterpriseDB http://www.enterprisedb.com
---(end of broadcast)---
TIP 2: Don't 'kill -9' the postmaster
rzelewu,id_zamowienia from zamowienia join przelew using
(id_przelewu, matching_name_col1, ...) where id_klienta=4999;
and could therefore provide a different answer.
--
Simon Riggs
EnterpriseDB http://www.enterprisedb.com
---(end of broadcast)-
tats
where attname = 'st_id';
select count(distinct st_id) from seed;
and also the table definition, including the PK
--
Simon Riggs
EnterpriseDB http://www.enterprisedb.com
---(end of broadcast)---
TIP 1: if posting/
lationname set name = (
>select name
>from temp.a
>where temp.a.id = correlationname.a.id
> )
(which is definitely not allowed by SQL:2003)
Having said all of that, its clearly a grey area so no need to change
this as part of beta, since we could easily cause more wierdness
rtitioning, as you know, but it does seem as if everybody else *is*.
--
Simon Riggs
EnterpriseDB http://www.enterprisedb.com
---(end of broadcast)---
TIP 3: Have you checked our extensive FAQ?
http://www.postgresql.org/docs/faq
On Tue, 2006-10-03 at 13:56 -0400, Tom Lane wrote:
> Simon Riggs <[EMAIL PROTECTED]> writes:
> > On Tue, 2006-10-03 at 11:04 -0400, Tom Lane wrote:
> >> This is the long-ago-agreed-to behavior, see
> >> http://www.postgresql.org/docs/8.1/static/rules-status.html
&g
ndex column doesn't match what we are getting
* from the expression. Perhaps this can be fixed
* someday, but for now, punt.
*/
It's in the analyze.c code, but not in the docs.
Be interested in a full report of your research, once you're done.
--
S
al specifically says it doesn't do,
therefore you'll need the analyze_function. That capability was put
there deliberately to help you out, in this situation.
> I don't think I need to write my own analyze function
That is the solution, not a workaround.
--
Simon Ri
On Mon, 2006-11-06 at 15:54 -0700, Rusty Conover wrote:
> I still think this is a deficiency in the analyze function to not use
> the operator_class that the index uses when producing statistics for
> that index.
Agreed, but that isn't the way it works right now, AFAICS. TODO..
)
> addressing the last block it intends to use whenever it allocates a new
> batch of blocks, whereupon md.c could adopt a saner API: allow
> smgrextend but not other calls to address blocks beyond the current EOF.
> Thoughts?
Yes, do it.
--
Simon Riggs
EnterpriseDB http
d be good to
brain dump some starting places for an investigation.
Does anybody have a perf test that shows hash indexes beating btrees by
any significant margin? (Not saying there isn't one...)
I can see the argument that fixed hash indexes would be faster, but
there are obviously major down
On Fri, 2006-11-17 at 08:26 -0600, Kenneth Marshall wrote:
> I certainly hold out some hope that they can improved. I would like to see
> them still included. Once they are gone, it will be much harder to ever
> add them back.
OK, you got it - keep hash indexes then.
--
Si
The following bug has been logged online:
Bug reference: 3250
Logged by: Simon K
Email address: [EMAIL PROTECTED]
PostgreSQL version: 8.2
Operating system: Windows XP
Description:Different ResultSets btw JDBC Driver and pgAdmin3
Details:
when i execute this query
/filesystem or the
settings you've chosen for fsync and wal_fsync.
If you shut it down cleanly, yet its flaky when it comes back up that
doesn't sound too much like a database problem to me...
--
Simon Riggs
EnterpriseDB http://www.enterprisedb.com
1 - 100 of 233 matches
Mail list logo
