Tom Lane wrote:
Kevin Grittner kevin.gritt...@wicourts.gov writes:
Tom Lane t...@sss.pgh.pa.us wrote:
The reason for wanting to deprecate and ultimately remove that
syntax is so we can get rid of FREEZE as a reserved word.
Oh, OK. I can go along with that. If we're going that route,
On Fri, 2011-01-14 at 15:05 -0500, Tom Lane wrote:
Simon Riggs si...@2ndquadrant.com writes:
On Fri, 2011-01-14 at 14:48 -0500, Tom Lane wrote:
In any case I'd rather break apps using LOCK foo NOWAIT than break
every application using any form of LOCK at all, which is what I think
your
On 08/01/11 23:37, Alexander Korotkov wrote:
I updated my patch to make it use full index scan in GIN index which is
possible thanks to recent Tom Lane patch. Now wildcard, where no trigram can
be extracted from, invokes full index scan, which is slow but correct.
Hi,
unfortunately, this
On Fri, Jan 14, 2011 at 2:51 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
On Fri, Jan 14, 2011 at 2:09 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Freezing sooner isn't likely to reduce I/O compared to hint bits. What
that does is create I/O that you *have* to
On Fri, Jan 14, 2011 at 2:15 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Kevin Grittner kevin.gritt...@wicourts.gov writes:
If we're going to be supporting that long term, we should probably
change the note about FREEZE being deprecated, though.
So, still +1 on removing the wording about FREEZE
Robert Haas robertmh...@gmail.com wrote:
I'm not wildly enthusiastic about breaking this with only one
intervening release. We normally support deprecated syntax for
quite a bit longer than that.
one intervening release? Where did you see that?
I thought we were just talking about
Hi,
Here is a patch that implements named restore points.
It allows DBAs to specify an exact point to which they can recover
but that point will have a name, so they have a better control of when
they want to stop recovery (ie: DBA's won't depend of remember
specific times, dates and such).
On Fri, Jan 14, 2011 at 3:41 PM, Kevin Grittner
kevin.gritt...@wicourts.gov wrote:
Robert Haas robertmh...@gmail.com wrote:
I'm not wildly enthusiastic about breaking this with only one
intervening release. We normally support deprecated syntax for
quite a bit longer than that.
one
Simon Riggs si...@2ndquadrant.com writes:
On Fri, 2011-01-14 at 15:05 -0500, Tom Lane wrote:
No, that will not work at all. LOCK has to be a utility command.
But it doesn't break the use case for locking sequences, ISTM.
You haven't stated what you think that use case is, but in any case
I'm
Thanks for reviewing!
On Fri, Jan 14, 2011 at 13:40, Robert Haas robertmh...@gmail.com wrote:
Did you check whether this updated the code for 100% of the object
types where this could apply?
I walked through all the CREATE statements in the documentation and
these four seem to be the only ones
Thanks for considering our special scenario. I did not use the vacuum freeze
option because the documentation said it is going to be deprecrated. Based on
the positive votes so far, I gather that a vacuum (freeze) syntax will be
supported in some version in the future, until then, I can
On Fri, 2011-01-14 at 15:46 -0500, Tom Lane wrote:
Simon Riggs si...@2ndquadrant.com writes:
On Fri, 2011-01-14 at 15:05 -0500, Tom Lane wrote:
No, that will not work at all. LOCK has to be a utility command.
But it doesn't break the use case for locking sequences, ISTM.
You haven't
I wrote:
It looks to me like the reason why there's a shift/reduce conflict is
not so much that TABLE is optional as that we allow the syntax
LOCK tablename NOWAIT
BTW, I did confirm this to the extent of showing that the shift-reduce
conflict could be eliminated by attaching precedences
Dear pghackers,
During the last two weeks, I have enjoyed a total of 113 hours of
development of pov - PostgreSQL Object Version control system.
Version 1.0 is now finally released!
POV will not touch any of your data (tables, sequences, indexes) -
it will only keep track of your logics
On Fri, 2011-01-14 at 16:09 -0500, Tom Lane wrote:
I think the realistic options are (1) change the syntax
non-backward-compatibly or (2) don't add any functionality here.
(3) think of another way.
I'm not keen to explain to people how we broke their applications just
because we wanted to add
Kevin Grittner kevin.gritt...@wicourts.gov writes:
Robert Haas robertmh...@gmail.com wrote:
The critical issue is whether the tuples get frozen while they're
still invisible to some transactions on the standby server.
That's when you get query cancellations.
Oh, OK; I get that. That seems
Tom Lane t...@sss.pgh.pa.us wrote:
Kevin Grittner kevin.gritt...@wicourts.gov writes:
Robert Haas robertmh...@gmail.com wrote:
The critical issue is whether the tuples get frozen while
they're still invisible to some transactions on the standby
server. That's when you get query
On 01/14/2011 11:48 AM, Stephen Frost wrote:
* Tom Lane (t...@sss.pgh.pa.us) wrote:
Andrew Dunstanand...@dunslane.net writes:
I think it's time to revisit the design of CSV logs again, now we have
two or three releases worth of experience with it. It needs some
flexibility and refinement.
On Fri, Jan 14, 2011 at 4:56 PM, Andrew Dunstan and...@dunslane.net wrote:
I'm not sure I really want to make it that flexible :-)
To deal with the issue Tom's referring to, I think it would be sufficient if
we just allowed users to suppress production of certain columns (as long as
we never
Andrew Dunstan and...@dunslane.net writes:
On 01/14/2011 11:48 AM, Stephen Frost wrote:
My first thought would be to have a 'log_csv_format' GUC that's very
similar to 'log_line_prefix' (and uses the same variables if
possible..). We could then ship a default in postgresql.conf that
matches
On 01/14/2011 05:04 PM, Aidan Van Dyk wrote:
If there is going to be any change, how about using fixed columns (an
possibly allowing them to be empty for stuff that's expensive to
create/write), but adding a 1st column that contains a version
identifyer. And to make it easy, maybe the PG
Simon Riggs si...@2ndquadrant.com writes:
It's a major undertaking trying to write software that runs against
PostgreSQL for more than one release. We should be making that easier,
not harder.
None of the proposals would make it impossible to write a LOCK statement
that works on all available
Jaime Casanova ja...@2ndquadrant.com writes:
Here is a patch that implements named restore points.
It allows DBAs to specify an exact point to which they can recover
but that point will have a name, so they have a better control of when
they want to stop recovery (ie: DBA's won't depend of
Simon Riggs si...@2ndquadrant.com writes:
On Fri, 2011-01-14 at 16:09 -0500, Tom Lane wrote:
I think the realistic options are (1) change the syntax
non-backward-compatibly or (2) don't add any functionality here.
(3) think of another way.
The only third way that I can see is to invent some
Hi,
I propose the patch which reduces the amount of data loss
on the standby.
If you create the trigger file after replication is terminated,
the standby tries to replay all the WAL available in pg_xlog
and the archive. This behavior is OK, and it's helpful to reduce
the amount of data loss.
Em 14-01-2011 17:41, Jaime Casanova escreveu:
Here is a patch that implements named restore points.
Nice feature. I only read the provided documentation and it seems inconsistent
to allow name, time, and xid at recovery_target_name because (i) someone could
name the recovery point as
Aidan Van Dyk ai...@highrise.ca writes:
If there is going to be any change, how about using fixed columns (an
possibly allowing them to be empty for stuff that's expensive to
create/write), but adding a 1st column that contains a version
identifyer. And to make it easy, maybe the PG major
On Fri, Jan 14, 2011 at 5:42 PM, Euler Taveira de Oliveira
eu...@timbira.com wrote:
Em 14-01-2011 17:41, Jaime Casanova escreveu:
Here is a patch that implements named restore points.
Nice feature. I only read the provided documentation and it seems
inconsistent to allow name, time, and xid
in this message.
http://archives.postgresql.org/pgsql-hackers/2011-01/msg01096.php
2) copy_export-20110114.patch (NOT attached to this message)
This patch is attached and described in this message.
http://archives.postgresql.org/pgsql-hackers/2011-01/msg01066.php
3) 20110114
On Fri, Jan 14, 2011 at 5:34 PM, Tom Lane t...@sss.pgh.pa.us wrote:
I'm not keen to explain to people how we broke their applications just
because we wanted to add new functionality AND avoid one shift/reduce
conflict in our SQL grammar. Avoiding changes to user code isn't third
on that list
On Fri, Jan 14, 2011 at 3:41 PM, Jaime Casanova ja...@2ndquadrant.com wrote:
Here is a patch that implements named restore points.
It allows DBAs to specify an exact point to which they can recover
but that point will have a name, so they have a better control of when
they want to stop
On Fri, Jan 14, 2011 at 3:45 PM, Marti Raudsepp ma...@juffo.org wrote:
There's a similar case with CREATE TABLE IF NOT EXISTS, maybe this is
worth covering in an updated patch too?
And if I change that, people might expect the same from DROP X IF EXISTS too?
It's far less clear what you'd
On Fri, Jan 14, 2011 at 4:41 PM, Peter Eisentraut pete...@gmx.net wrote:
I've been going over this patch with a fine-tooth comb for the last two
weeks, fixed some small bugs, added comments, made initdb a little
friendlier, but no substantial changes.
I'm going to start working on SQL-level
On 01/14/2011 05:08 PM, Tom Lane wrote:
Andrew Dunstanand...@dunslane.net writes:
On 01/14/2011 11:48 AM, Stephen Frost wrote:
My first thought would be to have a 'log_csv_format' GUC that's very
similar to 'log_line_prefix' (and uses the same variables if
possible..). We could then ship a
On Fri, 14 Jan 2011 14:59:00 -0500
Andrew Dunstan and...@dunslane.net wrote:
Have you actually posted this version of file_fdw? I haven't seen it.
Sorry, now it's been posted.
http://archives.postgresql.org/pgsql-hackers/2011-01/msg01205.php
Regarads,
--
Shigeru Hanada
--
Sent via
Andrew Dunstan and...@dunslane.net writes:
On 01/14/2011 05:08 PM, Tom Lane wrote:
It actually sounded like a pretty good idea to me.
If you have a format string, what do you want to do with the bits of the
format that aren't field references?
I was thinking of it as being strictly a field
Robert Haas robertmh...@gmail.com writes:
Me, too. But I don't agree with your particular choice of small
syntax adjustment. Maybe we should just let the issue drop for now.
Nobody's actually complained about this that I can recall; it's just a
comment that's been sitting there in pg_dump
On Fri, 2011-01-14 at 17:18 -0500, Tom Lane wrote:
Jaime Casanova ja...@2ndquadrant.com writes:
Here is a patch that implements named restore points.
It allows DBAs to specify an exact point to which they can recover
but that point will have a name, so they have a better control of when
On Fri, 2011-01-14 at 17:34 -0500, Tom Lane wrote:
I'm not keen to explain to people how we broke their applications
just
because we wanted to add new functionality AND avoid one
shift/reduce
conflict in our SQL grammar. Avoiding changes to user code isn't
third
on that list of three
On 1/14/11 11:51 AM, Tom Lane wrote:
The people whose tables are mostly insert-only complain about it, but
that's not the majority of our userbase IMO. We just happen to have a
couple of particularly vocal ones, like Berkus.
It might or might not be the majority, but it's an extremely common
Em 14-01-2011 20:47, Robert Haas escreveu:
On Fri, Jan 14, 2011 at 4:41 PM, Peter Eisentrautpete...@gmx.net wrote:
I've been going over this patch with a fine-tooth comb for the last two
weeks, fixed some small bugs, added comments, made initdb a little
friendlier, but no substantial changes.
On Jan 8, 2011, at 9:41 PM, Tom Lane wrote:
David E. Wheeler da...@kineticode.com writes:
On Jan 7, 2011, at 4:19 PM, Tom Lane wrote:
Well, actually, I just committed it. If you want to test, feel free.
Note that right now only the anyarray @ @ operators are genuinely
fixed ... I plan to
Em 14-01-2011 19:50, Jaime Casanova escreveu:
On Fri, Jan 14, 2011 at 5:42 PM, Euler Taveira de Oliveira
eu...@timbira.com wrote:
Em 14-01-2011 17:41, Jaime Casanova escreveu:
Here is a patch that implements named restore points.
Nice feature. I only read the provided documentation and it
On Fri, Jan 14, 2011 at 8:00 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Andrew Dunstan and...@dunslane.net writes:
On 01/14/2011 05:08 PM, Tom Lane wrote:
It actually sounded like a pretty good idea to me.
If you have a format string, what do you want to do with the bits of the
format that
* Tom Lane (t...@sss.pgh.pa.us) wrote:
Andrew Dunstan and...@dunslane.net writes:
If you have a format string, what do you want to do with the bits of the
format that aren't field references?
I was thinking of it as being strictly a field list. I don't know
whether it's really practical
On Fri, Jan 14, 2011 at 8:33 PM, Euler Taveira de Oliveira
eu...@timbira.com wrote:
OK. I will review your patch at the beginning of the week.
thanks
--
Jaime Casanova www.2ndQuadrant.com
Professional PostgreSQL: Soporte y capacitación de PostgreSQL
--
Sent via pgsql-hackers
David E. Wheeler da...@kineticode.com writes:
So some questions:
* Is something seriously wrong with GiST index creation on integer[] columns?
* Why does GIN performance appear to be no better than table scans on
integer[] columns?
* Why does it take 3-4x longer to create the GIN than the
Stephen Frost sfr...@snowman.net writes:
* Tom Lane (t...@sss.pgh.pa.us) wrote:
I was thinking of it as being strictly a field list. I don't know
whether it's really practical to borrow log_line_prefix's one-character
names for the fields (for one thing, there would need to be names for
all
On 01/14/2011 08:41 PM, Robert Haas wrote:
I think we're in the process of designing a manned mission to Mars to
solve the problem that our shoelaces are untied.
What's your suggestion, then?
cheers
andre
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make
Robert Haas robertmh...@gmail.com writes:
On Fri, Jan 14, 2011 at 8:00 PM, Tom Lane t...@sss.pgh.pa.us wrote:
I was thinking of it as being strictly a field list.
I think we're in the process of designing a manned mission to Mars to
solve the problem that our shoelaces are untied.
How so?
* Tom Lane (t...@sss.pgh.pa.us) wrote:
A user-settable column list seems pretty on-target
for solving those problems to me.
I'm looking into implementing this.
An interesting initial question is- should the users be able to control
the *order* of the columns? My gut feeling, if we're giving
Stephen Frost sfr...@snowman.net writes:
* Tom Lane (t...@sss.pgh.pa.us) wrote:
A user-settable column list seems pretty on-target
for solving those problems to me.
I'm looking into implementing this.
An interesting initial question is- should the users be able to control
the *order* of
On 01/14/2011 09:51 PM, Tom Lane wrote:
Stephen Frostsfr...@snowman.net writes:
* Tom Lane (t...@sss.pgh.pa.us) wrote:
A user-settable column list seems pretty on-target
for solving those problems to me.
I'm looking into implementing this.
An interesting initial question is- should the
* Tom Lane (t...@sss.pgh.pa.us) wrote:
In any case, if the GUC representation is a list of field names, I think
the POLA demands that the system honor the list order.
Agreed. That puts us back into the question of how to make it
efficient. My best thought at the moment, which doesn't strike
* Andrew Dunstan (and...@dunslane.net) wrote:
The only thing I'd suggest extra is that we might allow
version_n_m as shorthand for the default table layout from the
relevant version.
I like that idea, makes the default a lot simpler to deal with too. :)
Thanks!
Andrew Dunstan and...@dunslane.net writes:
The only thing I'd suggest extra is that we might allow version_n_m as
shorthand for the default table layout from the relevant version.
Mmm ... seems like that just complicates matters. To make that useful,
you have to assume that there *is* a
Hello Joachim,
I'm reviewing this patch for CommitFest 2011-01.
On Fri, Jan 07, 2011 at 06:41:38AM -0500, Joachim Wieland wrote:
On Thu, Dec 30, 2010 at 7:31 AM, Joachim Wieland j...@mcknight.de wrote:
What I am proposing now is the following:
We return snapshot information as a chunk of
Stephen Frost sfr...@snowman.net writes:
* Tom Lane (t...@sss.pgh.pa.us) wrote:
In any case, if the GUC representation is a list of field names, I think
the POLA demands that the system honor the list order.
Agreed. That puts us back into the question of how to make it
efficient. My best
* Tom Lane (t...@sss.pgh.pa.us) wrote:
everything that looks at this GUC value
will know instantly what it is for each version.
The last bit is kind of a killer for tools like pgfouine, no?
Ugh.. Could we just accept it as input but return the full list if
asked for it
In any case I thought
* Tom Lane (t...@sss.pgh.pa.us) wrote:
Yeah, an array or list of integer codes was what I was thinking too.
Hm, yeah, a list of integer codes might be even better/simpler.
Okay, next user-interface question- thoughts on handling SIGHUP? My
first reaction is that we should create a new log file
Stephen Frost sfr...@snowman.net writes:
I'd been puzzling over how to deal with this big list of fields in
postgresql.conf and I do like the idea of some kind of short-cut being
provided to ease the pain for users.
Yeah, I agree with the worry that a default value that's a mile long
is going
Stephen Frost sfr...@snowman.net writes:
Okay, next user-interface question- thoughts on handling SIGHUP? My
first reaction is that we should create a new log file on SIGHUP (if we
don't already, havn't checked), or maybe just on SIGHUP if this variable
changes.
Point being, until we get
On Tue, Dec 7, 2010 at 07:24, Tim Bunce tim.bu...@pobox.com wrote:
Changes:
Sets the local $_TD via C instead of passing an extra argument.
So functions no longer start with our $_TD; local $_TD = shift;
Pre-extend stack for trigger arguments for slight performance gain.
Passes
Here's v2 based on your feedback.
I pruned test coverage down to just the highlights. By the end of patch series,
the net change becomes +67 to alter_table.sql and +111 to alter_table.out. The
alter_table.out delta is larger in this patch (+150), because the optimizations
don't yet apply and
Tom Lane wrote:
I think we need to keep the override capability until the autotune
algorithm has proven itself in the field for a couple of years.
I agree with Josh that a negative value should be used to select the
autotune method.
Agreed on both fronts. Attached patch does the magic.
Kevin Grittner wrote:
I guess a manual override doesn't bother me too much, but I am a bit dubious of
its
value, and there is value in keeping the GUC count down...
It's a risk-reward thing really. The reward for removing it is that a
few lines of code and a small section of the
On Jan 14, 2011, at 5:54 PM, Tom Lane wrote:
David E. Wheeler da...@kineticode.com writes:
So some questions:
* Is something seriously wrong with GiST index creation on integer[] columns?
* Why does GIN performance appear to be no better than table scans on
integer[] columns?
* Why
101 - 167 of 167 matches
Mail list logo
