ows can be accessed with one page
access (to the heap) why should it use an index?
--
Kevin Grittner
EDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
t i am getting only
> size 9213 MB.
>
> Dont know, what exactly happend?
Well, you could narrow the possibilities by restoring that dump to
an 8.4 database and see how big that is. Some major releases have
improved the storage formats for some data types, like numeric; but
you might just b
ing:
REINDEX DATABASE '"PremierIEX"'
--
Kevin Grittner
EDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
"pc...@contigo.com" wrote:
> Anyway to tell what went wrong from the memory dump?
I would start by looking for the biggest "total" allocation.
--
Kevin Grittner
EDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-bugs mailing list (pg
The following bug has been logged on the website:
Bug reference: 8398
Logged by: Kevin Martin
Email address: martin.ke...@gmail.com
PostgreSQL version: 9.3rc1
Operating system: Ubuntu 10.04
Description:
to_json() returns an invalid JSON value when called on an empty
ger column, it but can be coerced to
work with a properly normalized relational database with a little
effort. In my experience it's worth the effort.
--
Kevin Grittner
EDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-bugs mailing list (pgsql-bug
Tom Lane wrote:
> Kevin Grittner writes:
>> It occurs to me that the behavior you are seeing would be
>> consistent with 945 being considered an uppercase letter, with
>> 60536 being considered its lowercase form. Normal PostgreSQL
>> case-folding of identifiers w
Kevin Grittner wrote:
> Whether it is a bug in Windows or in PostgreSQL character-
> handling under Windows I can say myself, since I haven't
> had any reason to use Windows for years.
Er, that should have been I *can't* say.
>> create or replace function α(β int, ξ in
ame) = 1;
ascii | proname
---+-
945 | α
(1 row)
test=# select ascii('α');
ascii
---
945
(1 row)
test=# select proname from pg_proc where proname = 'α';
proname
-
α
(1 row)
--
Kevin Grittner
EDB: http://www.enterprisedb.com
The Enterprise PostgreSQL
his is supposed to make things faster, but all the bugs might not
be out of it yet.
--
Kevin Grittner
EDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
9:16:38 WARNING: could not create listen socket for "127.0.0.1"
> 2013-07-24 19:16:38 FATAL: could not create any TCP/IP sockets
Is another postmaster running on port 5432?
You could run any or all of these statements to get insight into that:
lsof -i4TCP@127.0.0.1:5432
netstat -plnt |
"g.bakalar...@icm.edu.pl" wrote:
> Kevin Grittner wrote:
>> "g.bakalar...@icm.edu.pl" wrote:
>>
>>> When doing these kind of statements
>>
>>> execute : CREATE TEMPORARY TABLE [...]
>>
>>> After few days [...] my huge s
into action - it usually kills one of
> postgres processes - postmaster restart all databases) and after
> all linux has again some 100GB of not commited memory
What do you have as settings for temp_buffers and max_connections?
--
Kevin Grittner
EDB: http://www.enterprisedb.com
Th
3.2) and (3.2 / 2), respectively.
--
Kevin Grittner
EDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
ow.
> You should use a newer version.
Most definitely.
--
Kevin Grittner
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
art of a decimal fraction when you can't
draw a line over those digits?)
In the absence of such a type, you might want to arrange your
calculations such that any division or square root calculations
are done last. That way the effect of the truncation of the
repeating (or not) infinite decimal
> )
> WITH (OIDS=FALSE)
> ;
> CREATE INDEX IX_FullText_2 ON "User_Full_Text_Search_2"
> USING gin("tsv");
> I don't understand why a materialized column is more slow than a
> calculeted one...
Try materia
upgraded with pg_dump (or some
other logical population of the data, versus a pg_upgrade run) you
are probably getting bitten by the initial setting of hint bits.
http://wiki.postgresql.org/wiki/Hint_Bits
See if it is still slow after that
--
Kevin Grittner
EnterpriseDB: http://www.enterpr
David Johnston wrote:
> varchar(100)
> The other option to index words via the full-text search capabilities.
Or for columns this short, a similarity search on a trigram index.
http://www.postgresql.org/docs/current/interactive/pgtrgm.html
--
Kevin Grittner
EnterpriseDB
name SET STORAGE MAIN;
http://www.postgresql.org/docs/9.0/interactive/sql-altertable.html
http://www.postgresql.org/docs/9.0/interactive/storage-toast.html
--
Kevin Grittner
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-bugs mailing list (pgsql-bug
pdate table_A set situation='Waiting' where id='23';
UPDATE 1
test=# select * from table_a;
id | situation
+---
23 | Waiting
(1 row)
test=# select * from table_b;
id | sitation | when
+--+----
23
iple directory entries to point
to the same data location. Until you delete the last directory
entry the file remains.
--
Kevin Grittner
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your
idn't happen
...
The file is delete_old_cluster.sh on most platforms. The suffix is
.bat on Windows.
It can be run anytime after the upgrade *as long as you have not
moved the new cluster to the old location*.
Thanks to Bruce Momjian for telling me in chat when I asked just now.
--
Ke
consultation was very
> slow, taking almost the time of the query without LIMIT and
> OFFSET.
You should probably use a cursor instead of LIMIT and OFFSET.
--
Kevin Grittner
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-bugs mailing list (p
modify
or truncate any of the hard-linked files, as they are quite likely
to still be just another name for the same file that is in use for
production under the newer version. You want to simply remove the
older directory entry pointing to the file.
http://www.linfo.org/hard_link.html
--
Kevi
uding all files
which start with a filename you derived from pg_class and has a dot
or underscore followed by more characters?
--
Kevin Grittner
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make chan
g depends more on the number
of database objects than their size.)
http://www.postgresql.org/docs/9.1/interactive/pgupgrade.html
--
Kevin Grittner
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To
ed a hash
aggregation, and that was faster? And that you feel that it should
be using that even with the bloat? That the dead rows seem to be
getting included in the statistics, driving to the slower plan, and
you feel they should be omitted?
Note that I'm not aruing one way or another on
cuum settings and overall
vacuum regimen to prevent future bloat.
This does not look like a bug from the information provided so far.
-Kevin
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
L statement with details of how that statement is supported
in each PL would get really messy really quickly.
-Kevin
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
Bruce Momjian wrote:
> On Thu, Jan 24, 2013 at 08:43:37PM -0300, Alvaro Herrera wrote:
>> Bruce Momjian escribió:
>>> On Tue, Sep 4, 2012 at 02:01:54PM -0400, Bruce Momjian wrote:
>>>> On Tue, Sep 4, 2012 at 12:49:40PM -0500, Kevin Grittner wrote:
>>>>&g
configuring the TCP keepalive parameters.
http://www.postgresql.org/docs/9.2/interactive/runtime-config-connection.html#RUNTIME-CONFIG-CONNECTION-SETTINGS
-Kevin
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
tsunez...@efficlabo.com wrote:
> Rotation of the log is not carried out.
>
> "log_rotation_size" is not effective.
We need more details.
http://wiki.postgresql.org/wiki/Guide_to_reporting_problems
-Kevin
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
Andres Freund wrote:
> On 2013-01-12 14:29:38 -0500, Tom Lane wrote:
>> "Kevin Grittner" writes:
>>> To try to get your function code to work as you expect, the
>>> language would essentially need to identify which statements could
>>> be pre-planne
be pre-planned, and which would needed to be treated as raw source
on each execution. That would be tricky to implement, and would
itself have some run-time cost. At this point we've put the burden
on the programmer to identify this at the time the code is written,
rather than adding run-time exp
me if you're willing to fix it for 9.2.3
> for instance?
Back-patching means changing things in a minor release, where
things only change after the second dot. We don't make changes in
user-visible behavior like this in minor releases; so no, we would
not make a change like this in 9
isting directory C:/Program
> Files/PostgreSQL/9.2/data2 ... initdb: could not change permissions of
> directory "C:/Program Files
> /PostgreSQL/9.2/data2": Permission denied
This looks like a simple permissions problem, not a bug.
-Kevin
--
Sent via pgsql-bugs mailing list (pgsql-bug
d, char_length(a_name), a_name
from artikel
where a_id in (323, 324);
-Kevin
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
Sumit kumar sharma wrote:
> I have downloaded 9.2 version but I am unable to install postgres
> sql in windows 8 please fix it as soon as possible.
Please provide details.
http://wiki.postgresql.org/wiki/Guide_to_reporting_problems
-Kevin
--
Sent via pgsql-bugs mailing list (pgsq
ke sure
you are taking frequent backups and keeping several generations of
them.
Future postings on the topic should be on the pgsql-general list;
this list is for bug reports.
-Kevin
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
p.ela...@gmail.com wrote:
> Description:
>
> subj
This is not a bug report. You might try posting on the
pgsql-general list. If you want any useful response, you need to
provide a little more detail.
-Kevin
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make c
his point, you need to run the script file in through psql. If it
contains steps you don't want to execute, you will need to copy and
edit the file to leave just the portions you want to run.
-Kevin
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subs
're writing a history book, you want something more current.
> on Linux 6
What is the output of?: uname -a
-Kevin
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
oning/
You should be looking at 9.1 or 9.2 at this point.
-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 following bug has been logged on the website:
Bug reference: 7659
Logged by: Kevin Smith
Email address: ke...@rootsmith.ca
PostgreSQL version: 9.2.1
Operating system: CentOS5
Description:
I have the following in my pg_hba.conf file:
host all +ldap 127.0.0.1/32
ue above is that any single command sees an absolutely
> consistent view of the database."
Based on my clarification here, do you agree that the current
language is more accurate than your proposed revision?
-Kevin
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
wn to 0.1 for fully
cached workloads, along with the cpu_tuple_cost boost.
I think we should raise the default for cpu_tuple_cost, but have been
reluctant to suggest it based on just my personal experiences. Has
anyone else found this useful?
-Kevin
--
Sent via pgsql-bugs mailing lis
ress options the system
> crashes. Where is the font stored, and how to change?
You might have better luck getting an answer on the pgadmin-support
list.
-Kevin
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
ople use NOT EXISTS unless they really want the
rather astonishing behavior of NOT IN.
-Kevin
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
that many people only look at ones where the
subject line indicates an issue with which they are familiar, and
will skip messages without any clue about the issue.
-Kevin
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
[Adding the OP back to CC, in case he's not subscribed to the list]
Mark Kirkwood wrote:
> On 09/09/12 14:01, Kevin Grittner wrote:
>> "Pieter Viljoen Sr." wrote:
>>
>>> The TWO most important factors in hindering us to convert to
>>> Postgres
is a good fit for
your use-case, a post to pgsql-nov...@postgresql.org would be more
appropriate.
-Kevin
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
lem than the RAM will cost.
-Kevin
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
tle more to work with, please describe you hardware
and show the results of running the query on this page:
http://wiki.postgresql.org/wiki/Server_Configuration
-Kevin
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
Bruce Momjian wrote:
> On Tue, Sep 4, 2012 at 12:11:53PM -0500, Kevin Grittner wrote:
>> What do you think would be the right thing to do with it at this
>> point?
>
> Well, there should probably be a tar files with a README. What
> about adding this to /contrib?
I
Bruce Momjian wrote:
> On Mon, Apr 9, 2012 at 02:07:43PM -0500, Kevin Grittner wrote:
>> Bruce Momjian wrote:
>>> On Mon, Apr 09, 2012 at 03:37:09PM -0300, Alvaro Herrera wrote:
>>>
>>>> (Another related tool is clearxlogtail which zeroes areas from
>
ry
key).
You would be well served to fix your query and move on. There's no
way we're going to make it behave the way you are requesting. The
current behavior conforms to the SQL standard, performs better than
it could if it worked the way you suggest, and allows you to get the
results you want by fully specifying the ORDER BY clause.
-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:
> Denis Kolesnik wrote:
>> and even sorting by id:
>> select id, str_last_name from tbl_owners_individual where id in
>> (83,175,111,1) order by str_last_name;
>>
>> id |str_last_name
>> -+---
4
test=# select id, str_last_name from tbl_owners_individual where id
in
test-# (83,175,111,1) order by str_last_name;
id | str_last_name
-+---
83 | GX
175 | GX
1 | Kolesnik
111 | Kolesnik
(4 rows)
-Kevin
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
nt of rows with false.
That sure sounds like a situation where you should use a partial
index.
http://www.postgresql.org/docs/current/interactive/indexes-partial.html
-Kevin
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www
"Kevin Grittner" wrote:
<> p...@elbrief.de> wrote:
>
>> insert into bla ( a , b )
>> select a , a
>> from generate_series( 1 , 100 ) as a ( a ) ;
>
>> explain analyze select * from bla
>> where b > 99 order by a limit 1
cs on multiple
columns, so that correlations like that don't confuse the optimizer,
or trying to evaluate the "risk" of a query taking a long time based
on unexpected correlations.
Not really a bug; more like a recognized opportunity to improve the
optimizer.
-Kevin
--
Sent via pgsql-bu
show us what you're doing.
> but not success in fetch the data by query,
What did you try? What did you expect to happen? What did happen?
> Please tell me procedure of this.
http://wiki.postgresql.org/wiki/Guide_to_reporting_problems
-Kevin
--
Sent via pgsql-bugs mailing l
index used.
If you think the optimizer is not choosing the fastest plan, please
read this page:
http://wiki.postgresql.org/wiki/SlowQueryQuestions
-Kevin
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
n is a direct consequence of programmers using
procedural code where they could have used declarative code, so I
would tend to stress clean and complete set operations over
concessions to procedural coding.
I'll stop waving my hands around now.
-Kevin
--
Sent via pgsql-bugs mailing li
Tom Lane wrote:
> "Kevin Grittner" writes:
>> So currently a NOT NULL constraint on a column with a composite
>> type is equivalent to:
>> CHECK (NOT c IS NULL)
>
> I don't believe this statement is accurate. What's really
> happening is
ay would
need to be stated as something like "The column can only contain
non-null values."
-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 to be excluded.
Moving the NOT in front of the IS results in a test for rows from
"bad" where it is NOT true that row value "c" IS [ENTIRELY] NULL.
That works for me, anyway. Some find the rules around NULL
illogical and argue for just memorizing them as a set of facts
rath
someone to
program it for you, but it would be best to discuss it on (some
other) list first, to see if there is general support for having a
second syntax for this.
-Kevin
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
[moving to -jdbc list with bcc to -bugs]
wrote:
> PostgreSQL version: 9.1.4
> java version "1.7.0_04"
> Java(TM) SE Runtime Environment (build 1.7.0_04-b20)
> Java HotSpot(TM) Client VM (build 23.0-b21, mixed mode)
What PostgreSQL driver jar?
-Kevin
--
Sent
ted to
that deficiency. As long as NULL is not abused for such things as
"known to be zero" in an accounting record (which is subtly but
significantly different from "not applicable"), NULL is almost
always (IMO) better than some "magic value". If you have ever
conve
syntax for
specifying that as non-obvious, but it seems pretty reasonable to
me.
-Kevin
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
ing NULL has. On the other hand,
aggregates like counts might be very useful -- it is often useful to
know not only how many rows have each of the known values, but how
many are missing a value.
Have you looked at whether an exclusion constraint would serve your
needs here?
-Kevin
--
Sent v
greSQL executable files
from one location to another?
-Kevin
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
aware, running pg_ctl with the restart option is
generally not adequate to prevent problems with an update, in place
or not. The postmaster must be stopped and then started. Some
service scripts may do that, others don't. So the safe thing,
unless you know exactly how your service script
ognize everything in the newer server,
-Kevin
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
rminating connection
> due to administrator command
What do you see in the PostgreSQL server log at the time of this
disconnect?
-Kevin
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
-such-file-or-directory-893924/
-Kevin
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
eses as specified in the
documentation:
http://www.postgresql.org/docs/9.1/interactive/sql-select.html#SQL-LIMIT
| to write anything except a simple integer constant for start or
| count, you must write parentheses around it.
-Kevin
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.
yone to help much. Please read this page and start a new
thread on pgsql-general with your request for assistance in figuring
out the problem:
http://wiki.postgresql.org/wiki/Guide_to_reporting_problems
-Kevin
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To mak
and, an
index entry based on now() is clearly a problem.
Otherwise I agree with your response -- this is clearly *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
* wrote:
> Kevin Grittner ***:
>> what you have written will scan the entire table and give each
>> row a 1 in 10 chance of being selected.
>>
> Hmm, is this because random() marked as volatile (and would be
> called for every row)? Ups, I
join testt t on (t.id = n.r);
By the way, you might want to tweak that random number before
casting it to int, or you might not get *any* rows back:
test=# select ('0.01'::float * 10)::int;
int4
--
0
(1 row)
Maybe something like:
(select floor(random() * 10
see a different misbehavior:
>
> regression=# set timezone to 'Europe/Moscow'; select '2011-03-27
> 23:00:00'::timestamptz;
> SET
> timestamptz
>
> 2011-03-28 00:29:40+04
> (1 row)
Ubuntu 10.04 LTS
Linux kevin-desktop 2.6.32-40-gene
wrote:
> PostgreSQL version: 9.0.0
http://www.postgresql.org/support/versioning/
There are fixes in newer bug-fix releases which would likely take
care of this. If you still see it under 9.0.7, please let us know.
-Kevin
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.
bably put packaging that up as a proper
extension and posting it to PGXN as another thing on the list of
things I'll do when I stumble over that pot of round tuits at the
end of the rainbow. Right now the source is on pgfoundry. If
anybody wants to do anything with it before I find time, fe
> ahead and remove that mention.
>
> Agreed; removed with the attached patch. I didn't bother keeping
> the gzip mention because I assume there is little value to using
> without pglesslog.
We found that gzip without doing something about the unused portion
of the WAL f
eneral, but I can imagine it possibly being useful for
monitoring purposes.)
-Kevin
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
[Please keep the list copied. I won't respond to any more emails
directly to me without a copy to the list.]
Tatiana Ortiz wrote:
> Kevin Grittner >> Test if you have network connectivity from your client to the
>>> server host using ping or equivalent tools.
>>
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
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
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 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
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
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
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
"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
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
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
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
1 - 100 of 593 matches
Mail list logo
