Hi,We are testing upgrade from PostgreSQL version 7.3.9 to 7.4.9 on Gentoo linux. In some Java programs we get the error " SET AUTOCOMMIT TO OFF is no longer supported".I read about some changes in release notes "http://www.postgresql.org/docs/8.1/static/release-7-4.html". What is the best way to s
On Mon, 2006-05-15 at 16:58 -0700, Jeff Frost wrote:
> The log is below. Note that the problem began around 2a.m. around the time
> the complaint about checkpoint segments happens. After a bit of research it
> appears that the checkpoint complaint happens when our db maintenance job
> kicks o
Hi
Is there any query for possibility of getting only one
row at a time in a group of records?
With distinct rows & Columns my query has to return only
one record at a time with out any condition.Will it be possible?
Thank you,
Sandhya
SELECT ….. LIMIT 1
Will get the first row in the dataset.
Then to fetch the next row, you can do SELECT …… LIMIT 1 OFFSET 1
(will get the 2nd record) and so on.
(replace ….. with your conditions,
LIMIT must come at the end of the query)
Andy
From:
[EMAIL PROTECTED] [
Thank you.
- Original Message -
From:
Andy Shellam
To: 'sandhya'
Cc: pgsql-admin@postgresql.org
Sent: Tuesday, May 16, 2006 6:26 PM
Subject: RE: [ADMIN] reg:Query
SELECT
.. LIMIT
1
Will get the first
row in the dataset. Then to fetch the next
Actually, just realized, this depends on
your PGSQL version.
The older format (pre-8.0 I believe) is
SELECT ….. LIMIT x, y (where x is the number of rows to fetch, and
y is the offset (ie. Select x number of rows, starting from row y.)
Andy
From:
[EMAIL PROTECTED] [
yes..I got it.
SELECT LIMIT x OFFSET y.Am i
right?
- Original Message -
From:
Andy Shellam
To: 'sandhya'
Cc: pgsql-admin@postgresql.org
Sent: Tuesday, May 16, 2006 6:35 PM
Subject: FW: [ADMIN] reg:Query
Actually, just
realized, this de
Depends on which version of Postgres youre using (pre-8.0 or post-8.0)
I think the format changed from v8.0 onwards. So, for example, post-8.0:
SELECT email_address FROM account_details ORDER BY address_id LIMIT 1
OFFSET 0;
Will bring back the first row. The following will bring back t
Thusitha Kodikara <[EMAIL PROTECTED]> writes:
> We are testing upgrade from PostgreSQL version 7.3.9 to 7.4.9 on Gentoo
> linux. In some Java programs we get the error " SET AUTOCOMMIT TO OFF is no
> longer supported".
> I read about some changes in release notes
> "http://www.postgresql.org/do
Andy Shellam wrote:
Depends on which version of Postgres you’re using (pre-8.0 or post-8.0)
I think the format changed from v8.0 onwards. So, for example, post-8.0:
SELECT email_address FROM account_details ORDER BY address_id LIMIT 1
OFFSET 0;
Will bring back the first row. The follo
Kgd,
I think it changed in 8.0 onwards.
I used an application that was written for 7.4 on my 8.0.3 server, and it
threw up errors at the LIMIT statements, saying the "LIMIT X,Y" format was
deprecated, and to use "LIMIT X OFFSET Y" instead - so I had to have much of
the application queries rewritt
[Please keep mail on-list; I don't need multiple copies. Thanks.]
Andy Shellam wrote:
I think it changed in 8.0 onwards.
I used an application that was written for 7.4 on my 8.0.3 server, and it
threw up errors at the LIMIT statements, saying the "LIMIT X,Y" format was
deprecated, and to use
> Your earlier messages in the thread seemed to imply that LIMIT X,Y was
> the ONLY format that would work pre-8.0.
I had 2 applications that used the LIMIT X,Y format, and having started out
with Postgres on 8.0.0 (only touching base with 7.4), plus coming from a
mySQL background (which did use L
PostgreSQL 8.1.3Question on autovacuum.autovacuum_naptime (integer) Specifies the delay between activity rounds for the autovacuum subprocess. In each round the subprocess examines one database and issues VACUUM and ANALYZE commands as needed for tables in that database. The delay is measured in se
Title: RE: [ADMIN] Autovacuum Question
>Does this mean that each run of autovacuum will vacuum/analyze all tables
>that need work in the database that autovacuum is looking at?
Yes, it will do all tables that satisfy the criteria.
>Also, with over 200 databases, does this mean that a databa
I just happened to be reading this page from
the 8.1 docs:
"The autovacuum daemon, when enabled, runs
every autovacuum_naptime seconds and
determines which database to process. Any database which is close to transaction
ID wraparound is immediately processed. In this case, autovacuum issue
Thanks to those who answered my first question. I am looking at implementing autovacuuming on our new production 8.1.3 systems. I am reading the documentation on the various configuration parameters. The autovacuum_analyze_threshold and autovacuum_vacuum_threshold talk about the number of update
U can install pgstattuple module which is available in the contrib directory and run it on production as
psql> \x
psql> select * from pgstattuple('public'.'tablename');
it displays the table_len, tuple_count, tuple_len, tuple_percent, dead_tuple_count, dead_tuple_len,dead_tuple_percent,free_s
Hi,
"My" developers asked me to hide from them the databases and
meta-information in the schemas they don't use and want, and
also to hide from other developers the meta-information in
theyr schemas.
They use PGAdmin III and PG Lightning Admin.
Is this possible ? Can someone, please, let me kno
On Tue, 16 May 2006, Simon Riggs wrote:
I don't see much evidence for a connection between archiver and these
issues. The problems start after autovacuum of "vb_web" at 02:08. That
seems much more likely to have something to do with client connections
than the archiver - which is really nothing
On Tue, May 16, 2006 at 10:30:26AM -0700, Mark Liberman wrote:
> >Does this mean that each run of autovacuum will vacuum/analyze all tables
> >that need work in the database that autovacuum is looking at?
>
> Yes, it will do all tables that satisfy the criteria.
>
> >Also, with over 200 databases
On Tue, May 16, 2006 at 06:50:41PM +0100, Dias Costa wrote:
> Hi,
>
> "My" developers asked me to hide from them the databases and
> meta-information in the schemas they don't use and want, and
> also to hide from other developers the meta-information in
> theyr schemas.
>
> They use PGAdmin III
On Tue, May 16, 2006 at 02:00:21PM -0400, Chris Hoover wrote:
> Thanks to those who answered my first question. I am looking at
> implementing autovacuuming on our new production 8.1.3 systems. I am
> reading the documentation on the various configuration parameters. The
> autovacuum_analyze_thr
Jeff Frost <[EMAIL PROTECTED]> writes:
> On Tue, 16 May 2006, Simon Riggs wrote:
>> Whatever happened between 02:08 and 02:14 seems important.
> I have the logs and after reviewing /var/log/messages for that time period,
> there is no other activity besides postgres.
I have a lurking feeling tha
On Wed, 17 May 2006, Tom Lane wrote:
I have a lurking feeling that the still-hypothetical connection between
archiver and foreground operations might come into operation at pg_clog
page boundaries (which require emitting XLOG events) --- that is, every
32K transactions something special happens
25 matches
Mail list logo
