Re: [HACKERS] [PATCHES] TODO item: Have psql show current values for a sequence
On Sat, May 24, 2008 at 12:27:16AM -0300, Dickson S. Guedes wrote: > Hi all, > > These patch implements the TODO item: Have psql show current values > for a sequence. > Comments are welcome. > > Sequence "public.foo_bar_seq" > +---+-+-+ > |Column | Type |Value| > +---+-+-+ > | sequence_name | name| foo_bar_seq | > | last_value| bigint | 11 | > | start_value | bigint | 1 | > | increment_by | bigint | 1 | > | max_value | bigint | 9223372036854775807 | > | min_value | bigint | 1 | > | cache_value | bigint | 1 | > | log_cnt | bigint | 31 | > | is_cycled | boolean | f | > | is_called | boolean | t | > +---+-+-+ Is it now the style to draw a complete box around /d* displays? Or can we dispense with the top and bottom rows of dashes? -dg -- David Gould [EMAIL PROTECTED] 510 536 1443510 282 0869 If simplicity worked, the world would be overrun with insects. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] [GENERAL] Fragments in tsearch2 headline
stucked with the function LexizeExec which I do not totally understand (... and is not well documents too :) ) Sorry for that. LexizeExec() is a play around supporting thesaurus dictionary, which is designed to replace phrase by phrase. So, if it see first matched word then it asks the parse to get next word. On next word it have four options: - asks next word - returns substituting phrase - says: Hey, I have a match, but it's possible to find a largest match, so give a next word - says about false match, so parser should return back and try next dictionary from the begining or last match. Now only thesaurus dictionary can work in that mode but nothing forbids to have another dictionary with phrase recognition. -- Teodor Sigaev E-mail: [EMAIL PROTECTED] WWW: http://www.sigaev.ru/ -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] [GENERAL] Fragments in tsearch2 headline
[moved to -hackers, because talk is about implementation details]
I've ported the patch of Sushant Sinha for fragmented headlines to pg8.3.1
(http://archives.postgresql.org/pgsql-general/2007-11/msg00508.php)
Thank you.
1 > diff -Nrub postgresql-8.3.1-orig/contrib/tsearch2/tsearch2.c
now contrib/tsearch2 is compatibility layer for old applications - they don't
know about new features. So, this part isn't needed.
2 solution to compile function (ts_headline_with_fragments) into core, but
using it only from contrib module looks very odd. So, new feature can be used
only with compatibility layer for old release :)
3 headline_with_fragments() is hardcoded to use default parser, but what will be
in case when configuration uses another parser? For example, for japanese
language.
4 I would prefer the signature ts_headline( [regconfig,] text, tsquery [,text] )
and function should accept 'NumFragments=>N' for default parser. Another parsers
may use another options.
5 it just doesn't work correctly, because new code doesn't care of parser
specific type of lexemes.
contrib_regression=# select headline_with_fragments('english', 'wow asd-wow
wow', 'asd', '');
headline_with_fragments
--
...wow asd-wowasd-wow wow
(1 row)
So, I incline to use existing framework/infrastructure although it may be a
subject to change.
Some description:
1 ts_headline defines a correct parser to use
2 it calls hlparsetext to split text into structure suitable for both goals:
find the best fragment(s) and concatenate that fragment(s) back to the text
representation
3 it calls parser specific method prsheadline which works with preparsed text
(parse was done in hlparsetext). Method should mark a needed
words/parts/lexemes etc.
4 ts_headline glues fragments into text and returns that.
We need a parser's headline method because only parser knows all about its
lexemes.
--
Teodor Sigaev E-mail: [EMAIL PROTECTED]
WWW: http://www.sigaev.ru/
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Execution-time-sensitive timestamp regression tests
"Tom Lane" <[EMAIL PROTECTED]> writes: > What I'm considering doing is putting a BEGIN/COMMIT around the whole > sequence, which will guarantee that now() does *not* advance, thus > eliminating the midnight gotcha. This would mean that the expected > output of the comparison to 'now' changes from 0 rows to 1 row. > > Objections, better ideas? Alternatively we could do a pg_sleep(.1) to sleep for 100ms. It sounds like the ideal would be something like: insert 'now' pg_sleep(.1) begin insert 'now' select * from table -- expect 1 (not 0 or 2) ... the other tests you mention which get bitten by midnight end -- Gregory Stark EnterpriseDB http://www.enterprisedb.com Ask me about EnterpriseDB's PostGIS support! -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] TODO item: Have psql show current values for a sequence
Hi all, These patch implements the TODO item: Have psql show current values for a sequence. Comments are welcome. * Credits The original patch were developed by Euler Taveira de Oliveira <[EMAIL PROTECTED]> but how he is a little busy, he sends it to me and I made some changes to satisfy the TODO item above. * Discussions http://archives.postgresql.org/pgsql-hackers/2007-12/msg00102.php http://archives.postgresql.org/pgsql-hackers/2007-12/msg00605.php * Outputs # \d foo_bar_seq Sequence "public.foo_bar_seq" +---+-+-+ |Column | Type |Value| +---+-+-+ | sequence_name | name| foo_bar_seq | | last_value| bigint | 11 | | start_value | bigint | 1 | | increment_by | bigint | 1 | | max_value | bigint | 9223372036854775807 | | min_value | bigint | 1 | | cache_value | bigint | 1 | | log_cnt | bigint | 31 | | is_cycled | boolean | f | | is_called | boolean | t | +---+-+-+ # \d+ foo_bar_seq Sequence "public.foo_bar_seq" +---+-+-+-+ |Column | Type |Value| Description | +---+-+-+-+ | sequence_name | name| foo_bar_seq | | | last_value| bigint | 11 | | | start_value | bigint | 1 | | | increment_by | bigint | 1 | | | max_value | bigint | 9223372036854775807 | | | min_value | bigint | 1 | | | cache_value | bigint | 1 | | | log_cnt | bigint | 31 | | | is_cycled | boolean | f | | | is_called | boolean | t | | +---+-+-+-+ -- []s Dickson S. Guedes -- Projeto Colmeia - Curitiba - PR +55 (41) 3254-7130 ramal: 27 http://makeall.wordpress.com/ http://pgcon.postgresql.org.br/ http://planeta.postgresql.org.br/ psql-show-current-values-for-sequence-v2.diff.gz Description: GNU Zip compressed data -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] \df displaying volatility
Alvaro Herrera wrote: Would anyone object to \df displaying a function's volatility? Maybe limit it to \df+? Ideally we would have a short header for the column so that it doesn't take too much space, and specify the setting with a single letter. The meaning of each letter we could display at the bottom of the table as a footer (something we were going to do for \z too I think?) Thoughts? I think it would be about time :) +1 Joshua D. Drake -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] \df displaying volatility
Would anyone object to \df displaying a function's volatility? Maybe limit it to \df+? Ideally we would have a short header for the column so that it doesn't take too much space, and specify the setting with a single letter. The meaning of each letter we could display at the bottom of the table as a footer (something we were going to do for \z too I think?) Thoughts? -- Alvaro Herrerahttp://www.CommandPrompt.com/ PostgreSQL Replication, Consulting, Custom Development, 24x7 support -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] keyword list/ecpg
Hi, I recently (on my flight to Ottawa) changed ecpg to use the keyword list of the backend instead of its own. This means that there is one less file to sync manually. However, it also means that an additional keyword defined in the backend will break compilation as ecpg doesn't have this definition in its parser. Does anyone object to moving the symbol definition part to a file of its own that's inluded by both parser? Or does anyone have a better idea? Michael -- Michael Meskes Email: Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org) ICQ: 179140304, AIM/Yahoo: michaelmeskes, Jabber: [EMAIL PROTECTED] Go VfL Borussia! Go SF 49ers! Use Debian GNU/Linux! Use PostgreSQL! -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Execution-time-sensitive timestamp regression tests
Tom Lane wrote: Magnus Hagander <[EMAIL PROTECTED]> writes: And I agree that it's strange we haven't seen it before. Could it be a side-effect from something that happened lately, or should we consider it purely random? Well, it's possible we have seen it before and ignored it because it wasn't reproducible. It was only the coincidence of two buildfarm members showing the failure at the same time that drew my attention. I think Andrew has the ability to grep the buildfarm history to see if we've seen this before. Another possibility is that we did something that improved performance to get us below the threshold where this could happen; though I don't recall anything very likely. rega I can't find any other similar failures recently in the buildfarm history. One data point: the _bat buildfarm members are running on Windows under VMWare, so their clocks might not be very true. cheers andrew -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] [ADMIN] Error while executing pg_dump "invalid memory alloc request size 4294967293"
Hi , I have tried to taken backup while no one is connected. Should i change my > RAM and then check it. Version are same of pg_dump and database version 8.1. Yes try that . Though I dont think thats going to help. Just checking are you using AMD server any chance . Please provide complete config of your installation. Hardware : what machine is it the process , RAM etc Software : OS , PostgreSQL version > Should I copy the data folder ? and then restore it with new installation > or what do you mean to say kindly brief it please. I will be thankful to any > help. thanks a lot. Yes , shutdown PostgreSQL, copy the data folder and reinstall the server and after initialisation restart the server. Before you attempt that make sure you backup atleast the database folder. Also during backup , post the log file to the community so they can look at it. > On Fri, May 23, 2008 at 8:53 AM, Vishal Mailinglist <[EMAIL PROTECTED]> > wrote: > >> Hi , >> >> Make sure no one is connected to the database while doing the back up. >> Usually memory alloc error comes if its a bad RAM . >> check the pg_dump version and your database version match (this could be a >> guess) >> try file level backup and restore into new database. >> >> >> On 22/05/2008, Amit jain <[EMAIL PROTECTED]> wrote: >>> >>> Hello All, >>> >>> We are using postgresql version 8.1 and our database size is 7gb. Ram >>> Size is 2 GB. >>> >>> while trying to take backup through pg_dump i am getting following error. >>> >>> oka97: pg_dump amtdb > amtdb.out >>> pg_dump: ERROR: invalid memory alloc request size 4294967293 >>> pg_dump: SQL command to dump the contents of table "atbs2_logs" failed: >>> PQendcopy() failed. >>> pg_dump: Error message from server: ERROR: invalid memory alloc request >>> size 4294967293 >>> pg_dump: The command was: COPY public.atbs2_logs (sno, request_time, >>> msisdn, phone_make, error_code, error_desc, reply_message, request_query, >>> responce_time, request_type) TO stdout; >>> >>> When I tried to take a single table backup i.e is mentioned in the error >>> named* "public.atbs2_logs" then again getting following error. >>> * >>> >>> pg_dump: SQL command failed >>> pg_dump: Error message from server: server closed the connection >>> unexpectedly >>> This probably means the server terminated abnormally >>> before or while processing the request. >>> pg_dump: The command was: FETCH 100 FROM _pg_dump_cursor >>> >>> >>> So we are unable to take backup , we have tried the vacuum and reindex >>> but not of any use. >>> >>> Kindly help us Any help would be highly appreciate. Thanx in Advance. >>> >>> >>> Amit Jain >>> >>> +91-9818450022 >>> >>> >>> >>> >>> >>> >>> >> >> >> >> -- >> Regards, >> Vishal Kashyap. >> Need help visit >> http://help.vishal.net.in > > > -- Regards, Vishal Kashyap. Need help visit http://help.vishal.net.in
Re: [HACKERS] Execution-time-sensitive timestamp regression tests
Magnus Hagander <[EMAIL PROTECTED]> writes: > And I agree that it's strange we haven't seen it before. Could it be a > side-effect from something that happened lately, or should we consider > it purely random? Well, it's possible we have seen it before and ignored it because it wasn't reproducible. It was only the coincidence of two buildfarm members showing the failure at the same time that drew my attention. I think Andrew has the ability to grep the buildfarm history to see if we've seen this before. Another possibility is that we did something that improved performance to get us below the threshold where this could happen; though I don't recall anything very likely. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Random order of archiving files
"Gurjeet Singh" <[EMAIL PROTECTED]> writes: >Can this random order in archival of files be explained? Maybe something wiped out the contents of the archive status subdirectory? If the .ready files all went away, the backends would eventually recreate them, but possibly in a surprising order. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] [PATCHES] WITH RECURSIVE patch V0.1
On Sat, May 24, 2008 at 05:01:11AM +0900, Yoshiyuki Asaba wrote: > Hi, > > From: David Fetter <[EMAIL PROTECTED]> > Subject: Re: [PATCHES] WITH RECURSIVE patch V0.1 > Date: Fri, 23 May 2008 11:26:30 -0700 > > > Where is the new patch? > > I will create the revised patch on June. This is a patch for this > problem. Thanks very much :) Cheers, David. -- David Fetter <[EMAIL PROTECTED]> http://fetter.org/ Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter Skype: davidfetter XMPP: [EMAIL PROTECTED] Remember to vote! Consider donating to Postgres: http://www.postgresql.org/about/donate -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Execution-time-sensitive timestamp regression tests
Tom Lane wrote: > Both of the observed failures are on Windows machines, where I'm told > that the resolution of gettimeofday() is an abysmal 55msec, so it > seems that the only surprise here is that we haven't seen the failure > often before. Actually, reading up some more it seems the 55msec was for win98 systems. Modern systems usually have around 10ms. And I agree that it's strange we haven't seen it before. Could it be a side-effect from something that happened lately, or should we consider it purely random? > It might be worth trying to improve the resolution of now() on > Windows, though I didn't much care for the ideas Magnus had about how > to do that when I asked him earlier today. For the record, what we were talking about was snapshotting the time at backend start and then use QueryPerformanceCounter() to see what happened and do some calculation. The other option appears to be to use a multimedia timer, timeGetSystemTime(). But the comment for that one still says "The default precision of the timeGetTime function can be five milliseconds or more, depending on the machine. You can use the timeBeginPeriod and timeEndPeriod functions to increase the precision of timeGetTime. If you do so, the minimum difference between successive values returned by timeGetTime can be as large as the minimum period value set using timeBeginPeriod and timeEndPeriod. Use the QueryPerformanceCounter and QueryPerformanceFrequency functions to measure short time intervals at a high resolution, " So the bottom line is - if you want to have high performance timing, you really should use QueryPerformance...(). //Magnus -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] [PATCHES] WITH RECURSIVE patch V0.1
Hi, From: David Fetter <[EMAIL PROTECTED]> Subject: Re: [PATCHES] WITH RECURSIVE patch V0.1 Date: Fri, 23 May 2008 11:26:30 -0700 > Where is the new patch? I will create the revised patch on June. This is a patch for this problem. *** ../../pgsql/src/backend/executor/nodeRecursivescan.c2008-05-24 04:45:23.0 +0900 --- src/backend/executor/nodeRecursivescan.c2008-05-24 04:47:54.0 +0900 *** *** 37,43 node->ss.ps.state->es_tuplestorestate = tuplestore_begin_heap(true, false, work_mem); } ! slot = node->ss.ps.ps_ResultTupleSlot; if (tuplestore_gettupleslot(node->ss.ps.state->es_tuplestorestate, true, slot)) return slot; --- 37,43 node->ss.ps.state->es_tuplestorestate = tuplestore_begin_heap(true, false, work_mem); } ! slot = node->ss.ss_ScanTupleSlot; if (tuplestore_gettupleslot(node->ss.ps.state->es_tuplestorestate, true, slot)) return slot; Regards, -- Yoshiyuki Asaba [EMAIL PROTECTED] -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] Execution-time-sensitive timestamp regression tests
I've been puzzled by a couple of recent buildfarm failures:
http://www.pgbuildfarm.org/cgi-bin/show_log.pl?nm=dawn_bat&dt=2008-05-22%2006:00:01
http://www.pgbuildfarm.org/cgi-bin/show_log.pl?nm=vaquita&dt=2008-05-19%2020:00:03
Both fail the timestamp test like this:
*** ./expected/timestamp.outMon May 19 21:01:31 2008
--- ./results/timestamp.out Mon May 19 21:34:23 2008
***
*** 36,42
SELECT count(*) AS None FROM TIMESTAMP_TBL WHERE d1 = timestamp without time
zone 'now';
none
--
! 0
(1 row)
DELETE FROM TIMESTAMP_TBL;
--- 36,42
SELECT count(*) AS None FROM TIMESTAMP_TBL WHERE d1 = timestamp without time
zone 'now';
none
--
! 1
(1 row)
DELETE FROM TIMESTAMP_TBL;
which seemed a bit baffling until I looked into the test source:
CREATE TABLE TIMESTAMP_TBL ( d1 timestamp(2) without time zone);
INSERT INTO TIMESTAMP_TBL VALUES ('now');
-- six more inserts and three selects
SELECT count(*) AS None FROM TIMESTAMP_TBL WHERE d1 = timestamp without time
zone 'now';
none
--
0
(1 row)
IOW, this test is assuming that the value of now() must change in the
time it takes to execute a few SQL statements. The buildfarm reports
indicate that it didn't change.
Both of the observed failures are on Windows machines, where I'm told
that the resolution of gettimeofday() is an abysmal 55msec, so it seems
that the only surprise here is that we haven't seen the failure often
before.
It might be worth trying to improve the resolution of now() on Windows,
though I didn't much care for the ideas Magnus had about how to do that
when I asked him earlier today.
In any case I think this regression test is broken-by-design (and so is
the very similar code in the timestamptz test). Aside from the risk
we see here, there are previously-recognized race conditions in the
statements I omitted: if local midnight passes during the sequence of
statements, you get a failure.
What I'm considering doing is putting a BEGIN/COMMIT around the whole
sequence, which will guarantee that now() does *not* advance, thus
eliminating the midnight gotcha. This would mean that the expected
output of the comparison to 'now' changes from 0 rows to 1 row.
Objections, better ideas?
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] [PATCHES] WITH RECURSIVE patch V0.1
On Sat, May 24, 2008 at 03:21:01AM +0900, Yoshiyuki Asaba wrote: > Hi, > > From: David Fetter <[EMAIL PROTECTED]> > Subject: Re: [PATCHES] WITH RECURSIVE patch V0.1 > Date: Sun, 18 May 2008 11:47:37 -0700 > > > I tried a bunch of different queries, and so far, only these two > > haven't worked. Any ideas what I'm doing wrong here? > > > > WITH RECURSIVE t(n) AS ( > > SELECT 1 > > UNION ALL > > SELECT n+1 > > FROM t > > WHERE n < 100 > > ) > > SELECT * FROM t; > > ERROR: cannot extract attribute from empty tuple slot > > Thank you for the report. I've fixed. > > postgres=# WITH RECURSIVE t(n) AS ( > SELECT 1 > UNION ALL > SELECT n+1 > FROM t > WHERE n < 100 > ) > SELECT count(*) FROM t; > count > --- >100 > (1 row) > > Regards, > -- > Yoshiyuki Asaba > [EMAIL PROTECTED] Great! Where is the new patch? Cheers, David. -- David Fetter <[EMAIL PROTECTED]> http://fetter.org/ Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter Skype: davidfetter XMPP: [EMAIL PROTECTED] Remember to vote! Consider donating to Postgres: http://www.postgresql.org/about/donate -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] [PATCHES] WITH RECURSIVE patch V0.1
Hi, From: David Fetter <[EMAIL PROTECTED]> Subject: Re: [PATCHES] WITH RECURSIVE patch V0.1 Date: Sun, 18 May 2008 11:47:37 -0700 > I tried a bunch of different queries, and so far, only these two > haven't worked. Any ideas what I'm doing wrong here? > > WITH RECURSIVE t(n) AS ( > SELECT 1 > UNION ALL > SELECT n+1 > FROM t > WHERE n < 100 > ) > SELECT * FROM t; > ERROR: cannot extract attribute from empty tuple slot Thank you for the report. I've fixed. postgres=# WITH RECURSIVE t(n) AS ( SELECT 1 UNION ALL SELECT n+1 FROM t WHERE n < 100 ) SELECT count(*) FROM t; count --- 100 (1 row) Regards, -- Yoshiyuki Asaba [EMAIL PROTECTED] -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] Random order of archiving files
Hi All, Can this random order in archival of files be explained? grep archived /var/log/localmessages 2008-05-23 08:43:43 PDTLOG: archived transaction log file "000109BD009D" 2008-05-23 08:44:41 PDTLOG: archived transaction log file "000109BD00A0" <- 9D and 9F archived much later 2008-05-23 08:45:01 PDTLOG: archived transaction log file "000109BD00A1" 2008-05-23 08:46:00 PDTLOG: archived transaction log file "000109BD00A4" 2008-05-23 08:46:26 PDTLOG: archived transaction log file "000109BD006C" 2008-05-23 08:46:29 PDTLOG: archived transaction log file "000109BD0069" 2008-05-23 08:46:32 PDTLOG: archived transaction log file "000109BD006D" 2008-05-23 08:46:33 PDTLOG: archived transaction log file "000109BD0071" 2008-05-23 08:46:34 PDTLOG: archived transaction log file "000109BD0073" 2008-05-23 08:46:35 PDTLOG: archived transaction log file "000109BD0074" 2008-05-23 08:46:38 PDTLOG: archived transaction log file "000109BD0075" 2008-05-23 08:46:41 PDTLOG: archived transaction log file "000109BD0076" 2008-05-23 08:46:42 PDTLOG: archived transaction log file "000109BD0077" 2008-05-23 08:46:43 PDTLOG: archived transaction log file "000109BD007A" 2008-05-23 08:46:49 PDTLOG: archived transaction log file "000109BD007B" 2008-05-23 08:46:52 PDTLOG: archived transaction log file "000109BD007D" 2008-05-23 08:46:53 PDTLOG: archived transaction log file "000109BD007F" 2008-05-23 08:46:54 PDTLOG: archived transaction log file "000109BD00A7" <--- chain broken here again... 2008-05-23 08:47:59 PDTLOG: archived transaction log file "000109BD00AA" 2008-05-23 08:48:21 PDTLOG: archived transaction log file "000109BD00AB" 2008-05-23 08:49:33 PDTLOG: archived transaction log file "000109BD00AD" 2008-05-23 08:50:30 PDTLOG: archived transaction log file "000109BD00AE" 2008-05-23 08:52:30 PDTLOG: archived transaction log file "000109BD00AF" 2008-05-23 08:54:30 PDTLOG: archived transaction log file "000109BD00B0" 2008-05-23 08:55:42 PDTLOG: archived transaction log file "000109BD00B1" 2008-05-23 08:57:39 PDTLOG: archived transaction log file "000109BD00B2" 2008-05-23 08:59:27 PDTLOG: archived transaction log file "000109BD00B3" 2008-05-23 09:01:26 PDTLOG: archived transaction log file "000109BD0085" 2008-05-23 09:01:27 PDTLOG: archived transaction log file "000109BD0080" 2008-05-23 09:01:28 PDTLOG: archived transaction log file "000109BD0081" 2008-05-23 09:01:29 PDTLOG: archived transaction log file "000109BD0086" 2008-05-23 09:01:30 PDTLOG: archived transaction log file "000109BD0088" 2008-05-23 09:01:34 PDTLOG: archived transaction log file "000109BD0089" 2008-05-23 09:01:37 PDTLOG: archived transaction log file "000109BD008C" 2008-05-23 09:01:38 PDTLOG: archived transaction log file "000109BD008F" 2008-05-23 09:01:39 PDTLOG: archived transaction log file "000109BD0090" 2008-05-23 09:01:42 PDTLOG: archived transaction log file "000109BD0091" 2008-05-23 09:01:46 PDTLOG: archived transaction log file "000109BD0093" 2008-05-23 09:01:47 PDTLOG: archived transaction log file "000109BD0094" 2008-05-23 09:01:48 PDTLOG: archived transaction log file "000109BD0095" 2008-05-23 09:01:52 PDTLOG: archived transaction log file "000109BD0097" 2008-05-23 09:01:54 PDTLOG: archived transaction log file "000109BD0099" 2008-05-23 09:01:55 PDTLOG: archived transaction log file "000109BD009A" 2008-05-23 09:01:56 PDTLOG: archived transaction log file "000109BD009B" 2008-05-23 09:01:57 PDTLOG: archived transaction log file "000109BD009C" 2008-05-23 09:01:58 PDTLOG: archived transaction log file "000109BD009E" 2008-05-23 09:01:59 PDTLOG: archived transaction log file "000109BD009F" 2008-05-23 09:02:01 PDTLOG: archived transaction log file "000109BD00A2" 2008-05-23 09:02:04 PDTLOG: archived transaction log file "000109BD00A3" 2008-05-23 09:02:06 PDTLOG: archived transaction log file "000109BD00A5" 2008-05-23 09:02:06 PDTLOG: archived transaction log file "000109BD00B4" <--- continuing from where it left earlier!!! 2008-05-23 09:02:58 PDTLOG: archived transaction log file "000109BD00B5" 2008-05-23 09:04:32 PDTLOG: archived transaction log file "000109BD00B6" 2008-05-23 09:06:28 PDTLOG: archived transaction log file "000109BD00B7" 2008-05-23 09:08:21 PDTLOG: archived transaction log file "000109BD00B8" I always assumed that the XLogs are g
Re: [HACKERS] [JDBC] How embarrassing: optimization of a one-shot query doesn't work
Dave Cramer <[EMAIL PROTECTED]> writes: > Any word on 8.3.2 ? Obviously, nothing is happening during PGCon ;-) There was some discussion a week or so back about scheduling a set of releases in early June, but it's not formally decided. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Error while executing pg_dump "invalid memory alloc request size 4294967293"
Amit jain wrote: Hello All, We are using postgresql version 8.1 and our database size is 7gb. Ram Size is 2 GB. while trying to take backup through pg_dump i am getting following error. oka97: pg_dump amtdb > amtdb.out pg_dump: ERROR: invalid memory alloc request size 4294967293 pg_dump: SQL command to dump the contents of table "atbs2_logs" failed: PQendcopy() failed. pg_dump: Error message from server: ERROR: invalid memory alloc request size 4294967293 pg_dump: The command was: COPY public.atbs2_logs (sno, request_time, msisdn, phone_make, error_code, error_desc, reply_message, request_query, responce_time, request_type) TO stdout; When I tried to take a single table backup i.e is mentioned in the error named* "public.atbs2_logs" then again getting following error. * pg_dump: SQL command failed pg_dump: Error message from server: server closed the connection unexpectedly This probably means the server terminated abnormally before or while processing the request. pg_dump: The command was: FETCH 100 FROM _pg_dump_cursor So we are unable to take backup , we have tried the vacuum and reindex but not of any use. It seems to me that you have corrupted data in that table for some reason, perhaps bad hardware? I bet that a simple "SELECT * FROM atbs2_logs" will fail as well. Which server version is this exactly? 8.1.what? How far did the pg_dump get before the crash? Is there any output at all? -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] [JDBC] How embarrassing: optimization of a one-shot query doesn't work
Tom, I believe this is pretty much a show stopper for anyone using jdbc to upgrade to 8.3.x. Any word on 8.3.2 ? Dave On 31-Mar-08, at 7:26 PM, Tom Lane wrote: While testing the changes I was making to Pavel's EXECUTE USING patch to ensure that parameter values were being provided to the planner, it became painfully obvious that the planner wasn't actually *doing* anything with them. For example execute 'select count(*) from foo where x like $1' into c using $1; wouldn't generate an indexscan when $1 was of the form 'prefix%'. Some investigation showed that the planner is using the passed values for estimation purposes, but not for any purposes where the value *must* be correct (not only this LIKE-optimization, but constraint exclusion, for instance). The reason is that the parameter values are made available to estimate_expression_value but not to eval_const_expressions. This is a thinko in a cleanup patch I made early in 8.3 development: http://archives.postgresql.org/pgsql-committers/2007-02/msg00352.php I said to myself "eval_const_expressions doesn't need any context, because a constant expression's value must be independent of context, so I can avoid changing its API". Silly me. The implication of this is that 8.3 is significantly worse than 8.2 in optimizing unnamed statements in the extended-Query protocol; a feature that JDBC, at least, relies on. The fix is simple: add PlannerInfo to eval_const_expressions's parameter list, as was done for estimate_expression_value. I am slightly hesitant to do this in a stable branch, since it would break any third-party code that might be calling that function. I doubt there is currently any production-grade code doing so, but if anyone out there is actively using those planner hooks we put into 8.3, it's conceivable this would affect them. Still, the performance regression here is bad enough that I think there is little choice. Comments/objections? regards, tom lane -- Sent via pgsql-jdbc mailing list ([EMAIL PROTECTED]) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-jdbc -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
