>
> > > > > 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
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 |
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/
-
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
"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
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
"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 ---
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
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
"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
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
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
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
> 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
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,
[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
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
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
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
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
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
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
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
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
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
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
[ 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
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
>> 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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
"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
Ü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
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
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
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
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
> 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
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
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
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
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
> 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
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
Ü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
> > 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
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
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
> 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
>
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
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
Ü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
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
--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
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
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
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
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
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
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
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
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
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
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
[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
-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.
>
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
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
Ü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
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
Ü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
Ü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
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
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
"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
Ü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
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
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" --
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
> > 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
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
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
> -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
>
>
> >> 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
Ü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
--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
Ü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
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 - 100 of 110 matches
Mail list logo
