Re: [HACKERS] ISBN/ISSN/ISMN/EAN13 module

2006-08-23 Thread Jeremy Kronuz
> > >  > > > Michael wrote:> > > I do hope that your algorithm for generating 13 digits from 10 has been > > > validated with isbn.org, since all the check digits will change.  I > > > believe it is crucial for postgresql to generate isbn codes in both 10 > > > and 13 digits> >> > Indeed now that

Re: [HACKERS] [PATCHES] Patch - Have psql show current values

2006-08-23 Thread Dhanaraj M
For \ds command, this patch displays the current sequence value(last_value) for each sequence. This was suggested during the earlier discussion. Output of the current patch: -- mydb=# \ds List of relations Schema | Name | Type | Owner |

Re: [HACKERS] [PATCHES] Patch - Have psql show current values

2006-08-23 Thread Peter Eisentraut
Dhanaraj M wrote: > This patch was discussed a few months ago. > I could not complete this patch at that time. > I hope that the current version of my patch is acceptable. What is this patch supposed to be doing? -- Peter Eisentraut http://developer.postgresql.org/~petere/ -

Re: [HACKERS] Some minor changes to pgbench

2006-08-23 Thread Tom Lane
ITAGAKI Takahiro <[EMAIL PROTECTED]> writes: > If we provide 'external initializer', some of your proposals can be done > through more generalized way, at least the foreign key test. ... > Are you interested in this idea? Sounds good to me --- this seems to follow along with Tatsuo's recent work t

Re: [HACKERS] Some minor changes to pgbench

2006-08-23 Thread ITAGAKI Takahiro
"Joshua D. Drake" <[EMAIL PROTECTED]> wrote: > >> Would it be worthwhile to add a switch so that the foreign key test is > >> only used "if" they use the switch in conjunction with a -i? > > > > I wouldn't object to providing that as a (non default) option. > > O.k. I will take a look at what t

Re: [HACKERS] pgsql-patches reply-to (was Re: [PATCHES] selecting large result sets in psql using cursors)

2006-08-23 Thread Alvaro Herrera
Peter Eisentraut wrote: > Alvaro Herrera wrote: > > I have on my TODO to have procmail > > throw away an email that it already delivered (e.g. by comparing > > Message-Id's), so if someone has a solution to that I'd like to know. > > :0 Wh: msgid.lock > | formail -D 65536 $HOME/.msgid.cache > > I

Re: [HACKERS] seahorse again failing

2006-08-23 Thread Tom Lane
"Magnus Hagander" <[EMAIL PROTECTED]> writes: >> Could someone with access to Windows code and test this? > Do you mean something as simple as this? > compiles, passes regression tests, logs this on startup of a fresh > cluster: > LOG: win32 open error on 'global/pgstat.stat': 2 Looks good ---

Re: [HACKERS] [PATCHES] Some minor changes to pgbench

2006-08-23 Thread Joshua D. Drake
Tom Lane wrote: "Joshua D. Drake" <[EMAIL PROTECTED]> writes: Would it be worthwhile to add a switch so that the foreign key test is only used "if" they use the switch in conjunction with a -i? I wouldn't object to providing that as a (non default) option. O.k. I will take a look at what tha

Re: [HACKERS] Tricky bugs in concurrent index build

2006-08-23 Thread Tom Lane
I wrote: > The problem case is that we take a tuple and try to insert it into the index. > Meanwhile someone else updates the tuple, and they're faster than us so > they get the new version into the index first. Now our aminsert sees a > conflicting index entry, and as soon as it commits good amin

Re: [HACKERS] [PATCHES] Some minor changes to pgbench

2006-08-23 Thread Tom Lane
"Joshua D. Drake" <[EMAIL PROTECTED]> writes: > Would it be worthwhile to add a switch so that the foreign key test is > only used "if" they use the switch in conjunction with a -i? I wouldn't object to providing that as a (non default) option. The int8 change should be unnecessary in view of Ta

Re: [HACKERS] [PATCHES] Merge join performance

2006-08-23 Thread Tom Lane
Heikki Linnakangas <[EMAIL PROTECTED]> writes: > We can make markpos fast, if we make the copy lazily in _bt_steppage, Nice hack. Getting rid of the buffer refcount manipulations is probably even more useful than avoiding the memcpy. > I did some micro-benchmarking of merge join performance, se

Re: [HACKERS] ISBN/ISSN/ISMN/EAN13 module

2006-08-23 Thread mdean
Jeremy Kronuz wrote: > Michael wrote: > I do hope that your algorithm for generating 13 digits from 10 has been > validated with isbn.org, since all the check digits will change. I > believe it is crucial for postgresql to generate isbn codes in both 10 > and 13 digits Indeed now that see

Re: [HACKERS] Problem with mailing list?

2006-08-23 Thread Bruno Wolff III
On Wed, Aug 23, 2006 at 08:47:03 +0200, Zdenek Kotala <[EMAIL PROTECTED]> wrote: > Is everything ok with postgres mail server? I have problem to send mail > to hackers list and pgadmin-hacker as well. If somebody is on cc, he > receives mail correctly, but it does not appear in the list. Any su

Re: [HACKERS] ISBN/ISSN/ISMN/EAN13 module

2006-08-23 Thread Jeremy Kronuz
  > Michael wrote:> I do hope that your algorithm for generating 13 digits from 10 has been > validated with isbn.org, since all the check digits will change.  I > believe it is crucial for postgresql to generate isbn codes in both 10 > and 13 digits Indeed now that see the module it's finally cl

Re: [HACKERS] pgsql-patches reply-to (was Re: [PATCHES] selecting large result sets in psql using cursors)

2006-08-23 Thread Peter Eisentraut
Alvaro Herrera wrote: > I have on my TODO to have procmail > throw away an email that it already delivered (e.g. by comparing > Message-Id's), so if someone has a solution to that I'd like to know. :0 Wh: msgid.lock | formail -D 65536 $HOME/.msgid.cache I don't use the eliminatecc feature either,

Re: [HACKERS] [PATCHES] selecting large result sets in psql using

2006-08-23 Thread Andrew Dunstan
[EMAIL PROTECTED] wrote: To cut the Gordon knot I'm going to suggest we use: ITYM "Gordian" - see http://en.wikipedia.org/wiki/Gordian_Knot cheers andrew ;-) ---(end of broadcast)--- TIP 5: don't forget to increase your free space map set

Re: [HACKERS] pgsql-patches reply-to (was Re: [PATCHES] selecting large result sets in psql using cursors)

2006-08-23 Thread Bruno Wolff III
On Wed, Aug 23, 2006 at 15:03:24 -0400, Alvaro Herrera <[EMAIL PROTECTED]> wrote: > Bruno Wolff III wrote: > > > > I do, but it is a lot of email and if I miss a few days it takes a while to > > catch up again. At some point I will probably do some smarter filtering, but > > I don't want to spen

Re: [HACKERS] pgsql-patches reply-to (was Re: [PATCHES] selecting large result sets in psql using cursors)

2006-08-23 Thread Alvaro Herrera
Bruno Wolff III wrote: > On Tue, Aug 22, 2006 at 23:15:59 -0400, > Robert Treat <[EMAIL PROTECTED]> wrote: > > On Thursday 17 August 2006 11:55, Peter Eisentraut wrote: > > > > I'm curious, do you combine any other lists like that? I've played around > > with that idea (for example, I used to

Re: [HACKERS] pgsql-patches reply-to (was Re: [PATCHES] selecting large result sets in psql using cursors)

2006-08-23 Thread Bruno Wolff III
On Tue, Aug 22, 2006 at 23:15:59 -0400, Robert Treat <[EMAIL PROTECTED]> wrote: > On Thursday 17 August 2006 11:55, Peter Eisentraut wrote: > > I'm curious, do you combine any other lists like that? I've played around > with that idea (for example, I used to combine webmaster emails, pgsql-www

Re: [HACKERS] [PATCHES] COPY view

2006-08-23 Thread Tom Lane
Zoltan Boszormenyi <[EMAIL PROTECTED]> writes: > How about the callback solution for the SELECT case > that was copied from the original? Should I consider > open-coding in copy.c what ExecutorRun() does > to avoid the callback? Adding a DestReceiver type is a good solution ... although that stati

Re: [HACKERS] [PATCHES] COPY view

2006-08-23 Thread Tom Lane
Alvaro Herrera <[EMAIL PROTECTED]> writes: > Which is why you should leave the relation case alone and only add the > different case. The relation case is already known to be good. Well, a certain amount of refactoring of the code is inevitable unless we want a lot of code duplication. But I don

Re: [HACKERS] [PATCHES] COPY view

2006-08-23 Thread Alvaro Herrera
Zoltan Boszormenyi wrote: > 1. to minimize the already huge code impact on the relation case. > 2. the checks done for the SELECT case is not exactly the > same as for the realation case. So put them in CopyToRelation. But the ones that apply to both, leave in CopyTo. > 3. the relation case

Re: [HACKERS] Win32 max connections bug (causing crashes)

2006-08-23 Thread Merlin Moncure
On 8/18/06, Magnus Hagander <[EMAIL PROTECTED]> wrote: > i doubled all my heap settings and was able to roughly double the - > c > on pgbench from ~158 (stock) to ~330 (modified). so this is > definately the problem. If you try decreasing max_files_per_process to a significantly lower value (s

Re: [HACKERS] [PATCHES] COPY view

2006-08-23 Thread Zoltan Boszormenyi
Tom Lane írta: [ cc list trimmed to something reasonable ] Zoltan Boszormenyi <[EMAIL PROTECTED]> writes: OK, here's my current version. The reference leak is fixed. But as my testcase shows, it only works for single selects currently. The parser accepts it but COPY doesn't produce the expec

Re: [HACKERS] [PATCHES] COPY view

2006-08-23 Thread Andrew Dunstan
Tom Lane wrote: frankly I see no reason for this patch to be messing with the relation case at all. Quite apart from anything else, if it's done that way nothing that currently works gets broken. cheers andrew ---(end of broadcast)--- TIP

Re: [HACKERS] [PATCHES] COPY view

2006-08-23 Thread Alvaro Herrera
Zoltan Boszormenyi wrote: > The exact same code was there, > e.g. parse and rewrite "SELECT * FROM view" > just not in analyze.c. I will try without it, though. And it was wrong as well. (The code was there on the COPY-view patch, not on the official code). -- Alvaro Herrera

Re: [HACKERS] [PATCHES] COPY view

2006-08-23 Thread Tom Lane
[ cc list trimmed to something reasonable ] Zoltan Boszormenyi <[EMAIL PROTECTED]> writes: > OK, here's my current version. The reference leak is fixed. > But as my testcase shows, it only works for single selects > currently. The parser accepts it but COPY doesn't produce > the expected output. P

Re: [HACKERS] Tricky bugs in concurrent index build

2006-08-23 Thread Tom Lane
Gregory Stark <[EMAIL PROTECTED]> writes: > Tom Lane <[EMAIL PROTECTED]> writes: >> I think that's OK, but the whole idea of using an MVCC snap in phase 2 >> doesn't work on closer inspection. The problem is still the same one >> that you need to take (at least) share lock on each tuple you insert

Re: [HACKERS] [PATCHES] selecting large result sets in psql using

2006-08-23 Thread chrisnospam
>> To cut the Gordon knot I'm going to suggest we use: > >> \set CURSOR_FETCH fetch_count > >> and \g and ; are modified such that when they see >> this variable set to fetch_count > 0 and the buffer >> is a select they would use the modified fetch/output code. > >> Does this sound reasonable to ev

Re: [HACKERS] Replication

2006-08-23 Thread Jeff Davis
On Wed, 2006-08-23 at 13:36 +0200, Markus Schiltknecht wrote: > Hannu Krosing wrote: > > But if you have very few writes, then there seems no reason to do sync > > anyway. > > I think there is one: high-availability. A standby-server which can > continue if your primary fails. Of course sync is o

Re: [HACKERS] Tricky bugs in concurrent index build

2006-08-23 Thread Gregory Stark
Tom Lane <[EMAIL PROTECTED]> writes: > I think that's OK, but the whole idea of using an MVCC snap in phase 2 > doesn't work on closer inspection. The problem is still the same one > that you need to take (at least) share lock on each tuple you insert > into the index. Telling aminsert to check

Re: [HACKERS] Replication

2006-08-23 Thread Markus Schiltknecht
Hi, Hannu Krosing wrote: but it still needs to do at least one network roundtrip + any needed testing on all nodes + WAL sync on all nodes before it can COMMIT, no? No. It only needs the 'roundtrip' in the sense that a transaction sends out its writeset and has to wait for the GCS to have it

Re: [HACKERS] Tricky bugs in concurrent index build

2006-08-23 Thread Tom Lane
stark <[EMAIL PROTECTED]> writes: > What happens if someone inserts a record that we miss, but it gets deleted by > the same phase 2 starts. So it's not visible to phase 2 but conflicts with > some other record we find. I suppose that's ok since the delete would have to > have comitted for that to

Re: [HACKERS] [PATCHES] COPY view

2006-08-23 Thread Zoltan Boszormenyi
Alvaro Herrera írta: Zoltan Boszormenyi wrote: OK, here's my current version. The reference leak is fixed. But as my testcase shows, it only works for single selects currently. The parser accepts it but COPY doesn't produce the expected output. Please, suggest a solution. I'm not sure

Re: [HACKERS] [PATCHES] COPY view

2006-08-23 Thread Alvaro Herrera
Zoltan Boszormenyi wrote: > OK, here's my current version. The reference leak is fixed. > But as my testcase shows, it only works for single selects > currently. The parser accepts it but COPY doesn't produce > the expected output. Please, suggest a solution. I'm not sure I agree with the approac

Re: [HACKERS] [PATCHES] COPY view

2006-08-23 Thread Zoltan Boszormenyi
Zoltan Boszormenyi írta: Hi, Bruce Momjian írta: Alvaro Herrera wrote: Bruce Momjian wrote: Andrew Dunstan wrote: Bruce Momjian wrote: I think Alvaro is saying we need it in a few days, not longer. I thought he was saying today ;-) He actually said

Re: [HACKERS] [PATCHES] COPY view

2006-08-23 Thread Zoltan Boszormenyi
Hi, Bruce Momjian írta: Alvaro Herrera wrote: Bruce Momjian wrote: Andrew Dunstan wrote: Bruce Momjian wrote: I think Alvaro is saying we need it in a few days, not longer. I thought he was saying today ;-) He actually said "now", but I don't thi

Re: [HACKERS] An Idea for planner hints

2006-08-23 Thread Mark Dilger
Jim C. Nasby wrote: On Tue, Aug 22, 2006 at 11:56:17AM -0700, Mark Dilger wrote: I proposed something like this quite a bit up-thread. I was hoping we could have a mode in which the system would run the second, third, fourth, ... best plans rather than just the best looking one, and then deter

Re: [HACKERS] [PATCHES] COPY view

2006-08-23 Thread Bruce Momjian
Alvaro Herrera wrote: > Bruce Momjian wrote: > > Andrew Dunstan wrote: > > > Bruce Momjian wrote: > > > > I think Alvaro is saying we need it in a few days, not longer. > > > > > > I thought he was saying today ;-) > > > > He actually said "now", but I don't think we need it immediately, > > espe

Re: [HACKERS] [PATCHES] COPY view

2006-08-23 Thread Alvaro Herrera
Bruce Momjian wrote: > Andrew Dunstan wrote: > > Bruce Momjian wrote: > > > I think Alvaro is saying we need it in a few days, not longer. > > > > I thought he was saying today ;-) > > He actually said "now", but I don't think we need it immediately, > especially if he is still working on it. We

Re: [HACKERS] Tricky bugs in concurrent index build

2006-08-23 Thread stark
Tom Lane <[EMAIL PROTECTED]> writes: >> Or do you mean we use SatisfiesVacuum to determine what to insert but >> SatisfiesSnapshot to determine whether to check uniqueness? > > Right. The problems seem to all stem from the risk of trying to > unique-check more than one version of a tuple, and usi

Re: [HACKERS] Question about (lazy) vacuum

2006-08-23 Thread Tom Lane
Hannu Krosing <[EMAIL PROTECTED]> writes: > Ühel kenal päeval, K, 2006-08-23 kell 05:23, kirjutas Gregory Stark: >> global xmin it just occurred to me to wonder: Does lazy vacuum need a >> transaction at all? > When I asked the same question, I was told that a lot of core > functionality vacuum

Re: [HACKERS] [PATCHES] Some minor changes to pgbench

2006-08-23 Thread Joshua D. Drake
Tom Lane wrote: "Joshua D. Drake" <[EMAIL PROTECTED]> writes: Tom Lane wrote: Addition of foreign key checking will certainly impact performance significantly. That is kind of the point. Without foreign keys it is a flawed test because you wouldn't be running in production without them and t

Re: [HACKERS] [PATCHES] Some minor changes to pgbench

2006-08-23 Thread Tom Lane
"Joshua D. Drake" <[EMAIL PROTECTED]> writes: > Tom Lane wrote: >> Addition of foreign key checking will certainly impact performance >> significantly. > That is kind of the point. Without foreign keys it is a flawed test > because you wouldn't be running in production without them and thus you

Re: [HACKERS] Replication

2006-08-23 Thread Hannu Krosing
Ühel kenal päeval, K, 2006-08-23 kell 13:36, kirjutas Markus Schiltknecht: > Hannu Krosing wrote: > > But if you have very few writes, then there seems no reason to do sync > > anyway. > > I think there is one: high-availability. A standby-server which can > continue if your primary fails. Of cou

Re: [HACKERS] Tricky bugs in concurrent index build

2006-08-23 Thread Tom Lane
stark <[EMAIL PROTECTED]> writes: > Tom Lane <[EMAIL PROTECTED]> writes: >> [ thinks for a bit... ] At least, it seems hopeless if we use >> SnapshotNow. Does it help if we use a real snapshot? I'm thinking >> pass 1 inserts exactly those tuples that are good according to a >> snap taken at its

Re: [HACKERS] [PATCHES] Some minor changes to pgbench

2006-08-23 Thread Joshua D. Drake
Tom Lane wrote: "Joshua D. Drake" <[EMAIL PROTECTED]> writes: * The schema now uses foreign keys to more accurately reflect a finacial DDL Addition of foreign key checking will certainly impact performance significantly. That is kind of the point. Without foreign keys it is a flawed test be

Re: [HACKERS] [PATCHES] COPY view

2006-08-23 Thread Bruce Momjian
Andrew Dunstan wrote: > Bruce Momjian wrote: > > I think Alvaro is saying we need it in a few days, not longer. > > > > > > I thought he was saying today ;-) He actually said "now", but I don't think we need it immediately, especially if he is still working on it. We are at least 1-2 weeks aw

Re: [HACKERS] [PATCHES] COPY view

2006-08-23 Thread Andrew Dunstan
Bruce Momjian wrote: I think Alvaro is saying we need it in a few days, not longer. I thought he was saying today ;-) cheers andrew ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.or

Re: [HACKERS] [PATCHES] COPY view

2006-08-23 Thread Böszörményi Zoltán
> Böszörményi Zoltán wrote: >> > B?sz?rm?nyi Zolt?n wrote: >> > >> >> > So when will you send in a revised patch? >> >> >> >> Soon. :-) >> > >> > No, don't send it "soon". We're in feature freeze already (and have >> > been for three weeks). You need to send it now. >> >> I have to test it some m

Re: [HACKERS] [PATCHES] Contrib module to examine client certificate

2006-08-23 Thread Peter Eisentraut
Am Dienstag, 22. August 2006 02:52 schrieb Bruce Momjian: > This seems like a nice /contrib module. > > Your patch has been added to the PostgreSQL unapplied patches list at: > > http://momjian.postgresql.org/cgi-bin/pgpatches > > It will be applied as soon as one of the PostgreSQL committers

Re: [HACKERS] Replication

2006-08-23 Thread D'Arcy J.M. Cain
On Wed, 23 Aug 2006 12:42:11 +0300 Hannu Krosing <[EMAIL PROTECTED]> wrote: > > OK, that solves your problem. How about my problem where replication > > has to happen on servers in three countries on two continents and > > thousands of updates a second have to happen in less that 10ms? > > For t

Re: [HACKERS] Question about (lazy) vacuum

2006-08-23 Thread Alvaro Herrera
Gregory Stark wrote: > > With all this code to handle ignoring vacuum transactions in calculating the > global xmin it just occurred to me to wonder: Does lazy vacuum need a > transaction at all? It doesn't do the tuple moving tricks with xvac that > vacuum full does so does lazy vacuum's xid ever

Re: [HACKERS] [PATCHES] COPY view

2006-08-23 Thread Bruce Momjian
B?sz?rm?nyi Zolt?n wrote: > > B?sz?rm?nyi Zolt?n wrote: > > > >> > So when will you send in a revised patch? > >> > >> Soon. :-) > > > > No, don't send it "soon". We're in feature freeze already (and have > > been for three weeks). You need to send it now. > > I have to test it some more but I w

Re: [HACKERS] [PATCHES] COPY view

2006-08-23 Thread Böszörményi Zoltán
> Böszörményi Zoltán wrote: > >> > So when will you send in a revised patch? >> >> Soon. :-) > > No, don't send it "soon". We're in feature freeze already (and have > been for three weeks). You need to send it now. I have to test it some more but I will send it. Best regards, Zoltán Böszörményi

Re: [HACKERS] pg_upgrade: What is changed?

2006-08-23 Thread Alvaro Herrera
Zdenek Kotala wrote: > Martijn van Oosterhout wrote: > >On Wed, Aug 23, 2006 at 10:26:19AM +0200, Zdenek Kotala wrote: > > > > > > > >>1) BKI - catalog. > >> c) Some records are changed > >> action: ??? > > > >They just need to be changed. In principle the datalog needs to be > >updated so

Re: [HACKERS] Tricky bugs in concurrent index build

2006-08-23 Thread Hannu Krosing
Ühel kenal päeval, K, 2006-08-23 kell 09:01, kirjutas Tom Lane: > Greg Stark <[EMAIL PROTECTED]> writes: > > Hmmm. Or is that true. The problem may be somewhat easier since at least you > > can be sure every tuple in the heap is in the index. So if you see a > > DELETE_IN_PROGRESS either it *was* a

Re: [HACKERS] seahorse again failing

2006-08-23 Thread Magnus Hagander
> > Tom Lane wrote: > >> It would be interesting to know the actual underlying Windows > error > >> code > >> --- I see that win32error.c maps several different codes to > EACCES. > > > It may be a good idea to put a elog(LOG) with the error code in > the > > failure path of AllocateFile. > > Tha

Re: [HACKERS] [PATCHES] COPY view

2006-08-23 Thread Alvaro Herrera
Böszörményi Zoltán wrote: > > So when will you send in a revised patch? > > Soon. :-) No, don't send it "soon". We're in feature freeze already (and have been for three weeks). You need to send it now. -- Alvaro Herrerahttp://www.CommandPrompt.com/ PostgreSQL

Re: [HACKERS] [PATCHES] COPY view

2006-08-23 Thread Alvaro Herrera
Böszörményi Zoltán wrote: > It seems I was able to get it working for both the VIEW and SELECT > cases. I still have one issue, the reference to the select is left open > and it complains on closing the transaction. But basically works. Cool, thanks. Send the patch and we can look it over to see

Re: [HACKERS] [PATCHES] COPY view

2006-08-23 Thread Böszörményi Zoltán
> Böszörményi Zoltán wrote: >> Hi, >> >> >>> Tom Lane wrote: >>> At the moment, with the online-index and updatable-views patches both pretty seriously broken, and no sign that the bitmap-index people are awake at all, I might take it on myself to fix this one instead of those >

Re: [HACKERS] [PATCHES] COPY view

2006-08-23 Thread Andrew Dunstan
Böszörményi Zoltán wrote: Hi, Tom Lane wrote: At the moment, with the online-index and updatable-views patches both pretty seriously broken, and no sign that the bitmap-index people are awake at all, I might take it on myself to fix this one instead of those others. But is that what I

Re: [HACKERS] [PATCHES] COPY view

2006-08-23 Thread Böszörményi Zoltán
Hi, > Tom Lane wrote: >> >> At the moment, with the online-index and updatable-views patches both >> pretty seriously broken, and no sign that the bitmap-index people are >> awake at all, I might take it on myself to fix this one instead of those >> others. But is that what I should be spending m

Re: [HACKERS] Question about (lazy) vacuum

2006-08-23 Thread Hannu Krosing
Ühel kenal päeval, K, 2006-08-23 kell 08:11, kirjutas Greg Stark: > Hannu Krosing <[EMAIL PROTECTED]> writes: > > BTW, I think that CONCURRENT CREATE INDEX should be modified to use long > > transactions which actually build the index and are ignored by vacuum > > and short ones which write data t

Re: [HACKERS] Tricky bugs in concurrent index build

2006-08-23 Thread Tom Lane
Greg Stark <[EMAIL PROTECTED]> writes: > Hmmm. Or is that true. The problem may be somewhat easier since at least you > can be sure every tuple in the heap is in the index. So if you see a > DELETE_IN_PROGRESS either it *was* a constraint violation prior to the delete > and failing is reasonable or

Re: [HACKERS] [PATCHES] COPY view

2006-08-23 Thread Bernd Helmle
--On Mittwoch, August 23, 2006 08:24:55 -0400 Tom Lane <[EMAIL PROTECTED]> wrote: What are these open issues for the updatable views patch you are seeing exactly? Didn't Alvaro list a bunch of issues when he put the patch back up for comment? I have not looked at it myself yet. Indeed h

Re: [HACKERS] [GENERAL] Queries joining views

2006-08-23 Thread Tom Lane
Alban Hertroys <[EMAIL PROTECTED]> writes: > Mm_object is always larger than any other table in the database, as > every table joins with (different) records in it to determine it's otype > and owner. So I don't understand how a fraction of any of those tables > could be larger than mm_object as

Re: [HACKERS] Tricky bugs in concurrent index build

2006-08-23 Thread Tom Lane
Greg Stark <[EMAIL PROTECTED]> writes: > It seems like it would be simpler to leave the core in charge the whole time. > It would call an AM method to initialize state, then call an AM method for > each tuple that should be indexed, and lastly call a finalize method. [ shrug... ] I'm uninterested

Re: [HACKERS] Tricky bugs in concurrent index build

2006-08-23 Thread Tom Lane
Greg Stark <[EMAIL PROTECTED]> writes: > But then wouldn't we have deadlock risks? If we come across these records in a > different order from someone else (possibly even the deleter) who also wants > to lock them? Or would it be safe to lock and release them one by one so we > only every hold one

Re: [HACKERS] Tricky bugs in concurrent index build

2006-08-23 Thread Greg Stark
Hannu Krosing <[EMAIL PROTECTED]> writes: > Ühel kenal päeval, K, 2006-08-23 kell 11:05, kirjutas Hannu Krosing: > > > > Maybe we could find a way to build a non-unique index first and then > > convert it to a unique one later, in yet another pass ? > > Or even add ALTER INDEX myindex ADD/DROP

Re: [HACKERS] [PATCHES] COPY view

2006-08-23 Thread Tom Lane
Bernd Helmle <[EMAIL PROTECTED]> writes: > What are these open issues for the updatable views patch you are seeing > exactly? Didn't Alvaro list a bunch of issues when he put the patch back up for comment? I have not looked at it myself yet. > i see the INSERT...RETURNING stuff as the only "big

Re: [HACKERS] Question about (lazy) vacuum

2006-08-23 Thread Greg Stark
Hannu Krosing <[EMAIL PROTECTED]> writes: > When I asked the same question, I was told that a lot of core > functionality vacuum uses needs to be in transaction. I guess bad things > can happen, if some other backend ends a transaction you claim to be in. > > And it is not so much about what end

Re: [HACKERS] [PATCHES] COPY view

2006-08-23 Thread Andrew Dunstan
Tom Lane wrote: At the moment, with the online-index and updatable-views patches both pretty seriously broken, and no sign that the bitmap-index people are awake at all, I might take it on myself to fix this one instead of those others. But is that what I should be spending my time on in the

Re: [HACKERS] [PATCHES] Use of backslash in tsearch2

2006-08-23 Thread Teodor Sigaev
Patch isn't full, simple test (values are took from regression.diffs): and try dump table and restore: ERROR: syntax error CONTEXT: COPY tt, line 5, column tq: "'1 ''2'" Attached cumulative patch fixes problem, but I have some doubts, is it really needed? -- Teodor Sigaev

Re: [HACKERS] [GENERAL] Queries joining views

2006-08-23 Thread Alban Hertroys
Tom Lane wrote: Alban Hertroys <[EMAIL PROTECTED]> writes: I'm confused too. Would it be possible for you to send me a dump of your database? Attached is a cleaned out database, the full schema is included, but only the relevant tables contain any data. Thanks. After digging through it a

Re: [HACKERS] pg_upgrade: What is changed?

2006-08-23 Thread Zdenek Kotala
Martijn van Oosterhout wrote: On Wed, Aug 23, 2006 at 10:26:19AM +0200, Zdenek Kotala wrote: 1) BKI - catalog. c) Some records are changed action: ??? They just need to be changed. In principle the datalog needs to be updated so it looks like a database initdb'd with the new versi

Re: [HACKERS] Tricky bugs in concurrent index build

2006-08-23 Thread Greg Stark
[Sorry for the duplicate -- I accidentally sent the previous before I was finished editing it] Tom Lane <[EMAIL PROTECTED]> writes: > I think we can solve this by having IndexBuildHeapScan not index > DELETE_IN_PROGRESS tuples if it's doing a concurrent build. The problem > of old transactions

Re: [HACKERS] Where is hstore?

2006-08-23 Thread tomas
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Wed, Aug 23, 2006 at 01:39:34PM +0400, Teodor Sigaev wrote: > >AFAIR the authors have never proposed it for inclusion. > > We'll be glad if hstore will be in main tarball. FWIW, I'd be glad too. >

Re: [HACKERS] Tricky bugs in concurrent index build

2006-08-23 Thread Greg Stark
Tom Lane <[EMAIL PROTECTED]> writes: > In the past, the only way we could see HEAPTUPLE_INSERT_IN_PROGRESS > or HEAPTUPLE_DELETE_IN_PROGRESS was for tuples created/deleted by our > own transaction, and so the actions taken by IndexBuildHeapScan are > to include in the index in both cases, but excl

Re: [HACKERS] Replication

2006-08-23 Thread Markus Schiltknecht
Hannu Krosing wrote: But if you have very few writes, then there seems no reason to do sync anyway. I think there is one: high-availability. A standby-server which can continue if your primary fails. Of course sync is only needed if you absolutely cannot effort loosing any committed transacti

Re: [HACKERS] Replication

2006-08-23 Thread Hannu Krosing
Ühel kenal päeval, K, 2006-08-23 kell 13:09, kirjutas Markus Schiltknecht: > Hannu Krosing wrote: > > But any sync _replication_ system will have severe impact on > > performance. My guess is that for a full sync replication, going from 1 > > server to 2 will actually lower performance andsome smal

Re: [HACKERS] Replication

2006-08-23 Thread Markus Schiltknecht
Hannu Krosing wrote: But any sync _replication_ system will have severe impact on performance. My guess is that for a full sync replication, going from 1 server to 2 will actually lower performance andsome small gains would be possible only starting from 3rd server. Only testing will show concr

Re: [HACKERS] Question about (lazy) vacuum

2006-08-23 Thread Hannu Krosing
Ühel kenal päeval, K, 2006-08-23 kell 05:23, kirjutas Gregory Stark: > With all this code to handle ignoring vacuum transactions in calculating the > global xmin it just occurred to me to wonder: Does lazy vacuum need a > transaction at all? It doesn't do the tuple moving tricks with xvac that > va

Re: [HACKERS] Replication

2006-08-23 Thread Hannu Krosing
Ühel kenal päeval, E, 2006-08-21 kell 15:00, kirjutas D'Arcy J.M. Cain: > On Mon, 21 Aug 2006 14:46:05 -0400 > "Gregory Maxwell" <[EMAIL PROTECTED]> wrote: > > On 8/21/06, Alvaro Herrera <[EMAIL PROTECTED]> wrote: > > > But the confirmation that needs to come is that the WAL changes have > > > been

Re: [HACKERS] Where is hstore?

2006-08-23 Thread Teodor Sigaev
AFAIR the authors have never proposed it for inclusion. We'll be glad if hstore will be in main tarball. As I remember, when we suggest (may be, in private exchange of letters) to include it, somebody says that hstore breaks "relational" in db. Lastest version is located at http://www.sigae

[HACKERS] Question about (lazy) vacuum

2006-08-23 Thread Gregory Stark
With all this code to handle ignoring vacuum transactions in calculating the global xmin it just occurred to me to wonder: Does lazy vacuum need a transaction at all? It doesn't do the tuple moving tricks with xvac that vacuum full does so does lazy vacuum's xid ever make it into tables? Couldn't

Re: [HACKERS] Enum proposal / design

2006-08-23 Thread Greg Stark
"Jim C. Nasby" <[EMAIL PROTECTED]> writes: > I think it would be good to have something, so that people are > occasionally reminded about these things. That's a good way to help > shake ideas out. I think the only reason there aren't more outrageous dreamworld ideas in the TODO is that people cam

Re: [HACKERS] Replication

2006-08-23 Thread Hannu Krosing
Ühel kenal päeval, E, 2006-08-21 kell 21:46, kirjutas Fujii Masao: > Stefan Kaltenbrunner wrote: > > It is however async replication so you can loose data commited on the > > master but not yet replicated to the slaves in case you loose the master > > completely. > > Yes, here is an insufficient

Re: [HACKERS] Tricky bugs in concurrent index build

2006-08-23 Thread Greg Stark
Tom Lane <[EMAIL PROTECTED]> writes: > What I think we can do about this is to include DELETE_IN_PROGRESS > tuples in the set of candidate tuples to insert in the second pass. > During the merge step that verifies whether the tuple is already > in the index, if we find that it's not, then we must

Leaving... (was: Re: [HACKERS] [PATCHES] COPY view)

2006-08-23 Thread Karel Zak
Hi all, seriously... I don't have time to work on PostgreSQL. It's time to say that I'm leaving this project. So, if you found some my broken code or whatever in PostgreSQL you should go and fix it. It's community-driven project. It's about collaboration -- don't ask "why should I help" --

Re: [HACKERS] pg_upgrade: What is changed?

2006-08-23 Thread Martijn van Oosterhout
On Wed, Aug 23, 2006 at 10:26:19AM +0200, Zdenek Kotala wrote: > 1) BKI - catalog. >c) Some records are changed >action: ??? They just need to be changed. In principle the datalog needs to be updated so it looks like a database initdb'd with the new version. > 5) Tuples > ques

Re: [HACKERS] Tricky bugs in concurrent index build

2006-08-23 Thread Zeugswetter Andreas DCP SD
> > Is it not possible to brute force this adding an AM method to insert > > without the uniqueness check? > > Hm. Actually there already is a feature of aminsert to allow > suppressing the unique check, but I'm not sure whether using > it for RECENTLY_DEAD tuples helps. Seems like we have t

Re: [HACKERS] [PATCHES] COPY view

2006-08-23 Thread Karel Zak
On Tue, Aug 22, 2006 at 01:11:22PM -0400, Andrew Dunstan wrote: > There's nothing hidden (unless it's also hidden from me ;-) ) > > I take it that when you talk about "we did this" you are referring to > the patch from Karel Zak. Hans has been original author of COPY VIEW idea and I've wrote it

[HACKERS] pg_upgrade: What is changed?

2006-08-23 Thread Zdenek Kotala
I'm working on pg_upgrade concept. I try to determine what is changed from 8.1 to 8.2. There is list of important areas for upgrade and suggested action. 1) BKI - catalog. There are a lot of changes. See attached file. a) There is new table pg_shdescription action: create b) T

Re: [HACKERS] seahorse again failing

2006-08-23 Thread Dave Page
> -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of > Magnus Hagander > Sent: 23 August 2006 09:25 > To: Andrew Dunstan; Tom Lane > Cc: Alvaro Herrera; Stefan Kaltenbrunner; PostgreSQL-development > Subject: Re: [HACKERS] seahorse again failing > >

Re: [HACKERS] seahorse again failing

2006-08-23 Thread Magnus Hagander
> >> It may be a good idea to put a elog(LOG) with the error code in > the > >> failure path of AllocateFile. > >> > > > > That seems like a plan to me. I had been thinking of making > > win32error.c itself log the conversions, but that would not > provide > > any context information. AllocateFil

Re: [HACKERS] Tricky bugs in concurrent index build

2006-08-23 Thread Hannu Krosing
Ühel kenal päeval, K, 2006-08-23 kell 11:05, kirjutas Hannu Krosing: > Ühel kenal päeval, T, 2006-08-22 kell 16:48, kirjutas Tom Lane: > > "Joshua D. Drake" <[EMAIL PROTECTED]> writes: > > >> It's fairly clear that we could support concurrent builds of nonunique > > >> indexes, but is that enough o

Re: [HACKERS] [PATCHES] COPY view

2006-08-23 Thread Bernd Helmle
--On Dienstag, August 22, 2006 23:12:21 -0400 Tom Lane <[EMAIL PROTECTED]> wrote: At the moment, with the online-index and updatable-views patches both pretty seriously broken, and no sign that the bitmap-index people are awake at all, I might take it on myself to fix this one instead of tho

Re: [HACKERS] Tricky bugs in concurrent index build

2006-08-23 Thread Hannu Krosing
Ühel kenal päeval, T, 2006-08-22 kell 16:48, kirjutas Tom Lane: > "Joshua D. Drake" <[EMAIL PROTECTED]> writes: > >> It's fairly clear that we could support concurrent builds of nonunique > >> indexes, but is that enough of a use-case to justify it? > > > I believe there would be. Most PostgreSQL

Re: [HACKERS] news server does not respond

2006-08-23 Thread Markus Schiltknecht
Christopher Browne wrote: Yeah, and you can't complain when you're cut off... :-) yeah, known problem... I used gmane to track the list, but... Regards Markus ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ?

  1   2   >