Re: [BUGS] Huge speed penalty using <>TRUE instead of =FALSE
Jan-Ivar Mellingen skrev: > One of our customers discovered that by replacing <>TRUE with =FALSE in > a query of a table containing 750.000 records reduced the query time > from about 12 seconds to about 60 milliseconds! > > The problematic query looks like this: > SELECT * FROM AlarmLogg WHERE Logg_avsluttet <> TRUE AND > Alarm_status='X' ORDER BY ID DESC > > If it is changed to this it works as expected: > SELECT * FROM AlarmLogg WHERE Logg_avsluttet = FALSE AND > Alarm_status='X' ORDER BY ID DESC > > After investigation (on a smaller dataset on my own database) I found > that the query was resulting in a sequential scan: > > "explain analyze SELECT * FROM AlarmLogg WHERE Logg_avsluttet <> TRUE > AND Alarm_status='X' ORDER BY ID DESC" > "Sort (cost=49936.96..49936.96 rows=1 width=405) (actual > time=837.793..837.793 rows=0 loops=1)" > " Sort Key: id" > " Sort Method: quicksort Memory: 17kB" > " -> Seq Scan on alarmlogg (cost=0.00..49936.95 rows=1 width=405) > (actual time=837.782..837.782 rows=0 loops=1)" > "Filter: ((logg_avsluttet <> true) AND ((alarm_status)::text = > 'X'::text))" > "Total runtime: 837.896 ms" > > The modified query gave this result: > "explain analyze SELECT * FROM AlarmLogg WHERE Logg_avsluttet = FALSE > AND Alarm_status='X' ORDER BY ID DESC" > "Sort (cost=8.36..8.37 rows=1 width=405) (actual time=0.032..0.032 > rows=0 loops=1)" > " Sort Key: id" > " Sort Method: quicksort Memory: 17kB" > " -> Index Scan using i_alarmlogg_logg_avsluttet on alarmlogg > (cost=0.00..8.35 rows=1 width=405) (actual time=0.024..0.024 rows=0 > loops=1)" > "Index Cond: (logg_avsluttet = false)" > "Filter: ((NOT logg_avsluttet) AND ((alarm_status)::text = > 'X'::text))" > "Total runtime: 0.123 ms" > > This is a dramatical difference, but I cannot understand why. In my head > "<>TRUE" should behave exactly the same as "=FALSE". This looks like a > bug to me, or am I overlooking something? > > This was verified on PostgreSQL 8.3.7, both on Windows Xp and Ubuntu 8.10. > > Some relevant details from the table definition: > CREATE TABLE alarmlogg > ( >id serial NOT NULL, >alarm_status character varying(1) DEFAULT ''::character varying, >logg_avsluttet boolean DEFAULT false, >... >CONSTRAINT alarmlogg_pkey PRIMARY KEY (id) > ) > > CREATE INDEX i_alarmlogg_alarm_status > ON alarmlogg > USING btree > (alarm_status); > > CREATE INDEX i_alarmlogg_logg_avsluttet > ON alarmlogg > USING btree > (logg_avsluttet); > > Regards, > Jan-Ivar Mellingen > Securinet AS > > > Thanks to all who answered my question and helped me discover that I forgot to consider the NULL values. After a cup of coffee and a little bit of thinking it became clear that <>TRUE is not the same as FALSE, and the NULLS are not in the index. PostgreSQL is a great database, but it does not hurt to think a little when using it... Thank You all! /Jan-Ivar -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #4972: RFE: convert timestamps to fractional seconds
On Monday 10 August 2009 03:41:06 Richard Neill wrote: > * Division of a timestamp by an interval should result in something > dimensionless. What would be the semantics of this? What's today divided by 2 hours? -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #4972: RFE: convert timestamps to fractional seconds
On Monday 10 August 2009, Richard Neill wrote:
> * So, for example, to check whether two timestamps (ts1 and ts2) are less
> than 2.5 seconds apart, (returning boolean), I'd like to be able to do at
> least one of:
>
> abs(time(ts1 - ts2)) < 2.5
> #A "time" function converts timestamp to
> #sec.us since epoch)
>
> abs(cast (ts1 - ts2) as double) < 2.5
> #cast to double, might have to implicitly divide
> #by the unit of "1 second"
>
> (ts1 - ts2) / INTERVAL '1 second' < 2.5
> #Divide 2 dimensioned quantities to get
> #a dimensionless one.
What is wrong with (ts1-ts2) between i1 and i2:
cdrs=> select version();
version
-
PostgreSQL 8.2.4 on i686-pc-linux-gnu, compiled by GCC i686-pc-linux-gnu-gcc
(GCC) 4.1.2 (Gentoo 4.1.2)
cdrs=> select ('today 01:23:45'::timestamp - 'today 01:23:42.3'::timestamp)
between '-2.5 seconds'::interval and '2.5 seconds'::interval;
?column?
--
f
(1 row)
cdrs=> select ('today 01:23:45'::timestamp - 'today 01:23:42.7'::timestamp)
between '-2.5 seconds'::interval and '2.5 seconds'::interval;
?column?
--
t
(1 row)
cdrs=> select ('today 01:23:45'::timestamp - 'today 01:23:47.3'::timestamp)
between '-2.5 seconds'::interval and '2.5 seconds'::interval;
?column?
--
t
(1 row)
cdrs=> select ('today 01:23:45'::timestamp - 'today 01:23:47.7'::timestamp)
between '-2.5 seconds'::interval and '2.5 seconds'::interval;
?column?
--
f
(1 row)
> Currently, it's necessary to do something really really long-winded, eg:
> (ts1 - ts2 >= 0 AND ts1 - ts2 < interval '2.5 seconds') OR (ts2 - ts1 >= 0
> AND ts2 - ts1 < interval '2.5 seconds')
Not really, as you pointed out abs(interval) doesn't work for me, but a simple
between is easier than this, and intervals seem to support sign properly.
F.O.S.
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
[BUGS] ERROR: XLogFlush: request AF/5703EDC8 is not satisfied --- flushed only to AF/50F15ABC
Dear All, I am using postgres 7.3 version on RHEL 4.0. My database has been restored. All tables all working fine i.e select , update but on a particular table its showing error "ERROR: XLogFlush: request AF/5703EDC8 is not satisfied --- flushed only to AF/50F15ABC " I have searched other threads, it shows the problem may be due to garbage in the LSN field of a page header. Now what is the solution to this problem. Utsav Turray Disclaimer :- This e-mail and any attachment may contain confidential, proprietary or legally privileged information. If you are not the original intended recipient and have erroneously received this message, you are prohibited from using, copying, altering or disclosing the content of this message. Please delete it immediately and notify the sender. Newgen Software Technologies Ltd (NSTL) accepts no responsibilities for loss or damage arising from the use of the information transmitted by this email including damages from virus and further acknowledges that no binding nature of the message shall be implied or assumed unless the sender does so expressly with due authority of NSTL.
Re: [BUGS] ERROR: XLogFlush: request AF/5703EDC8 is not satisfied --- flushed only to AF/50F15ABC
utsav wrote: Dear All, I am using postgres 7.3 version on RHEL 4.0. 7.3 is not a supported release any more you really need to look into getting something non-prehistoric - and what version of 7.3 exactly? My database has been restored. "restored" - how exactly? From a file system backup or from a dump generated by pg_dump? Stefan -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #4972: RFE: convert timestamps to fractional seconds
Dear Peter and Tom, Thanks for your help. Sorry for posting an incorrect bug report. I hope there are still a few useful parts... Tom Lane wrote: "Richard Neill" writes: * Convert a timestamp into a number of seconds since the epoch. This can be done in an ugly way using EXTRACT epoch FROM timestamp, but only to integer precision. Uh, nonsense. regression=# select extract(epoch from now()); date_part -- 1249884955.29859 (1 row) You're quite right - I stand corrected. I'm sorry - my experiment was clearly faulty - and when I checked the documentation, I read: SELECT EXTRACT(EPOCH FROM TIMESTAMP WITH TIME ZONE '2001-02-16 20:38:40-08'); Result: 982384720 and saw that the result was an integer. (which is correct, but it threw me off the scent). Aside: I still contend that this isn't a very obvious way to do it, being hard to find in the documentation, and slightly inconsistent because every other EXTRACT option pulls out some fraction of the field. (eg Extract month gives the current month number, rather than the number of whole months elapsed since the epoch). Also, a shorthand function name for this would be helpful. There are two places where I think the documentation on this page http://www.postgresql.org/docs/8.3/static/functions-datetime.html could be improved: (a) Table 9-26. Date/Time Functions doesn't contain ANY summary for how to get the seconds since the epoch. An initial look at EXTRACT would make it appear irrelevant. (b) Nowhere on the page is there a full example for getting seconds+microseconds since the epoch * Division of a timestamp by an interval should result in something dimensionless. This isn't a particularly sane thing to think about, because intervals aren't single numbers. Peter Eisentraut wrote: > On Monday 10 August 2009 03:41:06 Richard Neill wrote: >> * Division of a timestamp by an interval should result in something >> dimensionless. > > What would be the semantics of this? What's today divided by 2 hours? > I see your point. But on the other hand, it's very common to talk about "distance (in metres) = 300" or "50 seconds / seconds = 50" What I think I meant was dividing a differential timestamp by an interval. In this case, both should be unambiguously expressed in seconds, and the result will be dimensionless. For example: select interval '3 weeks' / interval '1 week'; will fail, yet select extract (epoch from interval '3 weeks') / extract (epoch from interval '1 week'); gives the correct answer of 3. Do you agree that an explicit cast of a timestamp to a double should work? Do you agree that abs() should be able to operate on an interval? select abs( interval '-1 week'); Thanks for your help, Richard -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #4959: unable to install/start service
Robert Haas wrote: On Fri, Jul 31, 2009 at 11:00 AM, wrote: The following bug has been logged online: Bug reference: 4959 Logged by: Email address: wad...@jcom.home.ne.jp PostgreSQL version: 8.4.0 Operating system: Windows Description:unable to install/start service Details: If service account password contains '>', installer fails to install service. (the password was made by 8.3.x installer...) I see no one replied to this. Is this a real bug? I think no one need to use '>' in password, and this may be windows installer problem. Password text after '>' was used as redirection filename. So params after password were ignored. -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] Huge speed penalty using <>TRUE instead of =FALSE
On Fri, Jul 17, 2009 at 10:21 AM, Tom Lane wrote: > Peter Eisentraut writes: >> ... But again, this is data type specific knowledge. > > Actually, now that I think about it, the planner already has > datatype-specific knowledge about boolean equality (see > simplify_boolean_equality). It would take just a few more lines of code > there to recognize "x <> true" and "x <> false" as additional variant > spellings of the generic "x" or "NOT x" constructs. Not sure if it's > worth the trouble though; how many people really write such things? I don't know, but there's probably somebody. I probably did it myself a few times, when I was just starting out. If it's easy, it seems worth doing. The problem with these things is that no matter how lame it seems to do whatever-it-is, the pain when someone does is really large... so adding a little bit of code to avoid that seems worthwhile, at least to me. > If you really wanted to take it to extremes, you could also reduce > cases like "x > false", but that's starting to get a bit silly. Probably that one is beyond even my tolerance. ...Robert -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #4972: RFE: convert timestamps to fractional seconds
On Mon, Aug 10, 2009 at 8:52 AM, Richard Neill wrote: > What I think I meant was dividing a differential timestamp by an interval. > In this case, both should be unambiguously expressed in seconds, and the > result will be dimensionless. And what will you get when you divide 1 month by 1 day? ...Robert -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #4961: pg_standby.exe crashes with no args
Bruce Momjian wrote: I can't reproduce a crash here on BSD: $ pg_standby pg_standby: not enough command-line arguments Can you show us the command and the crash text? I guess this occurs on only windows (Japanese envionment?). C:\Program Files\PostgreSQL\8.4\bin>pg_standby.exe results no text on command line, Windows error dialog. AppName:pg_standby.exe AppVer:0.0.0.0 ModName:msvcr80.dll ModVer:8.0.50727.762 Offset:91ad -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] Huge speed penalty using <>TRUE instead of =FALSE
Robert Haas writes: > On Fri, Jul 17, 2009 at 10:21 AM, Tom Lane wrote: >> Actually, now that I think about it, the planner already has >> datatype-specific knowledge about boolean equality (see >> simplify_boolean_equality). It would take just a few more lines of code >> there to recognize "x <> true" and "x <> false" as additional variant >> spellings of the generic "x" or "NOT x" constructs. Not sure if it's >> worth the trouble though; how many people really write such things? > I don't know, but there's probably somebody. I probably did it myself > a few times, when I was just starting out. If it's easy, it seems > worth doing. http://archives.postgresql.org/pgsql-committers/2009-07/msg00164.php regards, tom lane -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #4972: RFE: convert timestamps to fractional seconds
Richard Neill writes: > (b) Nowhere on the page is there a full example for getting > seconds+microseconds since the epoch Yeah, we could change that example to include a fractional part in the timestamp to make this clearer. > What I think I meant was dividing a differential timestamp by an > interval. In this case, both should be unambiguously expressed in > seconds, and the result will be dimensionless. What you're missing is that intervals are not single numbers, and are not simply numbers of seconds. > Do you agree that an explicit cast of a timestamp to a double should work? Doesn't seem like a particularly good idea. You're free to add such a cast to your own DBs, of course. > Do you agree that abs() should be able to operate on an interval? > select abs( interval '-1 week'); It's not as easy as that, because (once again) intervals aren't single numbers. For example, what should become of abs(interval '-1 month +1 day') The negative of this would be '1 month -1 day'. It's not real clear to me whether abs() should give that or '1 month 1 day', ie, make all the fields positive independently. regards, tom lane -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #4961: pg_standby.exe crashes with no args
Hi. Yes, I also reproduce it. It is very strange.. == Windows-XP Home Edition Version2002 Service Pack3(Japanese) CPU N270 @ 1.60Ghz 1GB RAM == C:\Program Files\PostgreSQL\8.4\bin>pg_standby.exe --help pg_standby allows PostgreSQL warm standby servers to be configured. Usage: C:\Program Files\PostgreSQL\8.4\bin>pg_standby.exe ...crash... However, MinGW+gcc returns a normal result. $ pg_standby pg_standby: not enough command-line arguments I don't have the margin time which still investigates it. Regards, Hiroshi Saito - Original Message - From: "wader2" Bruce Momjian wrote: I can't reproduce a crash here on BSD: $ pg_standby pg_standby: not enough command-line arguments Can you show us the command and the crash text? I guess this occurs on only windows (Japanese envionment?). C:\Program Files\PostgreSQL\8.4\bin>pg_standby.exe results no text on command line, Windows error dialog. AppName:pg_standby.exe AppVer:0.0.0.0 ModName:msvcr80.dll ModVer:8.0.50727.762 Offset:91ad -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #4961: pg_standby.exe crashes with no args
On Mon, Aug 10, 2009 at 16:10, wader2 wrote: > Bruce Momjian wrote: >> >> I can't reproduce a crash here on BSD: >> >> $ pg_standby >> pg_standby: not enough command-line arguments >> >> Can you show us the command and the crash text? > > I guess this occurs on only windows (Japanese envionment?). > > C:\Program Files\PostgreSQL\8.4\bin>pg_standby.exe > > results no text on command line, Windows error dialog. > > AppName:pg_standby.exe AppVer:0.0.0.0 ModName:msvcr80.dll > ModVer:8.0.50727.762 Offset:91ad I have reproduced this. The problem is: (void) signal(SIGUSR1, sighandler); (void) signal(SIGINT, sighandler); /* deprecated, use SIGUSR1 */ None of these signals exist on WIN32. I think the only reason it compiles at all is that we bring in *some* of our signals emulation code, but certainly not all of it. If I just move those two lines into the #ifndef WIN32 block just around it, it compiles and doesn't crash on running-with-no-arguments. I haven't tried to actually use it though - can someone confirm if this will actually make pg_standby not work properly? -- Magnus Hagander Me: http://www.hagander.net/ Work: http://www.redpill-linpro.com/ -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #4965: missing tests in tools/fsync/test_fsync.c
Jeff Janes wrote:
>
> The following bug has been logged online:
>
> Bug reference: 4965
> Logged by: Jeff Janes
> Email address: jeff.ja...@gmail.com
> PostgreSQL version: 8.4.0
> Operating system: Linux
> Description:missing tests in tools/fsync/test_fsync.c
> Details:
>
> In the part that implements "Compare file sync methods with one 8k write",
> the #ifdef OPEN_SYNC_FLAG code
> is nested within the #ifdef OPEN_DATASYNC_FLAG code.
>
> This causes o_sync to be skipped if o_dsync is unavailable, but only for
> this particular section (the section with 2 8k writes doesn't have this
> problem.)
>
> Also, the statement that prints the "Compare file sync methods with one 8k
> write" section title is up in the #ifdef block of a previous section, where
> it might be omitted on systems without an o_sync.
Yea, that C file needed some help. I have applied the attached patch to
CVS HEAD and 8.4.X. Thanks for the report and let me know if you think
this can be improved further.
--
Bruce Momjian http://momjian.us
EnterpriseDB http://enterprisedb.com
+ If your life is a hard drive, Christ can be your backup. +
Index: src/tools/fsync/test_fsync.c
===
RCS file: /cvsroot/pgsql/src/tools/fsync/test_fsync.c,v
retrieving revision 1.23
diff -c -c -r1.23 test_fsync.c
*** src/tools/fsync/test_fsync.c 11 Jun 2009 14:49:15 - 1.23
--- src/tools/fsync/test_fsync.c 10 Aug 2009 18:14:36 -
***
*** 30,36
#define FSYNC_FILENAME "/var/tmp/test_fsync.out"
#endif
! #define WRITE_SIZE (16 * 1024)
void die(char *str);
void print_elapse(struct timeval start_t, struct timeval elapse_t);
--- 30,36
#define FSYNC_FILENAME "/var/tmp/test_fsync.out"
#endif
! #define WRITE_SIZE (16 * 1024) /* 16k */
void die(char *str);
void print_elapse(struct timeval start_t, struct timeval elapse_t);
***
*** 71,76
--- 71,79
buf = (char *) TYPEALIGN(ALIGNOF_XLOG_BUFFER, full_buf);
+ /*
+ * Simple write
+ */
printf("Simple write timing:\n");
/* write only */
gettimeofday(&start_t, NULL);
***
*** 87,94
print_elapse(start_t, elapse_t);
printf("\n");
printf("\nCompare fsync times on write() and non-write() descriptor:\n");
! printf("(If the times are similar, fsync() can sync data written\n on a different descriptor.)\n");
/* write, fsync, close */
gettimeofday(&start_t, NULL);
--- 90,100
print_elapse(start_t, elapse_t);
printf("\n");
+ /*
+ * Fsync another file descriptor?
+ */
printf("\nCompare fsync times on write() and non-write() descriptor:\n");
! printf("If the times are similar, fsync() can sync data written\non a different descriptor.\n");
/* write, fsync, close */
gettimeofday(&start_t, NULL);
***
*** 132,137
--- 138,146
print_elapse(start_t, elapse_t);
printf("\n");
+ /*
+ * Compare 1 to 2 writes
+ */
printf("\nCompare one o_sync write to two:\n");
#ifdef OPEN_SYNC_FLAG
***
*** 148,154
print_elapse(start_t, elapse_t);
printf("\n");
! /* 2*8k o_sync writes */
if ((tmpfile = open(filename, O_RDWR | OPEN_SYNC_FLAG, 0)) == -1)
die("Cannot open output file.");
gettimeofday(&start_t, NULL);
--- 157,163
print_elapse(start_t, elapse_t);
printf("\n");
! /* Two 8k o_sync writes */
if ((tmpfile = open(filename, O_RDWR | OPEN_SYNC_FLAG, 0)) == -1)
die("Cannot open output file.");
gettimeofday(&start_t, NULL);
***
*** 163,176
close(tmpfile);
printf("\ttwo 8k o_sync writes ");
print_elapse(start_t, elapse_t);
- printf("\n");
-
- printf("\nCompare file sync methods with one 8k write:\n");
#else
printf("\t(o_sync unavailable) ");
#endif
printf("\n");
#ifdef OPEN_DATASYNC_FLAG
/* open_dsync, write */
if ((tmpfile = open(filename, O_RDWR | O_DSYNC, 0)) == -1)
--- 172,187
close(tmpfile);
printf("\ttwo 8k o_sync writes ");
print_elapse(start_t, elapse_t);
#else
printf("\t(o_sync unavailable) ");
#endif
printf("\n");
+ /*
+ * Compare file sync methods with one 8k write
+ */
+ printf("\nCompare file sync methods with one 8k write:\n");
+
#ifdef OPEN_DATASYNC_FLAG
/* open_dsync, write */
if ((tmpfile = open(filename, O_RDWR | O_DSYNC, 0)) == -1)
***
*** 183,189
--- 194,204
close(tmpfile);
printf("\topen o_dsync, write");
print_elapse(start_t, elapse_t);
+ #else
+ printf("\t(o_dsync unavailable) ");
+ #endif
printf("\n");
+
#ifdef OPEN_SYNC_FLAG
/* open_fsync, write */
if ((tmpfile = open(filename, O_RDWR | OPEN_SYNC_FLAG, 0)) == -1)
***
*** 196,204
close(tmpfile);
printf("\topen o_sync, write ");
print_elapse(start_t, elapse_t);
- #endif
#else
! printf("\t(o_dsync unavailable)
Re: [HACKERS] [BUGS] BUG #4961: pg_standby.exe crashes with no args
Magnus Hagander writes: > If I just move those two lines into the #ifndef WIN32 block just > around it, it compiles and doesn't crash on running-with-no-arguments. > I haven't tried to actually use it though - can someone confirm if > this will actually make pg_standby not work properly? It would mean there's no way to trigger failover via signal. I think what we need is for pg_ctl to be able to send these signals... regards, tom lane -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [HACKERS] [BUGS] BUG #4961: pg_standby.exe crashes with no args
On Mon, Aug 10, 2009 at 20:44, Tom Lane wrote: > Magnus Hagander writes: >> If I just move those two lines into the #ifndef WIN32 block just >> around it, it compiles and doesn't crash on running-with-no-arguments. >> I haven't tried to actually use it though - can someone confirm if >> this will actually make pg_standby not work properly? > > It would mean there's no way to trigger failover via signal. > > I think what we need is for pg_ctl to be able to send these signals... Those signals don't *exist* on Windows. The whole idea of cross-process signals don't *exist* on Windows. We emulate it in the main backend, by creating a background thread that sets a global variable. That is then polled in the CHECK_FOR_INTERRUPTS macro. pg_ctl is perfectly capable of sending these signals, but pg_standby can't receive them. We could implement the same type of check in pg_standby, but it requires something like CHECK_FOR_INTERRUPTS. And these interrupts won't, by default, cause any kind of interruption of the process. In the backend, we interrupt socket calls because we have the socket wrapper layer, and nothing else. I don't know how doable this would be in pg_standby - does it always block on a single thing where we could stick some win32 synchronization code? If it's a single, or limited, places we could implement something similar to the backend. But if we need to interrupt at arbitrary locations, that's just not possible. -- Magnus Hagander Me: http://www.hagander.net/ Work: http://www.redpill-linpro.com/ -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] Huge speed penalty using <>TRUE instead of =FALSE
On Mon, Aug 10, 2009 at 11:10 AM, Tom Lane wrote: > Robert Haas writes: >> On Fri, Jul 17, 2009 at 10:21 AM, Tom Lane wrote: >>> Actually, now that I think about it, the planner already has >>> datatype-specific knowledge about boolean equality (see >>> simplify_boolean_equality). It would take just a few more lines of code >>> there to recognize "x <> true" and "x <> false" as additional variant >>> spellings of the generic "x" or "NOT x" constructs. Not sure if it's >>> worth the trouble though; how many people really write such things? > >> I don't know, but there's probably somebody. I probably did it myself >> a few times, when I was just starting out. If it's easy, it seems >> worth doing. > > http://archives.postgresql.org/pgsql-committers/2009-07/msg00164.php > > regards, tom lane Oh, cool. Sorry, I missed the fact that that email was almost a month old. ...Robert -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #4970: Broken link in manual
Robert Haas escribió: > On Fri, Aug 7, 2009 at 12:31 AM, Rob Wultsh wrote: > > http://www.postgresql.org/docs/8.4/static/geqo-biblio.html links to "The > > Hitch-Hiker's Guide to Evolutionary Computation" > > (http://www.cs.bham.ac.uk/Mirrors/ftp.de.uu.net/EC/clife/www/location.htm) > > which as of 8/4/2009 responds with at 404 page. > > A quick Google search finds what appears to be that document here: > > http://www.aip.de/~ast/EvolCompFAQ/ > > Trivial patch attached, for the the benefit of any friendly committers > in the area. Should probably be backpatched also. This was the third report, so I guess something needed to be done. I backpatched it to 8.4, as I thought it unnecessary to backpatch any further back. -- Alvaro Herrerahttp://www.CommandPrompt.com/ The PostgreSQL Company - Command Prompt, Inc. -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
[BUGS] BUG #4973: number precision or scale lost when altering table column
The following bug has been logged online: Bug reference: 4973 Logged by: terry Email address: 94487...@qq.com PostgreSQL version: 8.3.3 Operating system: linux Description:number precision or scale lost when altering table column Details: Welcome to psql 8.3.3, the PostgreSQL interactive terminal. Type: \copyright for distribution terms \h for help with SQL commands \? for help with psql commands \g or terminate with semicolon to execute query \q to quit TEST=# CREATE TABLE B (C NUMERIC(8,3)); CREATE TABLE TEST=# INSERT INTO B VALUES (12345.678); INSERT 0 1 TEST=# SELECT * FROM B; c --- 12345.678 (1 row) TEST=# ALTER TABLE B ALTER COLUMN C TYPE NUMERIC(4,0); ERROR: numeric field overflow DETAIL: A field with precision 4, scale 0 must round to an absolute value less than 10^4. TEST=# ALTER TABLE B ALTER COLUMN C TYPE NUMERIC(5,0); ALTER TABLE /* scale lost */ TEST=# SELECT * FROM B; c --- 12346 (1 row) TEST=# oracle: SQL> CREATE TABLE Y (I NUMERIC(4,2)); Table created. SQL> INSERT INTO Y VALUES (12.21); 1 row created. SQL> SELECT * FROM Y; I -- 12.21 ORACLE can not modify, because precision or scale will be lost SQL> ALTER TABLE Y MODIFY I NUMERIC(3,0); ALTER TABLE Y MODIFY I NUMERIC(3,0) * ERROR at line 1: ORA-01440: column to be modified must be empty to decrease precision or scale SQL> ALTER TABLE Y MODIFY I NUMERIC(5,3); Table altered. SQL> INSERT INTO Y VALUES (12.123); 1 row created. SQL> SELECT * FROM Y; I -- 12.21 12.123 -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #4973: number precision or scale lost when altering table column
"terry" <94487...@qq.com> writes: > TEST=# CREATE TABLE B (C NUMERIC(8,3)); > CREATE TABLE > TEST=# INSERT INTO B VALUES (12345.678); > INSERT 0 1 > TEST=# SELECT * FROM B; > c > --- > 12345.678 > (1 row) > TEST=# ALTER TABLE B ALTER COLUMN C TYPE NUMERIC(4,0); > ERROR: numeric field overflow > DETAIL: A field with precision 4, scale 0 must round to an absolute value > less than 10^4. > TEST=# ALTER TABLE B ALTER COLUMN C TYPE NUMERIC(5,0); > ALTER TABLE > /* scale lost */ > TEST=# SELECT * FROM B; >c > --- > 12346 > (1 row) This is exactly the intended behavior. We're not really interested in Oracle's inability to handle the case. regards, tom lane -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
