Tom Lane wrote:
> "Kevin Grittner" writes:
>> If I'm reading this correctly, it would appear that nobody has
>> updated anything to a TOASTed value in a build against HEAD in
>> testing *anything* in the last two and a half months. And the
>> regressio
//wiki.postgresql.org/wiki/SlowQueryQuestions
You will probably get the most useful responses if you can first
identify one or more of your slow queries and post the specifics of
those, per the above web page.
-Kevin
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make chan
tinues to succeed
with this patch applied.
-Kevin
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
workaround is to explicitly cast quoted
literals and nulls in the result list of a set operation like UNION.
-Kevin
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
fficiently. Seeing what vmstat or iostat say during
a slow episode, and seeing whether the episodes correspond to
checkpoints, will give you a better indication of where the problem
lies.
-Kevin
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
.indexrelid
and a.attrelid = t.oid
and a.attnum = ANY(ix.indkey)
and t.relkind = 'r'
and t.oid = (select oid from pg_class where relname = 't')
ORDER BY
t.relname,
i.relname
;
-Kevin
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgres
ons to the database while those funnel down to a small
number on the database side. 300 active users might do quite well
on a connection pool which maintains 10 or 20 connections to the
database. It sounds like you haven't used the correct settings to
achieve that.
-Kevin
--
Sent via
ence configuring a good
connection pooler.
http://www.postgresql.org/support/professional_support
-Kevin
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
a way that a query can be reliably analyzed to determine
that the sort can be omitted which takes less than the 0.039 ms
required for the sort step, please suggest it. But not on the bugs
list.
-Kevin
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes t
st to look at this page and consider where it
would best fit:
http://www.postgresql.org/community/lists/
-Kevin
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
ns. If the above doesn't fit with what you're seeing,
please read this and post again:
http://wiki.postgresql.org/wiki/Guide_to_reporting_problems
-Kevin
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
polished a format as you would prefer, without breaking anything for
anyone else.
-Kevin
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
nown
(1 row)
In your second example (where the number matches), the unknown value
is cast to real when you compare to the real column, so the same
approximation is generated.
In general it is a bad idea to compare for equality using
approximate values. Perhaps you would be better off with that
column defined as numeric?
-Kevin
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
h USING, and thus easier to understand and
less prone to bugs than the ON form. I think it's a mistake to
discourage USING or under-support it compared to the more verbose
constructs.
-Kevin
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
nsaction because of errors, or essentially
deprecating the USING clause in general.
-Kevin
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
y of the replica failures were
from passing corrupted data from the master to the replicas, versus
having a common hardware/vm flaw.
-Kevin
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
y not a bug in the software. The
documentation does cover it here:
http://www.postgresql.org/docs/9.0/interactive/functions-comparison.html
Is there something you would add to that?
-Kevin
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
* ** wrote:
> 17.06.2011, 00:28, "Kevin Grittner" :
>> * **; wrote:
>>
>>> [4-1] 2011-06-16 17:40:27 UTC LOG: startup process (PID 15292)
>>> was terminated by signal 7: Bus error
>>> Signal 7 means hardware problems
king at?
> And indeed the parser does not generate warnings either.
It would be totally wrong for the parser to generate warnings about
correct behavior.
-Kevin
P.S. A copy/paste of part of the above-mentioned page:
To check whether a value is or is not null, use the constructs:
priate.
Before sending any such request, though, please look at the fine
manual and see if you can find the answer:
http://www.postgresql.org/docs/9.0/interactive/index.html
Before posting with another request for assistance, please read
this:
http://wiki.postgresql.org/wiki/Guide_to_rep
de 1.
You don't show any error message which mentions "path" in any way.
Why do you use that word to describe your problem?
One thing I do notice is that you didn't specify a database name on
the command line. What is your PGDATABASE environment variable
value? Maybe you j
The following bug has been logged online:
Bug reference: 6123
Logged by: Kevin Grittner
Email address: kevin.gritt...@wicourts.gov
PostgreSQL version: HEAD and 9.0.4
Operating system: Linux (probably doesn't matter)
Description:DELETE fails if before trigger c
Tom Lane wrote:
> "Kevin Grittner" writes:
>> [ circular trigger relationships ]
>
>> I expect the DELETE from a to delete related b record(s) and then
>> succeed. Instead the UPDATE in b_del_trig causes delete of a to
>> silently fail.
>
> The
Tom Lane wrote:
> "Kevin Grittner" writes:
>> Tom Lane wrote:
>>> The update causes the already-selected target row version of the
>>> DELETE to be obsoleted, so heap_delete finds it has nothing to
>>> do. I'm disinclined to mess with that
gainst the database. If you have a lot of rows in the restore
which you don't expect to be deleted or updated for a long time, you
might want to make that a VACUUM FREEZE ANALYZE.
In the future, please post questions like this to the pgsql-general
list.
-Kevin
--
Sent via pgsql-bugs
whether that is something you can control when you launch the
process in Java. Or do you have some reason to believe that this
would be under control of the pg_restore executable?
-Kevin
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
rm of
Windows, version 8.4 should support X32. I think you need version
9.0 (or the upcoming 9.1 release) to support Windows X64.
-Kevin
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
This is not a bug. It would be more appropriate for the
pgsql-general or pgsql-novice list. In all probability either the
server is not running on your local machine. If it is, it's
configured for a different port. If you need help learning how to
check these things, please ask on anoth
't cross-post like that.
http://wiki.postgresql.org/wiki/Guide_to_reporting_problems
-Kevin
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
4 and development HEAD. I
don't still have any machines handy which are running 8.4, but you
might want to try it on the latest bug-fix version of 8.4 (currently
8.4.8) to see if the fix was back-patched.
http://www.postgresql.org/support/versioning
-Kevin
--
Sent via pgsql-bugs mailin
sub2.key3;
key1 | key3 | value2
--+--+
1 |1 |
(1 row)
This is on HEAD from today. Clearly there's a problem.
-Kevin
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
re automatically?
We have multiple PostgreSQL clusters running on some of our
machines. How would your suggestions work in that environment?
Are any of the environment variable helpful?:
http://www.postgresql.org/docs/9.0/interactive/libpq-envars.html
-Kevin
--
Sent via pgsql-bugs ma
at('long string', 100));
INSERT 0 1
test=# select char_length(val) from txt;
char_length
-
1100
(1 row)
What makes you think it's limited to 4680 characters?
-Kevin
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscrip
into txt values (repeat('x', 4500));
INSERT 0 1
test=# insert into txt values (repeat('x', 4685));
INSERT 0 1
test=# select char_length(val), val is null, (val ~ 'x') from txt;
char_length | ?column? | ?column?
-+--+--
4500 | f
x(val);
val
-
1
(1 row)
Not only are you missing required parentheses and the SELECT keyword,
you're returning a record rather than a scalar value.
-Kevin
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
t cannot be an arbitrary
expression containing operators (like ::).
-Kevin
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
ommand.
It doesn't say that operators which provide equivalent functionality
to functions can also be used.
-Kevin
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
Alexey Klyukin wrote:
> On Aug 29, 2011, at 5:02 PM, Kevin Grittner wrote:
>
>> Alexey Klyukin wrote:
>>
>>> Function calls can appear in the FROM clause. (This is
>>> especially useful for functions that return result sets, but any
>>> function
"Kevin Grittner" wrote:
> test=# select val from (select 'a' = 'a') as val;
> val
> -
> (t)
> (1 row)
Also note the difference between a record and a scalar here. I
forgot to write it to return val as a scalar, which seems to be what
you&#x
RIALIZABLE level in PostgreSQL version 9.0;
this has been enhanced to fully compliant behavior in the upcoming
9.1 release.
For 9.0 behavior, see:
http://www.postgresql.org/docs/9.0/static/transaction-iso.html
For behavior in the soon-to-be-release 9.1 version, see:
http://www.postgresql.org/doc
"Albert Ward" wrote:
> would like to translate it to Bulgarian language, so I can share
> it with the readers on my blog.
This is not a bug, so it doesn't belong on this list. I will reply
to the duplicate post on docs shortly.
-Kevin
--
Sent via pgsql-bugs mai
values, you should use a type
which supports that, like numeric.
-Kevin
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
Christopher Gernon wrote:
> to_char() should be able to convert 5.6e-32 to text just as easily
> as it can convert 5.6e-3. For some reason, it doesn't.
Oh, I see your point now, and I agree with you.
We should probably at least put this on the TODO list, I think. Any
objection
Tom Lane wrote:
> "Kevin Grittner" writes:
>> Christopher Gernon wrote:
>>> to_char() should be able to convert 5.6e-32 to text just as
>>> easily as it can convert 5.6e-3. For some reason, it doesn't.
>
>> Oh, I see your point now, and I agr
r that
> to happen in the non- cases too, but whether that's actually
> what happens in other systems is something I don't know.
>From a quick web search, it looks like '#' filling is the typical
approach for infinity and NaN.
-Kevin
--
Sent via pgsql-bugs maili
to the
system tables. These probably all belong on the pgsql-general list.
The exception would be that if you are thinking about implementing
the requested features and contributing them to community
PostgreSQL, you could discuss that on the -hackers list.
-Kevin
--
Sent via pgsql-bugs mai
still have
questions:
http://wiki.postgresql.org/wiki/Guide_to_reporting_problems
http://wiki.postgresql.org/wiki/PostgreSQL_Release_Support_Policy
FWIW, Red Hat has been a very active supporter of PostgreSQL for
years.
-Kevin
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To m
t with
> psql.
Perhaps pgAdmin detects the mismatch and sets the client-side
character set to the more limited LATIN1? What does pgAdmin do if
you make such a connection and then try to store a character which
is not in the LATIN1 character set, like a euro character?
-Kevin
--
Sent via p
p the database which
is automatically created on installation.
-Kevin
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
o this?
Using what techniques? DELETE FROM ? TRUNCATE TABLE
? DROP TABLE on partitions? Something else?
-Kevin
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
having a usable
database if the OS goes down abruptly.
-Kevin
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
sact-SQL would return a
result set. Any stored procedure can produce an arbitrarily
intermixed stream of result sets, information lines, and error
messages.
-Kevin
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
go, or a bug still present in PostgreSQL.
Thanks,
-Kevin
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
the feature.
http://wiki.postgresql.org/wiki/Serializable
The Cahill doctoral thesis is very much worth reading, and many of
the papers referenced by it are also excellent.
http://hdl.handle.net/2123/5353
Thanks again. I hope to get back to you within a few days.
-Kevin
--
Sent via pgsql-bugs ma
goudvis wrote:
> Robert Haas wrote:
>>
>> I would be curious to see (updated, corrected) results on older
>> versions.
>
> If I am correct, Kevin Grittner is writing a review of the code
> and the testing methods. I think it would be wise to wait for the
> out
cess them. Also, it would
help to know where you got the installer, and what version it was.
-Kevin
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
th problems
with it. We have no special knowledge of what their installer does.
I see that while I've been typing this you asked whether
re-installing would help. Again, if it's not an installer we've
seen, so we don't know. The right people to be asking are the
people you go
your
house.
You either need to call the folks who put in the black box about how
to take it out, or hire someone who has the tools and knowledge to
do it.
-Kevin
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
and post to a
more appropriate list (like pgsql-general) with more information.
If you have multiple issues, it would be best to start a separate
thread for each one, with a subject line appropriate to the topic.
"help us" doesn't give any clue what the topic is.
http://wiki.postgres
the new
version?
http://wiki.postgresql.org/wiki/Guide_to_reporting_problems
-Kevin
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
mbers you're seeing, with a description of the type of
load. If you can confirm that this is not happening at a less strict
transaction isolation level, like REPEATABLE READ, we can clear this
as "not a bug", since you don't get truly serializable transactions
without cost -- that
NSERT 0 1
test=# select * from t where v like
'!"#$\%'()*+,-/:;=?@[\\]^_`{|}~&<>%'
escape '\';
v
----
!"#$%'()*+,-/:;=?@[\]^_`{|}~&<>
(1 row)
So this is not a bug on HEAD. What do you get when you run it?
-Kevin
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
eserved
words (such as CURRENT_DATE) would be allowed here, as would
expressions of arbitrary complexity -- sub-selects, CASE predicates,
functions, etc.; it would take a bit of work to sort out when
something might be a malformed attempt at a literal versus a
misspelled column name in a subquery.
wrote:
> ODBC ANSI driver psqlODBC v09.00.0310.1 does not properly pass
> values when data is of type "INTERVAL" to Crystal Reports.
You might want to try posting this issue to the pgsql-odbc list.
-Kevin
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To
#x27;)
else ''
end),
'[^A-Z0-9\,]', '', 'g')::"SearchNameT"
$$
And there is an index on "Party":
"Party_SearchName" btree ("searchName"("Party".*))
First off, is there much chan
http://www.postgresql.org/support/professional_support/
-Kevin
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
tions are:
| SQL functions execute an arbitrary list of SQL statements,
| returning the result of the last query in the list. In the simple
| (non-set) case, the first row of the last query's result will be
| returned.
http://www.postgresql.org/docs/9.1/interactive/xfunc-sql.html
-Kevin
--
Se
I don't know what time zone you're in, or whether daylight saving
time kicks in on that date. *Is* there a 02:11:11 on that date, or
is that when time "springs forward" by an hour in the spring for your
locale?
-Kevin
--
Sent via pgsql-bugs mailing list (pgsql-bug
there are triggers which do DML which can fire other
triggers, and at this point I'm not sure whether that's safe.
Anyone?
-Kevin
On 2011-12-09 12:49 PM I wrote:
PostgreSQL version 9.0.4, 64 bit.
Linux version 2.6.16.60-0.39.3-smp (geeko@buildhost)
(gcc version 4.1.2 20070115 (SUSE Linu
Tom Lane wrote:
> "Kevin Grittner" writes:
>> No comments on this?
>
> If there was a reproducible test case in your original message,
> I didn't see it, so I assumed you intended to investigate further
> on your own. It wasn't even clear to me that t
endless loop.
I will try again in just one site with a bit more care about which
functions I flag. If that goes OK, I'll have the confidence to go
forward with the application release.
Thanks!
-Kevin
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
ropriate list, like pgsql-general, pgsql-novice, or
pgsql-admin.
The downloads on this page seem to include both 32-bit and 64-bit
versions:
http://www.enterprisedb.com/products-services-training/pgdownload#windows
Perhaps you clicked on the wrong one last time?
-Kevin
--
Sent via pgsql-bugs
s lately, all on VMs. Here is one
where a solution was found:
http://archives.postgresql.org/pgsql-bugs/2011-12/msg00024.php
This is most likely a bug in OpenVz, not PostgreSQL.
-Kevin
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http:
nable to download"
statement into question. Did you intall the server? Is it running?
This doesn't sound like a bug. Please read the this page:
http://wiki.postgresql.org/wiki/Guide_to_reporting_problems
... and post follow-up discussion on pgsql-general.
-Kevin
--
Sent v
pect to happen in general when you put some statement in the
middle of another statement where it is not supported? For example,
if you put a CREATE TABLE statement in the FROM clause of a SELECT
statement, what would you expect?
-Kevin
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresq
INSERT 0 3
intclient=# select * from t;
id | d1 | d2
++
1 | 2012-01-11 | 2012-01-11
2 | 2012-01-11 | 2012-01-11
3 | 2012-01-11 | 2012-01-11
(3 rows)
You might find this page helpful:
http://wiki.postgresql.org/wiki/Guide_to_reporting_problems
-Kevin
--
Se
ad to get a handle on
that. I don't think anyone has devised any generalized formula yet,
but if we rule out other problems, I'd be happy to review your lock
situation and make suggestions.
-Kevin
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
naveen wrote:
> backup process takes more time
How much?
> process is unsuccessful.
In what way? Is there an error message? If so, please paste it.
http://wiki.postgresql.org/wiki/Guide_to_reporting_problems
-Kevin
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.o
lists can help with that
implementation. It seems there is a bug in that version, but it
might not be present in the community version.
-Kevin
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
makes complete sense when looking at the database
from the inside out, as a PostgreSQL developer, I can see how it's
less than obvious to a user who isn't familiar with the internals.
Do you have any suggestions for an error message which would make
sense to you in this context?
-Kevin
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
t.
If you want make a report of problems with a PostgreSQL web site,
please send an email to: pgsql-...@postgresql.org
-Kevin
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
"Kevin Grittner" wrote:
> Andrew Alcheyev wrote:
>
>> Well, it does good and the backend hasn't crashed yet, but the
>> client is still experiencing query problems at some point (not
>> far, I guess, from where its backend would segfault without the
has cleared by the time you're finished with these steps?
-Kevin
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
[rearranged to avoid top-posting: http://idallen.com/topposting.html]
Vipul Patel wrote:
> On Thursday 09 February 2012 10:33 PM, Kevin Grittner wrote:
>> What locks and blocking do you see when this happens?
>>
>> http://wiki.postgresql.org/wiki/Lock_Monitoring'
wrote:
> colname = 'value' returns true but
> colname LIKE 'value' returns false.
Is the colname of type char(n) or does it contain trailing spaces?
-Kevin
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
ansaction manager using 2PC. Any time the server
crashes while a COMMIT is pending, one must check to see whether it
"took".
As long as the client application sees the connection as dead in
this situation, I think PostgreSQL is doing everything just as it
should.
-Kevin
--
Sent v
ECT * FROM tblname WHERE colname LIKE '''%';
-Kevin
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
t/cf625c7ba2647825b0e3995da3604785f14fa20e
Do you see anything wrong with either of those?
> Workaround 2: JSF phaselistener to begin and rollback transaction
> before and after render-response.
I have no idea what that means in terms of what statements are run,
or when.
-Kevin
ostgreSQL COPY command is supported. It looks
like the website for dbpool is here:
http://www.snaq.net/java/DBPool/
-Kevin
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
ou subsequently did some things
which could break the service.
-Kevin
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
Slony, Londiste,
> or Bucardo.
There is a Wiki page listing and comparing available products:
http://wiki.postgresql.org/wiki/Replication,_Clustering,_and_Connection_Pooling
-Kevin
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
ry unless you specify ORDER BY. Assuming, as you seem to
be doing, that rows from the left side of a UNION will be output
before rows from the right side is not safe. You have no way of
knowing which row in a result set like that came from which of the
UNIONed SELECTs. In this case your assump
"Kevin Grittner" wrote:
> Aren Cambre wrote:
>
>> SELECT COUNT(*)
>> FROM consistent.master
>> WHERE citation_id IS NOT NULL
>> UNION
>> SELECT COUNT(*)
>> FROM consistent.master
>> UNION
>> SELECT COUNT(*)
>> FROM c
ent and you should no
longer see this problem.
-Kevin
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
t, if you need to acquire the table-level lock without waiting.
This is not a bug.
-Kevin
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
got this:
x1 | x2 | x3
++
| 3 | 5
(1 row)
-Kevin
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
o install version 9.1.3, 9.4.5.1, and 9.3.18.1 with the
> same result.
Where did you get these PostgreSQL installation files? (Can you
paste a URL?)
-Kevin
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
rthdistance.sgml;h=f9002b235b83d8e2facd9164a66db46792f6e54a;hb=HEAD
-Kevin
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
o gain access to the database
> let me know.
Start Task Manager and look in the Processes tab. Are there any
postgres process active? From a command line, run:
netstat -p TCP -a
and see if anything is listening on port 5432.
-Kevin
--
Sent via pgsql-bugs mailing list (pgsql-bugs@post
stallation
steps there, please post again -- but not on the pgsql-bugs list.
Try pgsql-general.
-Kevin
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
401 - 500 of 593 matches
Mail list logo
