Re: [HACKERS] Bug in VACUUM FULL ?

Tom Lane wrote: > > I've developed the attached patch against HEAD, and no longer see any > funny behavior. Would appreciate it if you'd test some more, though. > The patch works for me. With the patch applied, I don't see the weird errors in the pgbench and other customized tests that I used to

Re: [HACKERS] Bug in UTF8-Validation Code?

On Tue, Mar 13, 2007 at 04:42:35PM +0100, Mario Weilguni wrote: > Am Dienstag, 13. März 2007 16:38 schrieb Joshua D. Drake: > > Is this any different than the issues of moving 8.0.x to 8.1 UTF8? Where > > we had to use iconv? > > What issues? I've upgraded several 8.0 database to 8.1. without havi

Re: [HACKERS] Bug in UTF8-Validation Code?

Andrew Dunstan wrote: Albe Laurenz wrote: A fix could be either that the server checks escape sequences for validity This strikes me as essential. If the db has a certain encoding ISTM we are promising that all the text data is valid for that encoding. The question in my mind is how we h

Re: [HACKERS] Log levels for checkpoint/bgwriter monitoring

On Mon, 12 Mar 2007, Tom Lane wrote: It might also be interesting to know exactly how many buffers were pinned at the time the scan passed over them. In theory it should be a small fraction, but maybe it isn't ... It is; the theory holds for all the tests I tried today. The actual pinned bu

Re: [HACKERS] Bug in VACUUM FULL ?

> "Pavan Deolasee" <[EMAIL PROTECTED]> writes: >> The problem mentioned before is hard to reproduce with the >> suggested change, but its not completely gone away. I have >> seen that again on CVS HEAD with the patch applied. >> I am facing another issue with VACUUM FULL. This >> problem gets repro

Re: [HACKERS] Synchronized Scan update

On Tue, 2007-03-13 at 13:39 -0700, Jeff Davis wrote: > > > Do you have an opinion about sync_scan_threshold versus a simple > > > sync_scan_enable? > > > > enable_sync_scan? > > > > After looking at other GUC names, I suggest that it's either > "sync_scan" (for on/off) or "sync_scan_threshold"

Re: [HACKERS] Synchronized Scan update

On Tue, 2007-03-13 at 19:24 +, Simon Riggs wrote: > > The advantage of sync_scan_offset is that, in some situations, a second > > scan can actually finish faster than if it were the only query > > executing, because a previous scan has already caused some blocks to be > > cached. However, 16 is

Re: [HACKERS] 8.1.x (tested 8.1.8) timezone bugs

"Joshua D. Drake" <[EMAIL PROTECTED]> writes: > O.k., really trying to not be difficult here but... if we modified 8.1.9 > (to be released) to not fold the case of the unquoted timezone, doesn't > that resolve the issue entirely? (well it is a band-aid but still). No, it doesn't; the issue is what

Re: [HACKERS] Synchronized Scan update

On Tue, 2007-03-13 at 11:28 -0700, Jeff Davis wrote: > On Tue, 2007-03-13 at 17:11 +, Simon Riggs wrote: > > On Mon, 2007-03-12 at 17:46 -0700, Jeff Davis wrote: > > > On Mon, 2007-03-12 at 13:21 +, Simon Riggs wrote: > > > > So based on those thoughts, sync_scan_offset should be fixed at 1

Re: [HACKERS] 8.1.x (tested 8.1.8) timezone bugs

> AFAICS there is not any provision in the code that reads that string to > have different rules in different years, so you're more or less stuck > with being wrong before 2007 or being wrong after. Realistically this > means that POSIX-style rule strings are no longer useful, and you'd > better

Re: [HACKERS] 8.1.x (tested 8.1.8) timezone bugs

"Joshua D. Drake" <[EMAIL PROTECTED]> writes: > That is my actual concern. Before DST it wasn't an issue, now it is. Is > that PostgreSQL's problem? Probably not, but it certainly seems > inconsistent. [ digs around... ] Here we are (in localtime.c): /* * The DST rules to use if TZ has no rules

Re: [HACKERS] 8.1.x (tested 8.1.8) timezone bugs

Tom Lane wrote: > "Joshua D. Drake" <[EMAIL PROTECTED]> writes: >> Does this not seem a problem to you? > > No. 8.2 is case-insensitive on timezone names, but prior releases were not. > I believe the difference you're seeing in 8.1 is that 'PST8PDT' binds to > the zic database entry by that name,

Re: [HACKERS] 8.1.x (tested 8.1.8) timezone bugs

"Joshua D. Drake" <[EMAIL PROTECTED]> writes: > Does this not seem a problem to you? No. 8.2 is case-insensitive on timezone names, but prior releases were not. I believe the difference you're seeing in 8.1 is that 'PST8PDT' binds to the zic database entry by that name, while 'pst8pdt' falls back

Re: [HACKERS] 8.1.x (tested 8.1.8) timezone bugs

Tom Lane wrote: > "Joshua D. Drake" <[EMAIL PROTECTED]> writes: >> When updating for DST we found this nifty problem. This does not happen >> on 8.2. > > And your point is? Was the test case not clear? Is there something else I should have done? Does this not seem a problem to you? Sincerely, J

Re: [HACKERS] 8.1.x (tested 8.1.8) timezone bugs

"Joshua D. Drake" <[EMAIL PROTECTED]> writes: > When updating for DST we found this nifty problem. This does not happen > on 8.2. And your point is? regards, tom lane ---(end of broadcast)--- TIP 4: Have you searched our lis

Re: [HACKERS] Synchronized Scan update

On Tue, 2007-03-13 at 17:11 +, Simon Riggs wrote: > On Mon, 2007-03-12 at 17:46 -0700, Jeff Davis wrote: > > On Mon, 2007-03-12 at 13:21 +, Simon Riggs wrote: > > > So based on those thoughts, sync_scan_offset should be fixed at 16, > > > rather than being variable. In addition, ss_report_l

Re: [HACKERS] My honours project - databases using dynamically attached entity-properties

On Tue, Mar 13, 2007 at 05:54:34PM +, Richard Huxton wrote: > David Fetter wrote: > >On Tue, Mar 13, 2007 at 02:21:37PM +, Richard Huxton wrote: > >>David Fetter wrote: > >>>On Tue, Mar 13, 2007 at 09:31:45AM +, Richard Huxton wrote: > * Another good example is the "questionnaire".

Re: [HACKERS] Daylight Saving Time question PostgreSQL 8.1.4

Josh Berkus writes: > Zdenec, >> I have following idea: >> 1) add guc varibale which enable usage of OS time zone files >> 2) add extra parameters into ./configure script which enable OS TZ >> support in the code and get path to OS TZ files. > If we're adding it as a configure-time variable, ther

[HACKERS] HOT WIP Patch - Version 4.4

Please see the version 4.4 of HOT WIP patch posted on pgsql-patches. I have fixed couple of bugs in the earlier version posted. Other than that there are not any significant changes in the patch. The row-level fragmentation had a bug where we were unintentionally sorting the line pointers array

Re: [HACKERS] Daylight Saving Time question PostgreSQL 8.1.4

Josh Berkus wrote: Tom, You can try the symlink game if you want, but it'll be on your own head whether it works or not. (For the record, I am hoping to do exactly that in future releases for Red Hat ... but in that context I know what the system's timezone code is. I'm less sure that I kn

Re: [HACKERS] Daylight Saving Time question PostgreSQL 8.1.4

Zdenec, > I have following idea: > > 1) add guc varibale which enable usage of OS time zone files > > 2) add extra parameters into ./configure script which enable OS TZ > support in the code and get path to OS TZ files. If we're adding it as a configure-time variable, there's no reason to have a

Re: [HACKERS] My honours project - databases using dynamically attached entity-properties

David Fetter wrote: On Tue, Mar 13, 2007 at 02:21:37PM +, Richard Huxton wrote: David Fetter wrote: On Tue, Mar 13, 2007 at 09:31:45AM +, Richard Huxton wrote: * Another good example is the "questionnaire". With all due respect, this is a solved problem *without EAV or run-time DDL*.

Re: [HACKERS] Daylight Saving Time question PostgreSQL 8.1.4

Tom Lane wrote: Josh Berkus writes: Michael, I'm also curious about the rationale to maintain a separate timezone data files for machines that supply them. It's because we found that we couldn't ensure consistency between operating systems while relying on OS files. Partly that, and partl

Re: [HACKERS] 8.1.x (tested 8.1.8) timezone bugs

Joshua D. Drake wrote: > Hello, > > When updating for DST we found this nifty problem. This does not happen > on 8.2. > Updated to show timezone: postgres=# SET TIMEZONE TO 'PST8PDT'; SET postgres=# select now(); now --- 2007-03-13 10:44:33.156381-07 (

Re: [HACKERS] Synchronized Scan update

Ühel kenal päeval, T, 2007-03-13 kell 12:53, kirjutas Tom Lane: > Jeff Davis <[EMAIL PROTECTED]> writes: > > I agree that ss_report_loc() doesn't need to report on every call. If > > there's any significant overhead I agree that it should report less > > often. Do you think that the overhead is sig

[HACKERS] 8.1.x (tested 8.1.8) timezone bugs

Hello, When updating for DST we found this nifty problem. This does not happen on 8.2. postgres=# SET TIMEZONE TO 'PST8PDT'; SET postgres=# select now(); now --- 2007-03-13 10:41:07.034754-07 (1 row) postgres=# SET TIMEZONE TO PST8PDT; SET postgres=# SE

Re: [HACKERS] Daylight Saving Time question PostgreSQL 8.1.4

Michael, > Currently Apple's format appears to work fine with postgresql. And > given the responses and to make a quick job of it I will be copying > Apple's files only on the machines affected instead of symlinking > until we can coordinate a new version update. It seems that we are > only being

Re: [HACKERS] Synchronized Scan update

On Tue, 2007-03-13 at 17:17 +, Simon Riggs wrote: > On Tue, 2007-03-13 at 10:08 -0700, Jeff Davis wrote: > > On Tue, 2007-03-13 at 12:53 -0400, Tom Lane wrote: > > > Jeff Davis <[EMAIL PROTECTED]> writes: > > > > I agree that ss_report_loc() doesn't need to report on every call. If > > > > ther

Re: [HACKERS] My honours project - databases using dynamically attached entity-properties

On Tue, Mar 13, 2007 at 02:21:37PM +, Richard Huxton wrote: > David Fetter wrote: > >On Tue, Mar 13, 2007 at 09:31:45AM +, Richard Huxton wrote: > >>* Another good example is the "questionnaire". > > > >With all due respect, this is a solved problem *without EAV or > >run-time DDL*. The UR

Re: [HACKERS] Synchronized Scan update

On Tue, 2007-03-13 at 10:08 -0700, Jeff Davis wrote: > On Tue, 2007-03-13 at 12:53 -0400, Tom Lane wrote: > > Jeff Davis <[EMAIL PROTECTED]> writes: > > > I agree that ss_report_loc() doesn't need to report on every call. If > > > there's any significant overhead I agree that it should report less

Re: [HACKERS] Synchronized Scan update

On Tue, 2007-03-13 at 10:08 -0700, Jeff Davis wrote: > > One extra LWLock cycle per page processed definitely *is* a significant > > overhead ... can you say "context swap storm"? I'd think about doing it > > once every 100 or so pages. > > > > No lock is needed to store the hint. If somehow the

Re: [HACKERS] Synchronized Scan update

On Mon, 2007-03-12 at 17:46 -0700, Jeff Davis wrote: > On Mon, 2007-03-12 at 13:21 +, Simon Riggs wrote: > > So based on those thoughts, sync_scan_offset should be fixed at 16, > > rather than being variable. In addition, ss_report_loc() should only > > report its position every 16 blocks, rath

Re: [HACKERS] Daylight Saving Time question PostgreSQL 8.1.4

You can try the symlink game if you want, but it'll be on your own head whether it works or not. (For the record, I am hoping to do exactly that in future releases for Red Hat ... but in that context I know what the system's timezone code is. I'm less sure that I know what Apple is using.) Tha

Re: [HACKERS] Daylight Saving Time question PostgreSQL 8.1.4

Tom, > You can try the symlink game if you want, but it'll be on your own head > whether it works or not. (For the record, I am hoping to do exactly > that in future releases for Red Hat ... but in that context I know what > the system's timezone code is. I'm less sure that I know what Apple > i

Re: [HACKERS] Synchronized Scan update

On Tue, 2007-03-13 at 12:53 -0400, Tom Lane wrote: > Jeff Davis <[EMAIL PROTECTED]> writes: > > I agree that ss_report_loc() doesn't need to report on every call. If > > there's any significant overhead I agree that it should report less > > often. Do you think that the overhead is significant on s

Re: [HACKERS] Synchronized Scan update

Jeff Davis <[EMAIL PROTECTED]> writes: > I agree that ss_report_loc() doesn't need to report on every call. If > there's any significant overhead I agree that it should report less > often. Do you think that the overhead is significant on such a simple > function? One extra LWLock cycle per page p

Re: [HACKERS] Daylight Saving Time question PostgreSQL 8.1.4

Josh Berkus writes: > Michael, >> I'm also curious about the rationale to maintain a separate timezone >> data files for machines that supply them. > It's because we found that we couldn't ensure consistency between operating > systems while relying on OS files. Partly that, and partly that we

Re: [HACKERS] Daylight Saving Time question PostgreSQL 8.1.4

On Tue, Mar 13, 2007 at 12:20:25PM -0400, Michael Ledford wrote: > It appears that we didn't do enough research in regards to the recent > DST switch. We poorly assumed that having our machine's timezone files > up to date would be sufficient not knowing that our version of > postgres relied on its

Re: [HACKERS] Daylight Saving Time question PostgreSQL 8.1.4

Michael, > I'm also curious about the rationale to maintain a separate timezone > data files for machines that supply them. It's because we found that we couldn't ensure consistency between operating systems while relying on OS files. -- Josh Berkus PostgreSQL @ Sun San Francisco

Re: [HACKERS] Synchronized Scan update

On Mon, 2007-03-12 at 13:21 +, Simon Riggs wrote: > So based on those thoughts, sync_scan_offset should be fixed at 16, > rather than being variable. In addition, ss_report_loc() should only > report its position every 16 blocks, rather than do this every time, > which will reduce overhead of t

[HACKERS] Daylight Saving Time question PostgreSQL 8.1.4

It appears that we didn't do enough research in regards to the recent DST switch. We poorly assumed that having our machine's timezone files up to date would be sufficient not knowing that our version of postgres relied on its own timezone files. The question is... can we symlink the share/postgr

Re: [HACKERS] Major Feature Interactions

"Merlin Moncure" <[EMAIL PROTECTED]> writes: > What about the interaction of plan invalidation and the security > problems with 'security definer'? I am especially curious if pl > functions will no longer regenerate their plans with each session for > 8.3. Is that going to be the case? It wasn't

Re: [HACKERS] Bug in UTF8-Validation Code?

Am Dienstag, 13. März 2007 16:38 schrieb Joshua D. Drake: > Andrew Dunstan wrote: > > Albe Laurenz wrote: > >> A fix could be either that the server checks escape sequences for > >> validity > > > > This strikes me as essential. If the db has a certain encoding ISTM we > > are promising that all th

Re: [HACKERS] Bug in UTF8-Validation Code?

Andrew Dunstan wrote: > Albe Laurenz wrote: >> A fix could be either that the server checks escape sequences for >> validity >> > > This strikes me as essential. If the db has a certain encoding ISTM we > are promising that all the text data is valid for that encoding. > > The question in my m

Re: [HACKERS] Bug in UTF8-Validation Code?

Albe Laurenz wrote: A fix could be either that the server checks escape sequences for validity This strikes me as essential. If the db has a certain encoding ISTM we are promising that all the text data is valid for that encoding. The question in my mind is how we help people to recover f

Re: [HACKERS] Bug in UTF8-Validation Code?

Mario Weilguni wrote: >>> Steps to reproduce: >>> create database testdb with encoding='UTF8'; >>> \c testdb >>> create table test(x text); >>> insert into test values ('\244'); ==> Is akzepted, even if not UTF8. >> >> This is working as expected, see the remark in >> >> http://www.postgresql.org/

Re: [HACKERS] My honours project - databases using dynamically attached entity-properties

Hmm, hstore + (optionally) functional indexes. Is it answer? Edward Stanley wrote: Hi, Was wondering if people would mind having a read over what I plan to do for my undergraduate honours project - you can get the proposal here: http://www.mcs.vuw.ac.nz/~eddie/489_Proposal.pdf What I'd bas

Re: [HACKERS] Bug: Buffer cache is not scan resistant

Simon, On 3/13/07 2:37 AM, "Simon Riggs" <[EMAIL PROTECTED]> wrote: >> We're planning a modification that I think you should consider: when there >> is a sequential scan of a table larger than the size of shared_buffers, we >> are allowing the scan to write through the shared_buffers cache. > >

Re: [HACKERS] My honours project - databases using dynamically attached entity-properties

David Fetter wrote: I think the main discussion has been around: 1. Whether Edward's final-year project is basically EAV (in which case he'll probably need to work hard to get good marks). As Josh mentioned, I'm on of the people who says EAV is never justified. We do have a way of expres

Re: [HACKERS] Bug in UTF8-Validation Code?

Am Dienstag, 13. März 2007 15:12 schrieb Andrew Dunstan: > The sentence quoted from the docs is perhaps less than a model of > clarity. I would take it to mean that no client-encoding -> > server-encoding translation will take place. Does it really mean that > the server will happily accept any esc

Re: [HACKERS] My honours project - databases using dynamically attached entity-properties

David Fetter wrote: On Tue, Mar 13, 2007 at 09:31:45AM +, Richard Huxton wrote: * Another good example is the "questionnaire". With all due respect, this is a solved problem *without EAV or run-time DDL*. The URL below has one excellent approach to this.

Re: [HACKERS] Bug in UTF8-Validation Code?

Mario Weilguni wrote: Am Dienstag, 13. März 2007 14:46 schrieb Albe Laurenz: Mario Weilguni wrote: Steps to reproduce: create database testdb with encoding='UTF8'; \c testdb create table test(x text); insert into test values ('\244'); ==> Is akzepted, even if not UTF8. This is w

Re: [HACKERS] Major Feature Interactions

On 2/28/07, Simon Riggs <[EMAIL PROTECTED]> wrote: There's a number of major features all coming together over the next weeks, so I wanted to raise some awareness of possible areas of interaction. My concern is more than just "will multiple patches apply together?", but extends into whether the f

Re: [HACKERS] My honours project - databases using dynamically attached entity-properties

On Tue, Mar 13, 2007 at 09:31:45AM +, Richard Huxton wrote: > Sean Utt wrote: > >And then what? Make the search box on www.postgresql.org able to > >handle an email address as search text without throwing a shoe? > > > >Search for [EMAIL PROTECTED] or any other 'email' address from the > >postg

Re: [HACKERS] Bug in UTF8-Validation Code?

Am Dienstag, 13. März 2007 14:46 schrieb Albe Laurenz: > Mario Weilguni wrote: > > Steps to reproduce: > > create database testdb with encoding='UTF8'; > > \c testdb > > create table test(x text); > > insert into test values ('\244'); ==> Is akzepted, even if not UTF8. > > This is working as expect

Re: [HACKERS] Bug in UTF8-Validation Code?

Mario Weilguni wrote: > Steps to reproduce: > create database testdb with encoding='UTF8'; > \c testdb > create table test(x text); > insert into test values ('\244'); ==> Is akzepted, even if not UTF8. This is working as expected, see the remark in http://www.postgresql.org/docs/current/static/s

Re: [HACKERS] [COMMITTERS] pgsql: Make configuration parameters fall back to their default values

Magnus Hagander wrote: On Mon, Mar 12, 2007 at 08:20:53PM -0500, Andrew Dunstan wrote: Gregory Stark wrote: "Tom Lane" <[EMAIL PROTECTED]> writes: [EMAIL PROTECTED] (Peter Eisentraut) writes: Make configuration parameters fall back to their default values when they ar

[HACKERS] Bug in UTF8-Validation Code?

Hi, I've a problem with a database, I can dump the database to a file, but restoration fails, happens with 8.1.4. Steps to reproduce: create database testdb with encoding='UTF8'; \c testdb create table test(x text); insert into test values ('\244'); ==> Is akzepted, even if not UTF8. pg_dump te

Re: [HACKERS] Bug: Buffer cache is not scan resistant

On Tue, 2007-03-13 at 13:40 +0900, ITAGAKI Takahiro wrote: > "Simon Riggs" <[EMAIL PROTECTED]> wrote: > > > > > With the default > > > > value of scan_recycle_buffers(=0), VACUUM seems to use all of buffers > > > > in pool, > > > > just like existing sequential scans. Is this intended? > > > > >

Re: [HACKERS] Bug: Buffer cache is not scan resistant

On Mon, 2007-03-12 at 22:16 -0700, Luke Lonergan wrote: > You may know we've built something similar and have seen similar gains. Cool > We're planning a modification that I think you should consider: when there > is a sequential scan of a table larger than the size of shared_buffers, we > are a

Re: [HACKERS] My honours project - databases using dynamically attached entity-properties

Sean Utt wrote: And then what? Make the search box on www.postgresql.org able to handle an email address as search text without throwing a shoe? Search for [EMAIL PROTECTED] or any other 'email' address from the postgres home page. Barfage every time. Easy for some isn't easy for all, apparent

Re: [HACKERS] My honours project - databases using dynamically attached entity-properties

On Tue, 2007-03-13 at 00:43, Richard Huxton wrote: > Josh Berkus wrote: > > I really don't see any way you could implement UDFs other than EAV that > > wouldn't be immensely awkward, or result in executing DDL at runtime. > > What's so horrible about DDL at runtime? Obviously, you're only going t

Re: [HACKERS] CLUSTER and MVCC

Tom Lane wrote: Heikki Linnakangas <[EMAIL PROTECTED]> writes: In each chain, there must be at least one non-dead tuple with xmin < Oldestxmin. Huh? Typically *all* the tuples but the last are dead, for varying values of "dead". Please be more specific what you mean. I meant dead as in Hea

Re: [HACKERS] czech national site is moved

Hi, On Tue, 2007-03-13 at 10:06 +0100, Pavel Stehule wrote: > I moved czech wiki from http://postgresql.interweb.cz to > http://www.pgsql.cz. Can somobody update web link? Done -- but you should send this to pgsql-www, not to this list. Regards, -- Devrim GÜNDÜZ PostgreSQL Replication, Consul

[HACKERS] czech national site is moved

Hello I moved czech wiki from http://postgresql.interweb.cz to http://www.pgsql.cz. Can somobody update web link? Thank You Pavel Stehule _ Emotikony a pozadi programu MSN Messenger ozivi vasi konverzaci. http://messenger.msn.cz

Re: [HACKERS] My honours project - databases using dynamically attached entity-properties

On Mon, Mar 12, 2007 at 10:05:58PM -0700, Sean Utt wrote: > And then what? Make the search box on www.postgresql.org able to handle an > email address as search text without throwing a shoe? > > Search for [EMAIL PROTECTED] or any other 'email' address from the > postgres home page. Barfage ever

Re: [HACKERS] [COMMITTERS] pgsql: Make configuration parameters fall back to their default values

On Mon, Mar 12, 2007 at 08:20:53PM -0500, Andrew Dunstan wrote: > Gregory Stark wrote: > > "Tom Lane" <[EMAIL PROTECTED]> writes: > > > >> [EMAIL PROTECTED] (Peter Eisentraut) writes: > >>> Make configuration parameters fall back to their default values when > >>> they > >>> are removed from the co