On Wed, Jan 21, 2009 at 11:09 AM, Peter Eisentraut wrote:
> Here is my latest reworked patch that fixes all outstanding issues.
>
>
1) there's a regression failure, it's just a message that changes...
attached regression.diffs
2) this comment on
src/backend/rewrite/viewUpdate.c:form_where_for_up
Simon Riggs wrote:
Without the patch it is completely *impossible* to write an index plugin
that is *recoverable*.
It's also impossible to do many other things without modifying the
source code. Bitmap indexam had to do it, my clustered indexes had to do
it, GIN had to do it.
Yes, we have
On Wed, 2009-01-21 at 15:08 -0800, Jeff Davis wrote:
> If we keep the permission check in LockTableCommand(), I can make a
> patch that produces a more useful error message when the table is
> removed right before the pg_class_aclcheck().
Attached.
Regards,
Jeff Davis
diff --git a/src/bac
2009/1/22 Bruce Momjian :
> Nikhil Sontakke wrote:
>> > > PFA, patch which uses find_coercion_pathway to find a direct
>> > > COERCION_PATH_FUNC function and uses that if it is available. Or is there
>> > a
>> > > better approach? Seems to handle the above issue with this patch.
>> >
>> > +1
>> >
>
> I am curious. I read this whole current thread. What is "wrong" with the
> patch? As I understand it it does not increase complexity. It appears to
> only expose (or perhaps abstract?) existing functionality into a usable
> API that is not dependent on something being in core.
>
> Imagine if at s
On Wed, 2009-01-21 at 17:49 +, Simon Riggs wrote:
> On Wed, 2009-01-21 at 18:24 +0200, Heikki Linnakangas wrote:
> Bruce Lindsay, IBM Fellow and long term DB guru was interviewed in 2005:
> Q: If you magically had enough extra time to do one additional thing at
> work that you're not doing now
Here's a shot at a more radical revision, to try to address concerns
raised over my failure in the previous (very minimal) suggested patch
to address PostgreSQL behavior close to where the spec's behavior is
described, and my dragging in of language directly from the spec in a
confusing context. I
Latest patch is attached. Changed as discussed to issue TRUNCATE ...
ONLY when talking to servers >= 8.4 instead of plain TRUNCATE.
cheers
andrew
parallel_restore_15.patch.gz
Description: GNU Zip compressed data
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make
Bruce, et al,
* Bruce Momjian (br...@momjian.us) wrote:
> \dg [PATTERN]list roles (groups)
> \du [PATTERN]list roles (users)
Seeing this list reminded me of a pet-peeve.. \du and \dg actually show
the same info, that's fine, but neither of them show the rolcanlo
* Robert Haas (robertmh...@gmail.com) wrote:
> > Here are the items I think are best to default to user-only:
> [...]
> > Here are the ones that should include system objects by default:
[...]
> So maybe we should provide U, S, and A modifiers for every type of
> object (user, system, all). That d
Tom Lane wrote:
> Heikki Linnakangas writes:
> > Tom Lane wrote:
> >> We could attack this by including source database's encoding in the
> >> shared-memory entries, and performing a conversion on the fly when
> >> reading out the data. However, what happens if the conversion fails?
>
> > The mo
Alvaro Herrera wrote:
> Robert Treat wrote:
> > On Thursday 08 May 2008 00:27:10 Tino Wildenhain wrote:
> > > David Fetter wrote:
>
> Ref: http://archives.postgresql.org/pgsql-hackers/2008-05/msg00198.php
>
> > > > 1. Create a generic (possibly overloaded) trigger function, bundled
> > > > with
On Wed, 2009-01-21 at 17:46 -0600, Kevin Grittner wrote:
> >>> Bruce Momjian wrote:
> > It is cost vs. benefit. No one is saying plugabiity is bad, only
> that
> > in this case it is more costly than beneficial
>
> Just curious -- are we talking execution time costs or programming
> costs beca
On Thu, 2009-01-22 at 00:00 +, Gregory Stark wrote:
> But note that the interface is critical.
Yes, it is.
The existing rmgr code provides for 5 separate calls that a module needs
to implement to make an access method recoverable. btree, hash, gist and
gin already implement that API.
I hav
Heikki Linnakangas wrote:
> Simon Riggs wrote:
> > On Fri, 2009-01-09 at 16:14 +0200, Peter Eisentraut wrote:
> >> Simon Riggs wrote:
> >>> I notice that we allow commands such as
> >>>
> >>> SET TRANSACTION read only read write read only;
> >>>
> >>> BEGIN TRANSACTION read only read only read only
Simon Riggs wrote:
>
> On Wed, 2009-01-21 at 18:06 -0500, Bruce Momjian wrote:
>
> > Plugability adds complexity. Heikki's comment is that adding this
> > patch make the job of creating pluggable indexes 5% easier, while no
> > one is actually working on plugable indexes, and it hard to say that
On Wed, 2009-01-21 at 18:06 -0500, Bruce Momjian wrote:
> Plugability adds complexity. Heikki's comment is that adding this
> patch make the job of creating pluggable indexes 5% easier, while no
> one is actually working on plugable indexes, and it hard to say that
> making it 5% easier really ad
Robert Haas wrote:
> > I am not thrilled about inventing a new column for this, but how about
> > a display like so:
> >
> > regression=# \df nth_value
> >List of functions
> > Schema | Name| Result data type | Argument data types
> > +---
Josh Berkus writes:
> Right. And I'm saying that pluggability is PostgreSQL's main reason for
> existence, if you look at our place in the future of databases. So it's worth
> paying *some* cost, provided that the cost/benefit ratio works for the
> particular patch.
I agree that pluggability i
Nikhil Sontakke wrote:
> > > PFA, patch which uses find_coercion_pathway to find a direct
> > > COERCION_PATH_FUNC function and uses that if it is available. Or is there
> > a
> > > better approach? Seems to handle the above issue with this patch.
> >
> > +1
> >
> > I thing, so some values should b
Tom Lane wrote:
> According to SQL2008 section 7.11 , general rule 5, the
> default definition of window framing in a window that has an ordering
> clause but no framing (RANGE/ROWS) clause is that the window frame for
> a given row R runs from the first row of its partition through the last
> peer
Kevin Grittner wrote:
> >>> Bruce Momjian wrote:
> > It is cost vs. benefit. No one is saying plugabiity is bad, only
> that
> > in this case it is more costly than beneficial
>
> Just curious -- are we talking execution time costs or programming
> costs because of increased code complexity?
P
>>> Bruce Momjian wrote:
> It is cost vs. benefit. No one is saying plugabiity is bad, only
that
> in this case it is more costly than beneficial
Just curious -- are we talking execution time costs or programming
costs because of increased code complexity?
-Kevin
--
Sent via pgsql-hackers m
Josh Berkus wrote:
> Bruce,
>
> > Plugability adds complexity. Heikki's comment is that adding this patch
> > make the job of creating pluggable indexes 5% easier, while no one is
> > actually working on plugable indexes, and it hard to say that making it
> > 5% easier really advances anything, es
Bruce,
Plugability adds complexity. Heikki's comment is that adding this patch
make the job of creating pluggable indexes 5% easier, while no one is
actually working on plugable indexes, and it hard to say that making it
5% easier really advances anything, especially since many of our
existing i
On Wed, 2009-01-21 at 17:39 -0500, Bruce Momjian wrote:
> > It looks like it would be easy enough to throw a better error message
> > than that, e.g. with a try/catch. The information could be obsolete, but
> > if it succeeds, it would at least mean they had permissions at some time
> > in the past
Josh Berkus wrote:
> All,
>
> I really don't see why we would object to making *anything* pluggable if
> someone was willing to write the code to do so. For example, making
> storage pluggable would allow PostgreSQL to achieve great new things on
> new types of hardware. (yes, I have some idea
All,
I really don't see why we would object to making *anything* pluggable if
someone was willing to write the code to do so. For example, making
storage pluggable would allow PostgreSQL to achieve great new things on
new types of hardware. (yes, I have some idea how difficult this would be)
On Thu, 2009-01-22 at 00:29 +0300, Oleg Bartunov wrote:
> I'm rather keen on Pg extendability, which allowed me and Teodor to
> work on many extensions. Yes, first GiST we inherited from early
> academic research and was more like a toy. We still have several TODO
> items about GiST interface
Jeff Davis wrote:
> On Tue, 2008-12-23 at 08:48 -0500, Tom Lane wrote:
> > I've always thought that it was extremely shaky for LOCK to try to work
> > that way. With no lock, you have no confidence that the table isn't
> > changing or disappearing under you. In the worst case, the permissions
> >
On Wed, 21 Jan 2009, Simon Riggs wrote:
On Wed, 2009-01-21 at 21:45 +0200, Heikki Linnakangas wrote:
Ron Mayer wrote:
Early (2005)
GIST indexes were very painful in production environments because vacuuming
them held locks for a *long* time (IIRC, an hour or so on my database) on
the indexes
Joshua D. Drake wrote:
> On Wed, 2009-01-21 at 15:46 -0500, Bruce Momjian wrote:
> > Simon Riggs wrote:
> > >
> > > On Wed, 2009-01-21 at 15:22 -0500, Bruce Momjian wrote:
> > > > Added to TODO:
> > > >
> > > > Allow administrators to cancel multi-statement idle
> > > > tr
Heikki Linnakangas wrote:
> Emmanuel Cecchet wrote:
> > I just saw that this new patch was not considered because the previous
> > version ended being rejected.
> > Note that this version of the patch aims at supporting ONLY temp tables
> > that are created AND dropped in the same transaction. We
On Wed, 2009-01-21 at 15:46 -0500, Bruce Momjian wrote:
> Simon Riggs wrote:
> >
> > On Wed, 2009-01-21 at 15:22 -0500, Bruce Momjian wrote:
> > > Added to TODO:
> > >
> > > Allow administrators to cancel multi-statement idle
> > > transactions
> > >
> > > This allows locks to be r
A hash join modification patch is under review for 8.4 that needs
performance testing. We would appreciate help with this testing.
A testing version of the patch is attached in addition to testing
instructions and where to retrieve a sample data set. The basic idea
of the patch is that it
On Wed, Jan 21, 2009 at 2:02 PM, Robert Haas wrote:
> >>> Was there a reason that this cleanup patch wasn't applied?
> >>
> >> 1. It was submitted after the deadline for CommitFest:November.
> >
> > Well, it's just comment changes...
>
> Oh, didn't realize that. That's what I get for replying wi
Simon Riggs wrote:
>
> On Wed, 2009-01-21 at 15:22 -0500, Bruce Momjian wrote:
> > Added to TODO:
> >
> > Allow administrators to cancel multi-statement idle
> > transactions
> >
> > This allows locks to be released, but it is complex to report the
> > cancellatio
On Wed, 2009-01-21 at 15:22 -0500, Bruce Momjian wrote:
> Added to TODO:
>
> Allow administrators to cancel multi-statement idle
> transactions
>
> This allows locks to be released, but it is complex to report the
> cancellation back to the client.
>
On Wed, 2009-01-21 at 21:45 +0200, Heikki Linnakangas wrote:
> Ron Mayer wrote:
> > Early (2005)
> > GIST indexes were very painful in production environments because vacuuming
> > them held locks for a *long* time (IIRC, an hour or so on my database) on
> > the indexes locking out queries. Was t
On Wed, 2009-01-21 at 19:13 +0200, Heikki Linnakangas wrote:
> > You don't want pluggable indexes, don't use 'em. But that isn't an
> > argument against allowing the capability for others. That line of
> > thought would have led us to banning pluggable languages. We should
> > respect the roots o
Added to TODO:
Allow administrators to cancel multi-statement idle
transactions
This allows locks to be released, but it is complex to report the
cancellation back to the client.
*
http://archives.postgresql.org/pg
Martin Pihlak escribió:
> Alvaro Herrera wrote:
> > I agree that pgstats is not ideal (we've said this from the very
> > beginning), but I doubt that updating pg_class is the answer; you'd be
> > generating thousands of dead tuples there.
>
> But we already do update pg_class after vacuum -- in va
> Here are the items I think are best to default to user-only:
[...]
> Here are the ones that should include system objects by default:
Well, at a minimum, I think it's important for any type of object to
have an easy way to exclude system objects, because "show me all of
the stuff that didn't com
Ron Mayer wrote:
Early (2005)
GIST indexes were very painful in production environments because vacuuming
them held locks for a *long* time (IIRC, an hour or so on my database) on
the indexes locking out queries. Was that just a shortcoming of the
implementation, or was it a side-effect of them
Alvaro Herrera wrote:
> I agree that pgstats is not ideal (we've said this from the very
> beginning), but I doubt that updating pg_class is the answer; you'd be
> generating thousands of dead tuples there.
>
But we already do update pg_class after vacuum -- in vac_update_relstats().
Hmm, that pe
Gregory Stark wrote:
> Simon Riggs writes:
>
>> The original design of Postgres allowed pluggable index access methods,
>> but that capability has not been brought forward to allow for WAL. This
>> patch would bridge that gap.
>
> Well I think what people do is what GIST did early on -- they jus
Alvaro Herrera wrote:
> Bruce Momjian escribi?:
> > Alvaro Herrera wrote:
> > > Bruce Momjian escribi?:
> > >
> > > > Well, to do this you are going to need 'U' and 'S' modifiers, and then
> > > > we have to decide how \df is supposed to behave.
> > >
> > > I think we should have first decided ho
Bruce Momjian escribió:
> Alvaro Herrera wrote:
> > Bruce Momjian escribi?:
> >
> > > Well, to do this you are going to need 'U' and 'S' modifiers, and then
> > > we have to decide how \df is supposed to behave.
> >
> > I think we should have first decided how it was supposed to behave, and
> > l
>>> Was there a reason that this cleanup patch wasn't applied?
>>
>> 1. It was submitted after the deadline for CommitFest:November.
>
> Well, it's just comment changes...
Oh, didn't realize that. That's what I get for replying without
reading the patch...
...Robert
--
Sent via pgsql-hackers m
Alvaro Herrera wrote:
> Bruce Momjian escribi?:
>
> > Well, to do this you are going to need 'U' and 'S' modifiers, and then
> > we have to decide how \df is supposed to behave.
>
> I think we should have first decided how it was supposed to behave, and
> later applied any patches.
Well, there w
Bruce Momjian escribió:
> Well, to do this you are going to need 'U' and 'S' modifiers, and then
> we have to decide how \df is supposed to behave.
I think we should have first decided how it was supposed to behave, and
later applied any patches.
--
Alvaro Herrera
Alvaro Herrera wrote:
> Bruce Momjian escribi?:
>
> > But frankly, with a very complex backslash API that is already
> > overloaded, I figured having a consistent 'S' to include system objects
> > was the best we are going to be able to do. Once this is out in the
> > field we might get new ideas
Alvaro Herrera escribió:
> The only possible gripe I have is that the grammar in the second hunk
> seems strange or broken, but maybe it's just that I don't know the
> language enough.
Oh, it makes sense if you consider "states" as a noun rather than a verb.
--
Alvaro Herrera
Heikki Linnakangas escribió:
> (I haven't checked whether the comment changes are a good idea. But they
> probably are..)
The original comments are broken, the new ones seem good. I think this
patch should just be applied. The only possible gripe I have is that
the grammar in the second hunk
Robert Haas wrote:
On Wed, Jan 21, 2009 at 6:17 AM, Jonah H. Harris wrote:
On Thu, Nov 6, 2008 at 12:03 AM, Jonah H. Harris
wrote:
As I wasn't sure whether anyone agrees with my distaste for
repurposing tgenabled as mentioned above, I have attached is a patch
which minimally corrects the func
Alvaro Herrera wrote:
Martin Pihlak escribió:
Alvaro Herrera wrote:
You missed putting back the BUG comment that used to be there about
this.
This was deliberate, I did mention the condition in the comment at
the beginning of the file. This actually makes it a feature :)
Seriously though, do
Bruce Momjian escribió:
> But frankly, with a very complex backslash API that is already
> overloaded, I figured having a consistent 'S' to include system objects
> was the best we are going to be able to do. Once this is out in the
> field we might get new ideas.
I don't buy this argument. If
On Wed, 2009-01-21 at 15:06 +0300, Teodor Sigaev wrote:
> Done. Now GIN counts number of pending tuples and pages and stores they on
> metapage. Index cleanup could start during normal insertion in two cases:
> - number of pending tuples is too high to keep guaranteed non-lossy tidbitmap
> - pendi
On Wed, Jan 21, 2009 at 6:17 AM, Jonah H. Harris wrote:
> On Thu, Nov 6, 2008 at 12:03 AM, Jonah H. Harris
> wrote:
>>
>> As I wasn't sure whether anyone agrees with my distaste for
>> repurposing tgenabled as mentioned above, I have attached is a patch
>> which minimally corrects the function co
On Wed, 2009-01-21 at 19:13 +0200, Heikki Linnakangas wrote:
> Simon Riggs wrote:
> > Why do we have 12+ pluggable languages, but we're not allowed to write
> > pluggable indexes? Whatever argument you put against it being "too hard"
> > or dangerous or whatever *also* applies to languages. Yet ex
FYI, I tested your query in 8.3.X CVS and it worked so this fix will in
the next 8.3 minor release.
---
Corey Horton wrote:
> Is there any known workaround to get this the elements of the
> histogram_bounds anyarray in 8.3.
On Wed, 2009-01-21 at 18:38 +0200, Heikki Linnakangas wrote:
> Simon Riggs wrote:
> > So you *must* replay catalog entries and recreate the original catalog
> > in exact synchronisation with reading WAL files. Recreating the catalog
> > can only be done by Postgres itself.
>
> The startup process
Peter Eisentraut wrote:
> On Friday 16 January 2009 04:09:11 Robert Haas wrote:
> > I really wonder what is so terrible about the behavrior as implemented
> > in CVS HEAD. ?AFAICS, no one except maybe Tom has really specified WHY
> > they don't like it, just that they don't like it. ?I'm not sure
>
On Wed, 2009-01-21 at 18:24 +0200, Heikki Linnakangas wrote:
> If we allow them to develop as separate projects, then whenever they
> are ready they can be used with particular releases.
> Developing a new indexam is not something you do over the weekend.
> It's a long way from design to an impl
None of this is Any of My Business any more, but
On Wed, Jan 21, 2009 at 03:44:15PM +, Simon Riggs wrote:
> The patch takes special care to allow calls to the rmgr functions only
> from the startup process. The APIs are exactly like the indexams and
> *are* called only in specific ways, at sp
On Friday 16 January 2009 04:09:11 Robert Haas wrote:
> I really wonder what is so terrible about the behavrior as implemented
> in CVS HEAD. AFAICS, no one except maybe Tom has really specified WHY
> they don't like it, just that they don't like it. I'm not sure
> whether that's because (1) it's
Simon Riggs wrote:
Why do we have 12+ pluggable languages, but we're not allowed to write
pluggable indexes? Whatever argument you put against it being "too hard"
or dangerous or whatever *also* applies to languages. Yet experience
shows pluggability has resulted in a variety of robust and useful
Heikki Linnakangas wrote:
> Simon Riggs wrote:
> > Right now we've got a variety of index types that are *not* flourishing
> > (hash, bitmap, grouped).
>
> Hash indexam has been in core for ages, and yet no-one has bothered to
> implement WAL logging. If I've understood correctly, it has been now
Simon Riggs wrote:
So you *must* replay catalog entries and recreate the original catalog
in exact synchronisation with reading WAL files. Recreating the catalog
can only be done by Postgres itself.
The startup process doesn't have a relcache, so this rmgr patch is
nowhere near enough to enabl
On Wed, 2009-01-21 at 16:07 +, Gregory Stark wrote:
>
> > The plugin approach was suggested because it brings together so many
> use cases in one and adds missing robustness to a case where we
> already have extensibility. Extensibility is about doing things for
> specific implementations *wi
Martin Pihlak escribió:
> Alvaro Herrera wrote:
> > You missed putting back the BUG comment that used to be there about
> > this.
>
> This was deliberate, I did mention the condition in the comment at
> the beginning of the file. This actually makes it a feature :)
>
> Seriously though, do you th
Simon Riggs wrote:
Right now we've got a variety of index types that are *not* flourishing
(hash, bitmap, grouped).
Hash indexam has been in core for ages, and yet no-one has bothered to
implement WAL logging. If I've understood correctly, it has been now
been revamped in 8.4 so that there's
Alvaro Herrera wrote:
> You missed putting back the BUG comment that used to be there about
> this.
>
This was deliberate, I did mention the condition in the comment at
the beginning of the file. This actually makes it a feature :)
Seriously though, do you think that this is still a problem? Giv
Gregory Stark wrote:
But to do that we need an abstract interface that doesn't depend on internal
data structures, not a generic plugin facility that allows the plugin to
hijack the whole system.
We need something more like indexams which provides a set of call points which
do specific functions
Robert Treat wrote:
On Friday 16 January 2009 19:16:42 Simon Riggs wrote:
Bruce asked for 2 more weeks to get patches into shape for commit.
Current patch v8e is attached here. Ready for commit? Up to you.
My overall opinion is that it's in very good shape. Worth the community
including it
Here is my latest reworked patch that fixes all outstanding issues.
view_update-petere-20090121.patch.bz2
Description: Binary data
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Simon Riggs writes:
> On Wed, 2009-01-21 at 14:28 +, Greg Stark wrote:
>
>> The only advantage that remains, I think, is the real-world concern
>> that you can have proprietary plugins
>
> ** I have no plans for selling software that has been enabled by this
> patch. **
Hm, I didn't specif
Tom Lane wrote:
> Magnus Hagander writes:
As for -c, the solution would be to issue DROP IF EXISTS
statements. Is there any particular reason why we don't?
>>> I think we did that to avoid damaging portability and backwards
>>> compatibility of the dump files. The backwards compatibil
Peter Eisentraut wrote:
On Monday 19 January 2009 23:22:21 Todd A. Cook wrote:
The docs at
http://developer.postgresql.org/pgdocs/postgres/functions-aggregate.html
don't prohibit using array values with array_arg(), so I assumed that it
would work.
test=> select array_agg(v.a) from (values (a
Magnus Hagander wrote:
Peter Eisentraut wrote:
Magnus Hagander wrote:
However, one question: The comment currently says it's harmless to do
this on non-windows platforms. Does this still hold true?
Yes, the non-WIN32 code path appears to be the same, still. But the
ifdef WIN32 part we don't w
On Wed, 2009-01-21 at 14:57 +, Gregory Stark wrote:
> But to do that we need an abstract interface that doesn't depend on
> internal data structures, not a generic plugin facility that allows
> the plugin to hijack the whole system.
>
> We need something more like indexams which provides a se
On Wed, 2009-01-21 at 14:28 +, Greg Stark wrote:
> The only advantage that remains, I think, is the real-world concern
> that you can have proprietary plugins
How exactly is this plugin more likely to result in a proprietary plugin
than all of the other plugin types we have? Because I sugge
I wrote:
> I was thinking that the launcher should only request fresh stats at wakeup,
> the workers could then reuse that file. This could be implemented by calling
> pgstat_clear_snapshot only at launcher wakeup and setting max stats age to
> to autovacuum_naptime for the workers.
>
Attached is
Martin Pihlak writes:
> Bruce Momjian wrote:
>> Bruce Momjian wrote:
>>> I know we don't like the current behavior, but I think we need to make
>>> them consistent first for easy testing and so when we change it, it will
>>> remain consistent.
>>>
>>> I will work on a consensus patch soon for the
Simon Riggs writes:
> The original design of Postgres allowed pluggable index access methods,
> but that capability has not been brought forward to allow for WAL. This
> patch would bridge that gap.
Well I think what people do is what GIST did early on -- they just don't
support recoverability u
Bruce Momjian wrote:
> Bruce Momjian wrote:
>> I know we don't like the current behavior, but I think we need to make
>> them consistent first for easy testing and so when we change it, it will
>> remain consistent.
>>
>> I will work on a consensus patch soon for the new behavior.
>
The "\dXU *.*
On Thu, Nov 6, 2008 at 12:03 AM, Jonah H. Harris wrote:
> As I wasn't sure whether anyone agrees with my distaste for
> repurposing tgenabled as mentioned above, I have attached is a patch
> which minimally corrects the function comment for EnableDisableTrigger
> where fires_when is concerned.
W
- after limit is reached, force cleanup of pending list by calling
gininsertcleanup. Not very good, because users sometimes will see a huge
execution time of simple insert. Although users who runs a huge update should be
satisfied.
I have difficulties in a choice of way. Seems to me, the bette
Andrew Dunstan wrote:
The pg_dump output was never backward compatible. (The input is.) So
the output of parallel restore need not be backward compatible either.
(Unless this mandate has changed dramatically while I was not
looking?) So always issue TRUNCATE ONLY, if that is what the logic
On Wed, Jan 21, 2009 at 1:25 PM, Simon Riggs wrote:
> The only reasonable way to examine the contents of WAL files is with
> reference to a copy of the catalog that wrote them, timed *exactly* in
> synchronisation with the WAL stream.
This is a good point.
>> Regarding the example plugin inclu
On Wed, 2009-01-21 at 16:25 +0300, Teodor Sigaev wrote:
> >> The external indexam use case doesn't impress me either, and Tom seems to
> >> agree
> >> (http://archives.postgresql.org/message-id/24006.1221483...@sss.pgh.pa.us).
> Just for correctness - there is one external index
> http://www.c
Stephen Frost wrote:
> * Tom Lane (t...@sss.pgh.pa.us) wrote:
>> On looking closer, though, it's *still* messy and unobvious :-(.
>> There is no single place in the parser where we have the complete
>> multi-level query tree available in a convenient form for this sort of
>> postprocessing.
>
> Th
Simon Riggs wrote:
Latest version of rmgr hooks patch for later review in current
commitfest.
I'd like to reject this patch.
I've read through all the related threads again, and I just still don't
see a convincing use case for it. I think that tools that let you
introspect and modify WAL fil
Magnus Hagander wrote:
In which case, we should perhaps just document the workaround using
WSAStartup() yourself, and not bother with either API or connection
parameter...
I didn't originally agree with this but now I do. Any libpq init function for
wsa, would only be replacing an app call
Peter Eisentraut wrote:
Andrew Dunstan wrote:
It's just occurred to me that if TRUNCATE no longer means TRUNCATE ONLY,
parallel restore will need to detect which server version is being
used so that for version > 8.3 it issues TRUNCATE ONLY.
The pg_dump output was never backward compatible.
On Wed, 2009-01-21 at 14:05 +0200, Heikki Linnakangas wrote:
> Simon Riggs wrote:
> > Latest version of rmgr hooks patch for later review in current
> > commitfest.
>
> I'd like to reject this patch.
...
> I've read through all the related threads again, and I just still don't
> see a convincing
Peter Eisentraut wrote:
> Magnus Hagander wrote:
>> However, one question: The comment currently says it's harmless to do
>> this on non-windows platforms. Does this still hold true?
>
> Yes, the non-WIN32 code path appears to be the same, still. But the
> ifdef WIN32 part we don't want, because
The external indexam use case doesn't impress me either, and Tom seems to agree
(http://archives.postgresql.org/message-id/24006.1221483...@sss.pgh.pa.us).
Just for correctness - there is one external index
http://www.cs.purdue.edu/spgist/
--
Teodor Sigaev E-m
Magnus Hagander wrote:
However, one question: The comment currently says it's harmless to do
this on non-windows platforms. Does this still hold true?
Yes, the non-WIN32 code path appears to be the same, still. But the
ifdef WIN32 part we don't want, because that presumes something about
the
On Wed, 2009-01-21 at 14:05 +0200, Heikki Linnakangas wrote:
> Simon Riggs wrote:
> > Latest version of rmgr hooks patch for later review in current
> > commitfest.
>
> I'd like to reject this patch.
...
> The external indexam use case doesn't impress me either, and Tom seems to
> agree
> (http
1 - 100 of 107 matches
Mail list logo
