On Feb 9, 2008 8:04 PM, Adam Rich <[EMAIL PROTECTED]> wrote:
> > It seems to do the job, but how good is it in the long run? Any way I
> > could tweak it?
>
>
> I think this form will work the best:
>
>
> SELECT u.login, MAX(s.stop_time) AS last_use_time
> FROM users u, stats s
> WHERE u.id=s.user_
"Markus Bertheau" <[EMAIL PROTECTED]> writes:
> Does removing all locking as in the attached patch have any negative
> impact other than the non-consistency of the results?
Removing the LockBufHdr bit is definitely a pretty foolish idea.
regards, tom lane
On Feb 9, 2008 10:42 AM, Willem Buitendyk <[EMAIL PROTECTED]> wrote:
> I'm trying to restore my database from 8.26 into 8.3 (win32) but find
> the process to be exceedingly slow. The database has about 60M records.
> I realize there will be differences based on hardware, available memory,
> compl
Hi,
I want to use the pg_buffercache contrib module for monitoring our
server. It takes a lock on all buffers and then on each buffer header
in order to get a consistent picture of the buffers. I would be
running the function provided by the module once every 5 minutes.
I'm worrying about the per
-bash: pg_config: command not found
It's not installed in the base/server/libs RPMs. I had to search the
uninstalled PostgreSQL RPMs for it, and then (temporarily) install the
"devel" RPM to run it. For CentOS 4.4 & RHEL4, the system-wide psqlrc
is in /etc/sysconfig/pgsql/
-- Dean
On 2008
"Dean Gibson (DB Administrator)" <[EMAIL PROTECTED]> writes:
> I've tried various places, and none seem to work. I've even done a
> "strings `which psql` | grep psqlrc" to no avail.
"pg_config --sysconfdir" would tell you. I agree the documentation
on this is less than clear.
> It seems to do the job, but how good is it in the long run? Any way I
> could tweak it?
I think this form will work the best:
SELECT u.login, MAX(s.stop_time) AS last_use_time
FROM users u, stats s
WHERE u.id=s.user_id
AND u.status='3' AND u.next_plan_id IS NULL
GROUP BY u.login
HAVING MAX(s.
I've tried various places, and none seem to work. I've even done a
"strings `which psql` | grep psqlrc" to no avail.
---(end of broadcast)---
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your
Benjamin Arai <[EMAIL PROTECTED]> writes:
> We are thinking of modifying our system to use COPY to replace these
> large INSERT transactions but we are concerned that it will greatly
> impact the user experience (i.e., exclusively lock the table during the
> copy process). First, does COPY grab
On Feb 9, 2008 6:30 PM, Benjamin Arai <[EMAIL PROTECTED]> wrote:
> Hello,
>
> We are running a system which requires continual uptime while loading
> data. Currently one particular table receives a large number of inserts
> per commit (about 1 inserts). This process works well allowing both
>
On Feb 3, 2008 11:14 PM, Alex Turner <[EMAIL PROTECTED]> wrote:
> I"m not a database expert, but wouldn't
>
> create table attribute (
> attribute_id int
> attribute text
> )
>
> create table value (
> value_id int
> value text
> )
>
> create table attribute_value (
>entity_id int
> a
Ken Johanson <[EMAIL PROTECTED]> writes:
> A first question: will the current server design easily allow some
> change that lets us set behaviors (like standard_conforming_strings) on
> a per-connection basis?
See the SET command. Or maybe you should read the overview here:
http://www.postgresql.
Hello,
We are running a system which requires continual uptime while loading
data. Currently one particular table receives a large number of inserts
per commit (about 1 inserts). This process works well allowing both
end users to access the data as well as loading reasonably quickly.
W
Lewis Cunningham <[EMAIL PROTECTED]> writes:
> If a person is interested in all the groups, is it hard to subscribe?
> No.
> If all groups are in one, is it hard to filter out? Yes.
Some people like to filter PG mail into different folders for different
lists, so that they can read with more foc
On Feb 4, 2008, at 11:31 AM, Joshua D. Drake wrote:
I don't agree in the least, I was actually going to suggest we add a
new one for relational design questions. I like many lists that are
contextually specific. IMO, general should be removed for example.
I think this makes sense for a web-b
In article <[EMAIL PROTECTED]>,
Alex Turner <[EMAIL PROTECTED]> wrote:
%
% I"m not a database expert, but wouldn't
%
% create table attribute (
% attribute_id int
% attribute text
% )
%
% create table value (
% value_id int
% value text
% )
%
% create table attribute_value (
% entity_
Hi all,
The situation: there are users in one table, and their access statistics
in the other. Now I want to find users whose last access time was more
than one month ago. As I've only had to write quite simple queries
involving no sub-selects so far, I'd like to ask your opinion if this
one
(re-post, last seemed not to get on-list)
Hi all,
In the link below we asked if it was possible to set, in this case, the
standard_conforming_strings behavior, on a per-connection basis.
http://www.grokbase.com/topic/2006/07/27/backslash-as-ordinary-char-vs-not-set-via-a-connection-session-vari
Benjamin Arai <[EMAIL PROTECTED]> writes:
> I was reading the docuementation for 8.3
> (http://www.postgresql.org/docs/8.3/static/wal-async-commit.html) and it
> states "An immediate-mode shutdown is equivalent to a server crash, and
> will therefore cause loss of any unflushed asynchronous comm
Hello,
I was reading the docuementation for 8.3
(http://www.postgresql.org/docs/8.3/static/wal-async-commit.html) and it
states "An immediate-mode shutdown is equivalent to a server crash, and
will therefore cause loss of any unflushed asynchronous commits.". Does
this mean that doing a "shut
I'm trying to restore my database from 8.26 into 8.3 (win32) but find
the process to be exceedingly slow. The database has about 60M records.
I realize there will be differences based on hardware, available memory,
complexity of records but when I first tried a restore with the verbose
option
On Sat, 09 Feb 2008 10:20:51 -0700
Ken Johanson <[EMAIL PROTECTED]> wrote:
> I acknowledge that from time to time we must accept changes in the
> 3rd party software that will break our apps if we (or customers) ever
> upgrade them (a compounded issue if we have heavily-used deployments
> in the f
Ken Johanson <[EMAIL PROTECTED]> writes:
> Is there anything now, or in the works, for compatibility emulation?
Sure: keep using the same major release. This is one of the reasons
that we keep updating back release branches for so long.
regards, tom lane
Ken Johanson wrote:
Magnus Hagander wrote:
PG uses a different versioning system than this one?:
http://en.wikipedia.org/wiki/Software_versioning#Numeric
Or do you mean the changes are not minor? :-)
Yes, we use the one stated on our site, not wikipedia ;)
See: http://www.postgresql.org/sup
On Sat, Feb 09, 2008 at 10:54:38AM -0700, Ken Johanson wrote:
> Magnus Hagander wrote:
>
>>> PG uses a different versioning system than this one?:
>>> http://en.wikipedia.org/wiki/Software_versioning#Numeric
>>>
>>> Or do you mean the changes are not minor? :-)
>> Yes, we use the one stated on our
Magnus Hagander wrote:
PG uses a different versioning system than this one?:
http://en.wikipedia.org/wiki/Software_versioning#Numeric
Or do you mean the changes are not minor? :-)
Yes, we use the one stated on our site, not wikipedia ;)
See: http://www.postgresql.org/support/versioning
T
Ken Johanson wrote:
Stephen Frost wrote:
* Ken Johanson ([EMAIL PROTECTED]) wrote:
But given the recent and dramatic example of 8.3's on-by-default
stricter typing in functions (now not-autocasting), I worry that kind
of change could happen in every minor version (8.4 etc).
8.3 isn't a minor
Stephen Frost wrote:
* Ken Johanson ([EMAIL PROTECTED]) wrote:
But given the recent and dramatic example of 8.3's on-by-default stricter
typing in functions (now not-autocasting), I worry that kind of change
could happen in every minor version (8.4 etc).
8.3 isn't a minor version.
PG uses
Ken,
* Ken Johanson ([EMAIL PROTECTED]) wrote:
> But given the recent and dramatic example of 8.3's on-by-default stricter
> typing in functions (now not-autocasting), I worry that kind of change
> could happen in every minor version (8.4 etc).
8.3 isn't a minor version.
Enjoy,
I acknowledge that from time to time we must accept changes in the 3rd
party software that will break our apps if we (or customers) ever
upgrade them (a compounded issue if we have heavily-used deployments in
the field and not just in-house ones to maintain).
But given the recent and dramatic
Steve/Jeff,
Thanks for your replies. I am using the latest "pg" module but I don't
know if there is any way to handle this without SQL. I am manually
taking care of it using SQL functions to convert empty strings to
NULL. It would be nice if there is a setting that could take care of
this issue.
Simon Riggs wrote:
On Sat, 2008-02-09 at 07:49 -0500, Chander Ganesan wrote:
Signalling components could be added to pg_standby at some point...
What sort of thing are you looking for?
pg_standby accepts a trigger file as well as various types of signal
I didn't see anything about si
On Sat, 2008-02-09 at 07:49 -0500, Chander Ganesan wrote:
> Signalling components could be added to pg_standby at some point...
What sort of thing are you looking for?
pg_standby accepts a trigger file as well as various types of signal.
--
Simon Riggs
2ndQuadrant http://www.2ndQuadrant.c
Hi Roberto,
-a "WAL segment file" is the same that a "log file segment"?
A WAL (Write Ahead Log) file is one of the numbered files in the pg_xlog
directory. Keep in mind that you'll be archiving (in some cases) more
than just WAL files, for example you might see other files appear in
you
On Feb 9, 2008 5:50 AM, Greg Smith <[EMAIL PROTECTED]> wrote:
> On Fri, 8 Feb 2008, David Wall wrote:
>
> > Does pg_standby take care of this by checking file sizes or the like? In my
> > testing with scp, we never experienced any problems, but I wonder if we were
> > somehow "just lucky."
>
> pg_
On Fri, 8 Feb 2008 21:48:39 -0300
Alvaro Herrera <[EMAIL PROTECTED]> wrote:
> Hmm, did this go anywhere? I still look for the shiny new Pg polos on
> the mail every day, only to be disappointed.
>
Yes, they will be part of the larger run of shirts we do after SCALE.
Joshua D. Drake
--
The Po
36 matches
Mail list logo