Ühel kenal päeval, T, 2007-02-20 kell 12:08, kirjutas Pavan Deolasee:
>
> Reposting - looks like the message did not get through in the first
> attempt. My apologies if multiple copies are received.
>
>
> This is the next version of the HOT WIP patch. Since the last patch
> that
> I sent out, I
"Pavel Stehule" <[EMAIL PROTECTED]> writes:
> Nobody worked on this subject a lot of years. Who need it, knows about it
> and use it. I am for this topic is documented and in doc is note about
> difference from standard and about some incompletness of this operator.
Once we document it there's g
On Thu, 2007-02-15 at 10:49 +, Heikki Linnakangas wrote:
> Do we actually ever want to remove dead tuples from the middle of the
> chain? If a tuple in the middle of the chain is dead, surely every tuple
> before it in the chain is dead as well, and we want to remove them as
> well. I'm thi
On Fri, 2007-02-16 at 09:36 +0200, Hannu Krosing wrote:
> Ühel kenal päeval, N, 2007-02-15 kell 10:49, kirjutas Heikki
> Linnakangas:
>
> > We already log tuple removals by normal vacuums. We can't use that wal
> > entry as it is: if a dead tuple is in the middle of an update chain, it
> > needs
Joe Conway wrote:
> Bruce Momjian wrote:
> > Pavel Stehule wrote:
> >> Hello,
> >>
> >> I miss doc for this operator
> >
> > Strang IS [NOT] OF wasn't documented, especially seeing it was added
in
> > PostgreSQL 7.3. Anyway, documented and backpatched to 8.2.X.
>
> Here's the reason -- see this
On Monday 19 February 2007 11:27, Martijn van Oosterhout wrote:
> On Mon, Feb 19, 2007 at 05:10:36PM +0100, Dimitri Fontaine wrote:
> > > RAID and LVM too. I can't get excited about re-inventing those wheels
> > > when perfectly good implementations already exist for us to sit on top
> > > of.
> >
Reposting - looks like the message did not get through in the first
attempt. My apologies if multiple copies are received.
This is the next version of the HOT WIP patch. Since the last patch that
I sent out, I have implemented the HOT-update chain pruning mechanism.
When following a HOT-update
On Monday 19 February 2007 15:08, Bruce Momjian wrote:
> Joshua D. Drake wrote:
> > Andrew Sullivan wrote:
> > > On Mon, Feb 19, 2007 at 10:33:24AM -0500, Tom Lane wrote:
> > >> Martijn van Oosterhout writes:
> > >>> Somehow this seems like implementing RAID within postgres,
> > >>
> > >> RAID and
On Sat, 2007-02-17 at 12:48 -0500, Tom Lane wrote:
> Relcache inval casts a fairly wide net; for example, adding or dropping an
> index will invalidate all plans using the index's table whether or not
> they used that particular index, and I believe that VACUUM will also
> result in a relcache inv
Greg Smith <[EMAIL PROTECTED]> writes:
> The arguments for COPY are performance and that you don't need to specify
> the table name. INSERT is slower and you need a name, but it's easier to
> build a UNIX tool style pipeline to import it in real-time.
I can't believe that any production situati
Gregory Stark <[EMAIL PROTECTED]> writes:
> "Tom Lane" <[EMAIL PROTECTED]> writes:
>> Elements of arrays are not subject to being toasted by themselves, so
>> I don't think you can make that work. At least not without breaking
>> wide swaths of code that works fine today.
> You think it's more li
On 2/17/07, Joshua D. Drake <[EMAIL PROTECTED]> wrote:
My understanding is that the main difference is that rollbacks are
inexpensive for us, but expensive for Oracle.
Yes, Oracle is optimized for COMMIT, we're optimized for ROLLBACK :)
In all seriousness, last time I checked Oracle's MVCC was
On Mon, 19 Feb 2007, Tom Lane wrote:
Why is this still under discussion? I thought we'd agreed that COPY
format was the way to go.
Joshua Drake said "COPY would be a good option, but INSERT is probably
what I would use as the default. The most use I see for this is something
where I am tail
Greg Smith <[EMAIL PROTECTED]> writes:
> On Mon, 19 Feb 2007, Alvaro Herrera wrote:
>> Also, "sql" is not really a destination -- it is a format.
> A log file with a different name is another destination. eventlog is
> certainly a different format and it's sitting happily as an option there.
>
I have a WIP patch that adds the main detail I have found I need to
properly tune checkpoint and background writer activity. I think it's
almost ready to submit (you can see the current patch against 8.2 at
http://www.westnet.com/~gsmith/content/postgresql/patch-checkpoint.txt )
after making i
I am still waiting for a plpython patch that has Python version
checking.
---
Guido Goldstein wrote:
> Peter Eisentraut wrote:
> > Guido Goldstein wrote:
> >> Is it possible to tell me which python versions you want to
> >>
August Zajonc <[EMAIL PROTECTED]> writes:
> The key is how lightweight the setup could be, which matters because
> clients are not always willing to pay for a PITR setup. The low overhead
> would mean you'd feel fine about setting guc to 1hr or so.
This would have exactly the same performance cons
Greg Smith <[EMAIL PROTECTED]> writes:
> A workable syntax might be
> INSERT INTO "pg_log" ...
Why is this still under discussion? I thought we'd agreed that COPY
format was the way to go.
regards, tom lane
---(end of broadcast)---
On Mon, Feb 19, 2007 at 02:50:34PM -0500, Andrew Sullivan wrote:
> On Mon, Feb 19, 2007 at 10:33:24AM -0500, Tom Lane wrote:
> > Martijn van Oosterhout writes:
> > > Somehow this seems like implementing RAID within postgres,
> >
> > RAID and LVM too. I can't get excited about re-inventing those
I think I'll go with Tom's Plan B for HEAD, but not do anything more for
8.2 than has already been done.
cheers
andrew
Bruce Momjian wrote:
Did we come to a conclusion on this?
---
Andrew Dunstan wrote:
Andrew Du
Gregory Stark wrote:
If we could have autovacuum interrupt a vacuum in mid-sweep, perform a cycle
of vacuums on smaller tables, then resume, that problem would go away. That
sounds too difficult though, but perhaps we could do something nearly as good.
I think to make vacuum has this interrupt
Joe Conway wrote:
> Bruce Momjian wrote:
> > Pavel Stehule wrote:
> >> Hello,
> >>
> >> I miss doc for this operator
> >
> > Strang IS [NOT] OF wasn't documented, especially seeing it was added in
> > PostgreSQL 7.3. Anyway, documented and backpatched to 8.2.X.
>
> Here's the reason -- see this
Bruce Momjian wrote:
Pavel Stehule wrote:
Hello,
I miss doc for this operator
Strang IS [NOT] OF wasn't documented, especially seeing it was added in
PostgreSQL 7.3. Anyway, documented and backpatched to 8.2.X.
Here's the reason -- see this thread:
http://archives.postgresql.org/pgsql-patc
Pavel Stehule wrote:
> Hello,
>
> I miss doc for this operator
Strang IS [NOT] OF wasn't documented, especially seeing it was added in
PostgreSQL 7.3. Anyway, documented and backpatched to 8.2.X.
--
Bruce Momjian <[EMAIL PROTECTED]> http://momjian.us
EnterpriseDB
"Simon Riggs" <[EMAIL PROTECTED]> writes:
>> After looking over the code it seems that the executor needs a limited
>> subset of the Query fields, namely
>> ...
>> which I think we should put into a new TopPlan node type.
> All else sounds good, but why would we be caching a plan that used these
>
On Sun, 2007-02-18 at 18:19 -0500, Tom Lane wrote:
> While thinking about having a centralized plan cache for managing plan
> invalidation, I got annoyed again about the fact that the executor needs
> access to the Query tree. This means that we'll be storing *three*
> representations of any cache
Added to developer's FAQ:
src/Makefile.custom can be used to set environment variables,
like CUSTOM_COPT, that are used for every compile.
---
Magnus Hagander wrote:
> >> If we did what you suggest, then --enable-
On Mon, 2007-02-19 at 17:35 -0300, Alvaro Herrera wrote:
> Andrew Sullivan wrote:
> > On Mon, Feb 19, 2007 at 10:33:24AM -0500, Tom Lane wrote:
> > > Martijn van Oosterhout writes:
> > > > Somehow this seems like implementing RAID within postgres,
> > >
> > > RAID and LVM too. I can't get excite
Did we come to a conclusion on this?
---
Andrew Dunstan wrote:
> Andrew Dunstan wrote:
> >
> >
> > Tom Lane wrote:
> >> Andrew Dunstan <[EMAIL PROTECTED]> writes:
> >>
> >>> The consequence will be, though, that psql will
On Mon, 2007-02-19 at 19:38 +, Simon Riggs wrote:
> On Tue, 2007-02-13 at 22:19 -0500, Bruce Momjian wrote:
> > Simon Riggs wrote:
> > > On Thu, 2006-10-26 at 18:45 -0400, Tom Lane wrote:
> > > > Chris Campbell <[EMAIL PROTECTED]> writes:
> > > > > Is there additional logging information I can
Hi Tom,
> Hacking pg_control would be the hard part; you'll never get the CRC
> right if you do it manually. Possibly pg_resetxlog could be adapted
> to the purpose.
thanks for your valuable answer! I looked at pg_resetxlog.c but I'm no
pg internals' expert - would something like this work?
I have updated the PQfree documentation; patch attached. Backpatched
to 8.2.X.
---
Zeugswetter Andreas ADI SD wrote:
>
> > > future for some reason. (the doc for the other functions say you
> have to
> > > use PQfreemem w
Added to TODO:
* Consider allowing configuration of TOAST thresholds
http://archives.postgresql.org/pgsql-hackers/2007-02/msg00213.php
---
Simon Riggs wrote:
> On Mon, 2007-02-05 at 19:18 -0500, Jan Wieck wrote:
> > On 2
Added to TODO:
* Allow UPDATEs on only non-referential integrity columns not to
conflict
with referential integrity locks
http://archives.postgresql.org/pgsql-hackers/2007-02/msg00073.php
-
Andrew Sullivan wrote:
> On Mon, Feb 19, 2007 at 10:33:24AM -0500, Tom Lane wrote:
> > Martijn van Oosterhout writes:
> > > Somehow this seems like implementing RAID within postgres,
> >
> > RAID and LVM too. I can't get excited about re-inventing those wheels
> > when perfectly good implementat
On Mon, 19 Feb 2007, Alvaro Herrera wrote:
We already have a "combined GUC option" that is used to change two
different things (DateStyle) and I regularly see people confused about
how to use it.
You already have a combined GUC option called log_destination that's
sitting in the appropriate
On Mon, 19 Feb 2007 20:30:59 +0100, "Florian G. Pflug" <[EMAIL PROTECTED]>
said:
> August Zajonc wrote:
> > Gregory Stark wrote:
> >
> > Couldn't you define things simply to be that you get a consistent view
> > including all transactions started before x transaction? This is time
> > travel lite
Joshua D. Drake wrote:
> Andrew Sullivan wrote:
> > On Mon, Feb 19, 2007 at 10:33:24AM -0500, Tom Lane wrote:
> >> Martijn van Oosterhout writes:
> >>> Somehow this seems like implementing RAID within postgres,
> >> RAID and LVM too. I can't get excited about re-inventing those wheels
> >> when p
Added to TODO:
* Allow INSERT/UPDATE ... RETURNING inside a SELECT 'FROM' clause
http://archives.postgresql.org/pgsql-general/2006-09/msg00803.php
http://archives.postgresql.org/pgsql-hackers/2006-10/msg00693.php
--
On Mon, 19 Feb 2007, Joshua D. Drake wrote:
Longer than that... it supported mirroring and raid 5 in NT4 and
possibly even NT3.51 IIRC.
Mirroring and RAID 5 go back to Windows NT 3.1 Advanced Server in 1993:
http://support.microsoft.com/kb/114779
http://www.byte.com/art/9404/sec8/art7.htm
Th
Andrew Sullivan wrote:
> On Mon, Feb 19, 2007 at 10:33:24AM -0500, Tom Lane wrote:
>> Martijn van Oosterhout writes:
>>> Somehow this seems like implementing RAID within postgres,
>> RAID and LVM too. I can't get excited about re-inventing those wheels
>> when perfectly good implementations alrea
On Mon, Feb 19, 2007 at 10:33:24AM -0500, Tom Lane wrote:
> Martijn van Oosterhout writes:
> > Somehow this seems like implementing RAID within postgres,
>
> RAID and LVM too. I can't get excited about re-inventing those wheels
> when perfectly good implementations already exist for us to sit on
On Tue, 2007-02-13 at 22:19 -0500, Bruce Momjian wrote:
> Simon Riggs wrote:
> > On Thu, 2006-10-26 at 18:45 -0400, Tom Lane wrote:
> > > Chris Campbell <[EMAIL PROTECTED]> writes:
> > > > Is there additional logging information I can turn on to get more
> > > > details? I guess I need to see exa
Stefan Kaltenbrunner wrote:
> Peter Eisentraut wrote:
>> Tom Lane wrote:
>>> Martijn van Oosterhout writes:
Somehow this seems like implementing RAID within postgres,
>>> RAID and LVM too. I can't get excited about re-inventing those
>>> wheels when perfectly good implementations already exi
August Zajonc wrote:
Gregory Stark wrote:
"Zeugswetter Andreas ADI SD" <[EMAIL PROTECTED]> writes:
First we must run the query in serializable mode and replace
the snapshot with a synthetic one, which defines visibility
at the start of the desired transaction
We could use something that cont
Magnus Hagander wrote:
> Windows supports both RAID and LVM.
Oh good, so we've got that on record. :)
--
Peter Eisentraut
http://developer.postgresql.org/~petere/
---(end of broadcast)---
TIP 7: You can help support the PostgreSQL project by donat
On Mon, 19 Feb 2007, Guillaume Smet wrote:
Why not simply put something like %log_table% in the sql file and let
the admin replace it with sed or whatever he likes?
This is a reasonable approach. I would suggest that no special characters
be used though, so that the SQL could be used as-is b
Gregory Stark wrote:
> "Zeugswetter Andreas ADI SD" <[EMAIL PROTECTED]> writes:
>
>>> First we must run the query in serializable mode and replace
>>> the snapshot with a synthetic one, which defines visibility
>>> at the start of the desired transaction
>> We could use something that controls "
"Tom Lane" <[EMAIL PROTECTED]> writes:
> Gregory Stark <[EMAIL PROTECTED]> writes:
>> Once this is done it may be worth having arrays convert to short varlenas as
>> well.
>
> Elements of arrays are not subject to being toasted by themselves, so
> I don't think you can make that work. At least no
Peter Eisentraut wrote:
> Tom Lane wrote:
>> Martijn van Oosterhout writes:
>>> Somehow this seems like implementing RAID within postgres,
>> RAID and LVM too. I can't get excited about re-inventing those
>> wheels when perfectly good implementations already exist for us to
>> sit on top of.
>
>
Peter Eisentraut wrote:
> Tom Lane wrote:
>> Martijn van Oosterhout writes:
>>> Somehow this seems like implementing RAID within postgres,
>> RAID and LVM too. I can't get excited about re-inventing those
>> wheels when perfectly good implementations already exist for us to
>> sit on top of.
>
>
Tom Lane wrote:
> Martijn van Oosterhout writes:
> > Somehow this seems like implementing RAID within postgres,
>
> RAID and LVM too. I can't get excited about re-inventing those
> wheels when perfectly good implementations already exist for us to
> sit on top of.
I expect that someone will poin
Tom Lane wrote:
> SQL script maybe, much along the lines Greg was just mentioning.
I would welcome that, although a similar suggestion was rejected a few
years ago, which is why I didn't pursue it here.
> you can't just decide to leave out a few OIDs on the
> spur of the moment.
I still don't u
On 2/19/07, Alvaro Herrera <[EMAIL PROTECTED]> wrote:
If it adds necessary context then it clear does not have "the same
behavior",
I mean log_line_prefix behaviour is the same. The other information
are syslog specific.
I'd propose adding a log_entry_prefix separate from log_line_prefix; the
On Mon, Feb 19, 2007 at 01:28:46PM +0100, Lukas Kahwe Smith wrote:
> Hannu Krosing wrote:
> >Ãhel kenal päeval, L, 2007-02-17 kell 13:35, kirjutas Lukas Kahwe Smith:
> >>Lukas Kahwe Smith wrote:
> >>
> >>>I just wanted to bring up the wishlist todo items:
> >>>http://developer.postgresql.org/inde
Hi,
I started working again on my
IDENTITY/GENERATED patch.
My question is $SUBJECT.
This code is in rewriteTargetlist():
new_attr = build_column_default()
new_tle = makeTargetEntry((Expr *) new_expr, ...)
Now, in ExecInsert() I have to compute
the default for IDENTITY/GENERATED
between ExecCon
Guillaume Smet escribió:
> On 2/19/07, Alvaro Herrera <[EMAIL PROTECTED]> wrote:
> >Guillaume Smet escribió:
> >> On 2/19/07, Alvaro Herrera <[EMAIL PROTECTED]> wrote:
> >> >So add the session ID (%c) to log_line_prefix.
> >>
> >> It could work if log_line_prefix was added before every line but it'
On 2/19/07, Alvaro Herrera <[EMAIL PROTECTED]> wrote:
Guillaume Smet escribió:
> On 2/19/07, Alvaro Herrera <[EMAIL PROTECTED]> wrote:
> >So add the session ID (%c) to log_line_prefix.
>
> It could work if log_line_prefix was added before every line but it's
> definitely not the case:
> myuser my
Tom Lane wrote:
"Florian G. Pflug" <[EMAIL PROTECTED]> writes:
I'd suggest that the text is changed to something along the line of:
"database system was interrupted while in recovery at ...
If this has occurred more than once some data may be corrupted and
you may need to restore from the last b
Tom Lane wrote:
> Peter Eisentraut <[EMAIL PROTECTED]> writes:
> > Am Montag, 19. Februar 2007 13:12 schrieb Alvaro Herrera:
> >> I don't understand -- what problem you got with "NO OPERATION"? It
> >> seemed a sound idea to me.
>
> > It seems nonorthogonal. What if only some of the tables you m
Peter Eisentraut wrote:
> Am Montag, 19. Februar 2007 16:50 schrieb Tom Lane:
> > Well, in the first place Gen_fmgrtab.sh is producing garbage:
>
> Uh, ok, that needs fixing.
>
> > In the second place, if you don't want to predetermine OIDs for your
> > functions then they shouldn't be in hardwir
On Mon, Feb 19, 2007 at 05:10:36PM +0100, Dimitri Fontaine wrote:
> > RAID and LVM too. I can't get excited about re-inventing those wheels
> > when perfectly good implementations already exist for us to sit on top of.
>
> I though moving some knowledge about data availability into PostgreSQL cod
Dimitri Fontaine <[EMAIL PROTECTED]> writes:
> You're both saying RAID/LVM implementations provide good enough performances
> for PG not having to go this way, if I understand correctly.
There's certainly no evidence to suggest that reimplementing them
ourselves would be a productive use of our t
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Mon, Feb 19, 2007 at 04:00:09PM +0100, Florian G. Pflug wrote:
[...]
> In the long run, you'd probably want to store the commit-times of
> transactions somewhere, and add some guc that makes a vacuum assume
> that recently comitted transaction (say
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> Am Montag, 19. Februar 2007 16:50 schrieb Tom Lane:
>> In the second place, if you don't want to predetermine OIDs for your
>> functions then they shouldn't be in hardwired pg_proc.h rows at all.
> Where else would you put them?
SQL script maybe, muc
Am Montag, 19. Februar 2007 16:50 schrieb Tom Lane:
> Well, in the first place Gen_fmgrtab.sh is producing garbage:
Uh, ok, that needs fixing.
> In the second place, if you don't want to predetermine OIDs for your
> functions then they shouldn't be in hardwired pg_proc.h rows at all.
Where else
Le lundi 19 février 2007 16:33, Tom Lane a écrit :
> Martijn van Oosterhout writes:
> > Somehow this seems like implementing RAID within postgres,
>
> RAID and LVM too. I can't get excited about re-inventing those wheels
> when perfectly good implementations already exist for us to sit on top of.
"Tom Lane" <[EMAIL PROTECTED]> writes:
> In the second place, if you don't want to predetermine OIDs for your
> functions then they shouldn't be in hardwired pg_proc.h rows at all.
Is there any place to hook in to create things like procedures or other SQL
objects that don't really need hard code
On 2/19/07, Oleg Bartunov wrote:
You need to wait GiN support.
OK. Thanks.
If you need testers for this one, feel free to contact me. I'm very
interested in testing pg_trgm in conjunction with tsearch2.
--
Guillaume
---(end of broadcast)---
TI
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> Am Montag, 19. Februar 2007 16:26 schrieb Tom Lane:
>> Peter Eisentraut <[EMAIL PROTECTED]> writes:
>>> Am Montag, 19. Februar 2007 10:16 schrieb Magnus Hagander:
This breaks the fmgrtab generator on msvc.
>>
>>> It's intentional.
>>
>> Kindly ch
Am Montag, 19. Februar 2007 15:57 schrieb Tom Lane:
> The precedent that I'm thinking about is that the command tag for COMMIT
> varies depending on what it actually did.
Some have also argued against that in the past, so I guess we just have
different ideas of how it should work. Not a problem.
Am Montag, 19. Februar 2007 16:26 schrieb Tom Lane:
> Peter Eisentraut <[EMAIL PROTECTED]> writes:
> > Am Montag, 19. Februar 2007 10:16 schrieb Magnus Hagander:
> >> This breaks the fmgrtab generator on msvc. Most likely because I didn't
> >> think of that case. But since all other rows in pg_proc
Martijn van Oosterhout writes:
> Somehow this seems like implementing RAID within postgres,
RAID and LVM too. I can't get excited about re-inventing those wheels
when perfectly good implementations already exist for us to sit on top of.
regards, tom lane
---
Gregory Stark <[EMAIL PROTECTED]> writes:
> Once this is done it may be worth having arrays convert to short varlenas as
> well.
Elements of arrays are not subject to being toasted by themselves, so
I don't think you can make that work. At least not without breaking
wide swaths of code that works
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> Am Montag, 19. Februar 2007 10:16 schrieb Magnus Hagander:
>> This breaks the fmgrtab generator on msvc. Most likely because I didn't
>> think of that case. But since all other rows in pg_proc.h contain the
>> oid, I just wanted to check if they're act
Martijn van Oosterhout writes:
>> But I guess something like this would work:
>> 1) drop all indexes on text/varchar columns
>> 2) change cluster locale
>> 3) create all indexes on text/varchar columns
> You're going to miss the "name" columns, ie. every string index in
> pg_catalog.
But "name"
"Zeugswetter Andreas ADI SD" <[EMAIL PROTECTED]> writes:
>> First we must run the query in serializable mode and replace
>> the snapshot with a synthetic one, which defines visibility
>> at the start of the desired transaction
>
> We could use something that controls "global xmin".
> It would e
On 2/19/07, Tom Lane <[EMAIL PROTECTED]> wrote:
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> Am Montag, 19. Februar 2007 13:12 schrieb Alvaro Herrera:
>> I don't understand -- what problem you got with "NO OPERATION"? It
>> seemed a sound idea to me.
> It seems nonorthogonal. What if only s
"Dawid Kuroczko" <[EMAIL PROTECTED]> writes:
> ... Now, assuming UNIQUE INDEX on such table, the order would be preserved
> since no two intervals can overlap. And no overlapping data could be inserted
> without breaking "ovelapivity". And of course non-unique index would
> produce garbage (since
On Sat, Feb 17, 2007 at 01:28:22PM -0500, Tom Lane wrote:
> Magnus Hagander <[EMAIL PROTECTED]> writes:
> > I'd also like a comment from at least one other "patch reviewer" that
> > the methods used are good.
>
> It looks reasonable as far as it goes. One thought is that pg_dump
> really should h
On Mon, 19 Feb 2007, Guillaume Smet wrote:
On 2/19/07, Oleg Bartunov wrote:
pg_trgm was developed for spelling corrrection and there is a threshold of
similarity, which is 0.3 by default. Readme explains what does it means.
Yes, I read it.
Similarity could be very low, since you didn't make
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> Am Montag, 19. Februar 2007 13:12 schrieb Alvaro Herrera:
>> I don't understand -- what problem you got with "NO OPERATION"? It
>> seemed a sound idea to me.
> It seems nonorthogonal. What if only some of the tables you mentioned did
> not
> exist
Zeugswetter Andreas ADI SD wrote:
First we must run the query in serializable mode and replace the
snapshot with a synthetic one, which defines visibility at the
start
of the desired transaction
probably it is a good idea to take a lock on all tables involved to
avoid a vacuum to be started
> > >First we must run the query in serializable mode and replace the
> > >snapshot with a synthetic one, which defines visibility at the
start
> > >of the desired transaction
> > >
> > >probably it is a good idea to take a lock on all tables involved to
> > >avoid a vacuum to be started on the
> > Well this is certainly interesting. What do we think it
> would take to
> > enable the functionality?
>
> First we must run the query in serializable mode and replace
> the snapshot with a synthetic one, which defines visibility
> at the start of the desired transaction
We could use some
Florian G. Pflug escribió:
> Hannu Krosing wrote:
> >Ühel kenal päeval, P, 2007-02-18 kell 14:27, kirjutas Joshua D. Drake:
> >>Hannu Krosing wrote:
> >>>Ühel kenal päeval, L, 2007-02-17 kell 22:49, kirjutas Chad Wagner:
> >>>To get a flashback query, you "just" have to construct a snapshot from
>
Hannu Krosing wrote:
Ühel kenal päeval, P, 2007-02-18 kell 14:27, kirjutas Joshua D. Drake:
Hannu Krosing wrote:
Ühel kenal päeval, L, 2007-02-17 kell 22:49, kirjutas Chad Wagner:
To get a flashback query, you "just" have to construct a snapshot from
that time and you are done. We don't store t
Am Montag, 19. Februar 2007 13:12 schrieb Alvaro Herrera:
> I don't understand -- what problem you got with "NO OPERATION"? It
> seemed a sound idea to me.
It seems nonorthogonal. What if only some of the tables you mentioned did not
exist? Do you get "SOME OPERATION"?
There are also other ca
Ühel kenal päeval, P, 2007-02-18 kell 14:27, kirjutas Joshua D. Drake:
> Hannu Krosing wrote:
> > Ühel kenal päeval, L, 2007-02-17 kell 22:49, kirjutas Chad Wagner:
> >
> >>
> >> However, they don't have vacuum, we do.
> >>
> >> Right, and I think that is more or less because Oracle doesn'
Hannu Krosing wrote:
Ühel kenal päeval, L, 2007-02-17 kell 13:35, kirjutas Lukas Kahwe Smith:
Lukas Kahwe Smith wrote:
I just wanted to bring up the wishlist todo items:
http://developer.postgresql.org/index.php/Todo:WishlistFor83
What does/did the row "Clustered/replication solutions" refer
Ühel kenal päeval, L, 2007-02-17 kell 13:35, kirjutas Lukas Kahwe Smith:
> Lukas Kahwe Smith wrote:
>
> > I just wanted to bring up the wishlist todo items:
> > http://developer.postgresql.org/index.php/Todo:WishlistFor83
What does/did the row "Clustered/replication solutions" refer to ?
--
--
Bruce Momjian wrote:
> Tom Lane wrote:
> > "Jim C. Nasby" <[EMAIL PROTECTED]> writes:
> > > On Thu, Feb 08, 2007 at 01:54:13PM -0500, Tom Lane wrote:
> > >> I would be satisfied if the returned command tag were something else,
> > >> maybe "NO OPERATION".
> >
> > > "TABLE blah DID NOT EXIST" might
On Mon, Feb 19, 2007 at 11:25:41AM +0100, Dimitri Fontaine wrote:
> Hi list,
>
> Here's a proposal of this idea which stole a good part of my night.
> I'll present first the idea, then 2 use cases where to read some rational and
> few details. Please note I won't be able to participate in any dev
> One option that I've heard before is to have vacuum after a single iteration
> (ie, after it fills maintenance_work_mem and does the index cleanup and the
> second heap pass), remember where it was and pick up from that point next
> time.
>From my experience this is not acceptable... I have tabl
On Mon, Feb 19, 2007 at 11:25:02AM +0100, Peter Eisentraut wrote:
> Am Montag, 19. Februar 2007 10:16 schrieb Magnus Hagander:
> > This breaks the fmgrtab generator on msvc. Most likely because I didn't
> > think of that case. But since all other rows in pg_proc.h contain the
> > oid, I just wanted
On 17/02/07, Warren Turkal <[EMAIL PROTECTED]> wrote:
PERIOD(INT) is actually listed in the Dr. Snodgrass's book. However, I am not
really sure about the semantics of the type. When would you use a
PERIOD(INT)?
It wouldn't be directly useful for temporal SQL, but I have a number
of tables in a
Hi list,
Here's a proposal of this idea which stole a good part of my night.
I'll present first the idea, then 2 use cases where to read some rational and
few details. Please note I won't be able to participate in any development
effort associated with this idea, may such a thing happen!
The ba
I had intended to make varlenas alignment 'c' and have the heaptuple.c force
them to alignment 'i' if they required it. However I've noticed a problem that
makes me think I should do this the other way around.
The problem is that other places in the codebase use the alignment. In
particular array
On 2/19/07, Oleg Bartunov wrote:
pg_trgm was developed for spelling corrrection and there is a threshold of
similarity, which is 0.3 by default. Readme explains what does it means.
Yes, I read it.
Similarity could be very low, since you didn't make separate column and length
of the full stri
Am Montag, 19. Februar 2007 10:16 schrieb Magnus Hagander:
> This breaks the fmgrtab generator on msvc. Most likely because I didn't
> think of that case. But since all other rows in pg_proc.h contain the
> oid, I just wanted to check if they're actually supposed to be withuot
> oid, or if that was
1 - 100 of 107 matches
Mail list logo
