Hello,
there is a request on enhancing of pg_backup to produce a conditional
DROPs. A reason for this request is more simple usage in very dynamic
production - cloud BI solution.
pg_backup can have a new option --conditional-drops and then pg_dump
will produce a DROP IF EXISTS statements instead
2011/11/15 Pavel Stehule pavel.steh...@gmail.com:
Hello,
there is a request on enhancing of pg_backup to produce a conditional
DROPs. A reason for this request is more simple usage in very dynamic
production - cloud BI solution.
pg_backup can have a new option --conditional-drops and then
On 2011-11-14 15:45, Yeb Havinga wrote:
On 2011-10-15 07:41, Tom Lane wrote:
Yeb Havingayebhavi...@gmail.com writes:
Hello Royce,
Thanks again for testing.
I looked this patch over but concluded that it's not ready to apply,
mainly because there are too many weird behaviors around error
* Andres Freund:
I don't gcc will ever be able to call all possible misusages. E.g. The
List api is a case where its basically impossible to catch everything
(as gcc won't be able to figure out what the ListCell.data.ptr_value
pointed to originally in the general case).
Correct, if code is
On Sun, Nov 13, 2011 at 11:16 PM, Tom Lane t...@sss.pgh.pa.us wrote:
While investigating bug #6291 I was somewhat surprised to discover
$SUBJECT. The cause turns out to be this kluge in alter_table.sql:
select virtualtransaction
from pg_locks
where transactionid =
Patch adds cacheline padding around parts of XLogCtl.
Idea from way back, but never got performance tested in a situation
where WALInsertLock was the bottleneck.
So this is speculative, in need of testing to investigate value.
--
Simon Riggs http://www.2ndQuadrant.com/
Pavel Stehule pavel.steh...@gmail.com writes:
there is a request on enhancing of pg_backup to produce a conditional
DROPs. A reason for this request is more simple usage in very dynamic
production - cloud BI solution.
pg_backup can have a new option --conditional-drops and then pg_dump
will
Simon Riggs si...@2ndquadrant.com writes:
We need a function called transactionid_current() so a normal user can write
select virtualtransaction
from pg_locks
where transactionid = transactionid_current()
and have it just work.
That would solve that one specific
2011/11/15 Tom Lane t...@sss.pgh.pa.us:
Pavel Stehule pavel.steh...@gmail.com writes:
there is a request on enhancing of pg_backup to produce a conditional
DROPs. A reason for this request is more simple usage in very dynamic
production - cloud BI solution.
pg_backup can have a new option
Bruce Momjian wrote:
I'd still be willing to write a patch for a client-only solution.
Agreed. There is clearly a win in turning off SSL compression for
certain workloads, and if people think the client is the right
location,
then let's do it there.
Here it is. I'll add it to the November
On Thu, Nov 10, 2011 at 2:49 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Bruce Momjian br...@momjian.us writes:
Well, we could use an optional details string for that. If not, we
are still using the magic-string approach, which I thought we didn't
like.
No, we're not using magic strings,
On Tue, Nov 15, 2011 at 9:14 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Pavel Stehule pavel.steh...@gmail.com writes:
there is a request on enhancing of pg_backup to produce a conditional
DROPs. A reason for this request is more simple usage in very dynamic
production - cloud BI solution.
On 2011-10-05 00:45, Royce Ausburn wrote:
Attached is v2 of my patch that doesn't update CATALOG_VERSION_NO. I've also fixed the name of an
argument to pgstat_report_vacuum which I don't think was particularly good, and I've replace the
word tuple with row in some docs I added for
On Tue, Nov 15, 2011 at 10:05 AM, Yeb Havinga yebhavi...@gmail.com wrote:
I reviewed your patch. I think it is in good shape, my two main remarks
(name of n_unremovable_tup and a remark about documentation at the end of
this review) are highly subjective and I wouldn't spend time on it unless
On 2011-11-15 16:16, Robert Haas wrote:
On Tue, Nov 15, 2011 at 10:05 AM, Yeb Havingayebhavi...@gmail.com wrote:
I reviewed your patch. I think it is in good shape, my two main remarks
(name of n_unremovable_tup and a remark about documentation at the end of
this review) are highly subjective
Excerpts from Robert Haas's message of mar nov 15 12:16:54 -0300 2011:
On Tue, Nov 15, 2011 at 10:05 AM, Yeb Havinga yebhavi...@gmail.com wrote:
I reviewed your patch. I think it is in good shape, my two main remarks
(name of n_unremovable_tup and a remark about documentation at the end of
Excerpts from Robert Haas's message of mar nov 15 11:59:17 -0300 2011:
On Tue, Nov 15, 2011 at 9:14 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Pavel Stehule pavel.steh...@gmail.com writes:
there is a request on enhancing of pg_backup to produce a conditional
DROPs. A reason for this request is
On 11/15/2011 10:29 AM, Alvaro Herrera wrote:
They were deleted but there are transactions with older snapshots.
I think vacuum uses the term nondeletable or nonremovable. Not sure
which one is less bad. Not being a native speaker, they all sound
horrible to me.
I would go more for
On Tue, Nov 15, 2011 at 11:08 AM, Julien Tachoires jul...@gmail.com wrote:
Maybe I'd missed something, but the normal case is :
ALTER TABLE ... SET TABLESPACE = moves Table + moves associated TOAST Table
ALTER TABLE ... SET TABLE TABLESPACE = moves Table keeps associated
TOAST Table at its
Robert Haas robertmh...@gmail.com wrote:
I'm not necessarily saying that any of these particular
things are what we want to do, just throwing out the idea that we
may want a variety of lock types that are similar to lightweight
locks but with subtly different behavior, yet with common
On 11/15/2011 09:44 AM, Scott Mead wrote:
Fell off the map last week, here's v2 that:
* RUNNING = active
* all states from CAPS to lower case
This looks like what I was hoping someone would add here now. Patch
looks good, only issue I noticed was a spaces instead of a tab goof
where you
Greg,
I'm not attached to the name, which I just pulled out of the air for
the
documentation. Could just as easily call them built-in modules or
extensions. If the objection is that extensions isn't technically
correct for auto-explain, you might call them core add-ons instead.
My
Peter,
I consider contrib/isn to be quite broken. It hard codes ISBN
prefixes
for the purposes of sanitising ISBNs, even though their assignment is
actually controlled by a decentralised body of regional authorities.
I'd vote for kicking it out of contrib.
Submit a patch to fix it then.
On Tue, Nov 15, 2011 at 10:36 AM, Alvaro Herrera
alvhe...@commandprompt.com wrote:
I'm wondering why we need an option for this, though. Assuming we
make DROP IF EXISTS work anywhere that it doesn't already, why not
just always produce that rather than straight DROP? It seems
categorically
On Tue, Nov 15, 2011 at 10:36 AM, Alvaro Herrera
alvhe...@commandprompt.com wrote:
Excerpts from Robert Haas's message of mar nov 15 11:59:17 -0300 2011:
On Tue, Nov 15, 2011 at 9:14 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Pavel Stehule pavel.steh...@gmail.com writes:
there is a request on
On Tue, Nov 15, 2011 at 12:54 PM, Joshua Berkus j...@agliodbs.com wrote:
I consider contrib/isn to be quite broken. It hard codes ISBN
prefixes
for the purposes of sanitising ISBNs, even though their assignment is
actually controlled by a decentralised body of regional authorities.
I'd vote
On Tue, Nov 15, 2011 at 12:00 PM, Greg Smith g...@2ndquadrant.com wrote:
On 11/15/2011 09:44 AM, Scott Mead wrote:
Fell off the map last week, here's v2 that:
* RUNNING = active
* all states from CAPS to lower case
This looks like what I was hoping someone would add here now. Patch
On 11/15/2011 12:53 PM, Joshua Berkus wrote:
Given discussion, is there any point in reporting on the actual patch yet?
I don't expect the discussion will alter the code changes that are the
main chunk of the patch here. The only place the most disputed parts
impact is the documentation.
On Tue, Nov 15, 2011 at 10:29 AM, Alvaro Herrera
alvhe...@commandprompt.com wrote:
Excerpts from Robert Haas's message of mar nov 15 12:16:54 -0300 2011:
On Tue, Nov 15, 2011 at 10:05 AM, Yeb Havinga yebhavi...@gmail.com wrote:
I reviewed your patch. I think it is in good shape, my two main
Robert Haas wrote:
I use ISBN in 2 projects, and it's working fine for me. ?I'll strongly
resist any attempt to kick it out.
That's exactly why contrib is a random amalgamation of really useful
stuff and utter crap: people feel justified in defending the continued
existence of the crap
Robert Haas robertmh...@gmail.com wrote:
Joshua Berkus j...@agliodbs.com wrote:
I consider contrib/isn to be quite broken. It hard codes ISBN
prefixes for the purposes of sanitising ISBNs, even though their
assignment is actually controlled by a decentralised body of
regional authorities.
On Tue, Nov 15, 2011 at 1:33 PM, Robert Haas robertmh...@gmail.com wrote:
nondeletable is surely terrible, since they may well have got into
this state by being deleted. nonremovable is better, but still not
great.
Bit of brain storm, including looking over to terminology used for
garbage
Submit a patch to fix it then.
It's not fixable. The ISBN datatype is the equivalent of having an
SSN datatype that only allows SSNs that have actually been assigned to
a US citizen.
Nothing is not fixable. not fixable without breaking backwards
compatibility is entirely possible,
Robert Haas robertmh...@gmail.com writes:
I wonder if that instead of trying to remain somewhat compatible to
other systems we should instead have a mode specifically designed for
that --one which didn't output SET or backslash commands, used inserts
rather than COPY, etc-- and have the
On Tue, Nov 15, 2011 at 1:50 PM, Robert Haas robertmh...@gmail.com wrote:
It basically
works like a regular LWLock, except that it has a special operation to
optimize ProcArrayEndTransaction(). In the uncontended case, instead
of acquiring and releasing the lock, it just grabs the lock,
On 15 November 2011 18:03, Robert Haas robertmh...@gmail.com wrote:
It's not fixable. The ISBN datatype is the equivalent of having an
SSN datatype that only allows SSNs that have actually been assigned to
a US citizen.
That isn't even the worst part. isn is basically only useful in the US
at
Florian Weimer fwei...@bfk.de wrote:
* Andres Freund:
I don't gcc will ever be able to call all possible misusages.
E.g. The List api is a case where its basically impossible to
catch everything (as gcc won't be able to figure out what the
ListCell.data.ptr_value pointed to originally in
Excerpts from Robert Haas's message of mar nov 15 15:03:03 -0300 2011:
On Tue, Nov 15, 2011 at 12:54 PM, Joshua Berkus j...@agliodbs.com wrote:
I consider contrib/isn to be quite broken. It hard codes ISBN
prefixes
for the purposes of sanitising ISBNs, even though their assignment is
On 15 November 2011 19:01, Josh Berkus j...@agliodbs.com wrote:
Nothing is not fixable.
My idea of fixing contrib/isn would be to remove so much of it that it
would obviously make more sense to use simple, flexible SQL. It simply
makes way too many assumptions about the user's business rules for
On Tue, Nov 15, 2011 at 1:40 PM, Simon Riggs si...@2ndquadrant.com wrote:
Which is the same locking avoidance technique we already use for sync
rep and for the new group commit patch.
Yep...
I've been saying for some time that we should use the same technique
for ProcArray and clog also, so
Here is the patch to implement type privileges that I alluded to
earlier. To recall, this is mainly so that owners can prevent others
from using their types because that would in some cases prevent owners
from changing the types. That would effectively be a denial of service.
These are the
On Tue, Nov 15, 2011 at 2:01 PM, Josh Berkus j...@agliodbs.com wrote:
Submit a patch to fix it then.
It's not fixable. The ISBN datatype is the equivalent of having an
SSN datatype that only allows SSNs that have actually been assigned to
a US citizen.
Nothing is not fixable. not fixable
Excerpts from Robert Haas's message of mar nov 15 17:16:31 -0300 2011:
On Tue, Nov 15, 2011 at 1:40 PM, Simon Riggs si...@2ndquadrant.com wrote:
Which is the same locking avoidance technique we already use for sync
rep and for the new group commit patch.
Yep...
I've been saying for
On 15 November 2011 20:23, Peter Eisentraut pete...@gmx.net wrote:
Here is the patch to implement type privileges that I alluded to
earlier. To recall, this is mainly so that owners can prevent others
from using their types because that would in some cases prevent owners
from changing the
Alvaro Herrera alvhe...@commandprompt.com wrote:
As Kevin says nearby it's likely that we could find some way to
rewrite the SLRU (clog and such) locking protocol using these new
things too.
Yeah, I really meant all SLRU, not just clog. And having seen what
Robert has done here, I'm kinda
Robert Haas robertmh...@gmail.com wrote:
Josh Berkus j...@agliodbs.com wrote:
Nothing is not fixable. not fixable without breaking
backwards compatibility is entirely possible, though. If fixing
it led to two different versions of ISN, then that would be a
reason to push it to PGXN
Robert Haas robertmh...@gmail.com writes:
On Tue, Nov 15, 2011 at 10:29 AM, Alvaro Herrera
alvhe...@commandprompt.com wrote:
Excerpts from Robert Haas's message of mar nov 15 12:16:54 -0300 2011:
I guess this is a dumb question, but why don't we remove all the dead
tuples?
They were deleted
Rebased with head.
FYI, I've added myself as the reviewer for the current commitfest.
Best,
Nathan Boley
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Josh Berkus j...@agliodbs.com writes:
The thing is, most of the extensions in /contrib have major flaws, or
they would have been folded in to the core code by now. CITEXT doesn't
support multiple collations. INTARRAY and LTREE have inconsistent
operators and many bugs. CUBE lacks
On 16/11/2011, at 2:05 AM, Yeb Havinga wrote:
On 2011-10-05 00:45, Royce Ausburn wrote:
Attached is v2 of my patch that doesn't update CATALOG_VERSION_NO. I've
also fixed the name of an argument to pgstat_report_vacuum which I don't
think was particularly good, and I've replace the word
On 16/11/2011, at 8:04 AM, Tom Lane wrote:
Robert Haas robertmh...@gmail.com writes:
On Tue, Nov 15, 2011 at 10:29 AM, Alvaro Herrera
alvhe...@commandprompt.com wrote:
Excerpts from Robert Haas's message of mar nov 15 12:16:54 -0300 2011:
I guess this is a dumb question, but why don't we
On Tue, Nov 15, 2011 at 3:47 PM, Kevin Grittner
kevin.gritt...@wicourts.gov wrote:
Alvaro Herrera alvhe...@commandprompt.com wrote:
As Kevin says nearby it's likely that we could find some way to
rewrite the SLRU (clog and such) locking protocol using these new
things too.
Yeah, I really
On Sat, November 12, 2011 8:56 pm, Andrew Dunstan wrote:
On 08/26/2011 05:11 PM, Tom Lane wrote:
Alvaro Herreraalvhe...@commandprompt.com writes:
The --section=data --section=indexes proposal seems very reasonable
to
me -- more so than --sections='data indexes'.
+1 ... not only easier to
On 15 November 2011 21:53, Tom Lane t...@sss.pgh.pa.us wrote:
There's a larger issue here, which is that a lot of the stuff in contrib
is useful as (a) coding examples for people to look at, and/or (b) test
cases for core-server functionality. If a module gets kicked out to
PGXN we lose
On Tue, Nov 15, 2011 at 6:44 PM, Peter Geoghegan pe...@2ndquadrant.com wrote:
On 15 November 2011 21:53, Tom Lane t...@sss.pgh.pa.us wrote:
There's a larger issue here, which is that a lot of the stuff in contrib
is useful as (a) coding examples for people to look at, and/or (b) test
cases for
Hi all,
Commit c7f23494c1103f87bcf1ef7cbfcd626e73edb337 editorialized a bit on
Gurjeet Singh's patch to implement \ir for psql, particularly in
process_file(). Unfortunately, it looks like it broke the common case
of loading a .SQL file in psql's working directory. Consider the
following test
On Tue, Nov 15, 2011 at 9:02 PM, Kevin Grittner
kevin.gritt...@wicourts.gov wrote:
From my reading, it appears that if we get safe code in terms of
strict aliasing, we might be able to use the restrict keyword to
get further optimizations which bring it to a net win, but I think
there is
On Mon, Nov 14, 2011 at 2:08 AM, Simon Riggs si...@2ndquadrant.com wrote:
Enclosed patch implements Group Commit and also powersave mode for WALWriter.
XLogFlush() waits for WALWriter to run XLogBackgroundFlush(), which
flushes WAL and then wakes waiters. Uses same concepts and similar
code
On 15 November 2011 23:57, Robert Haas robertmh...@gmail.com wrote:
We can't go on complaining one the one hand that
people don't install postgresql-contrib, and then on the other hand
insist on shipping really bad code in contrib. It's asking a lot for
someone who isn't already heavily
Personally I think some log output, done better, would have been more useful
for me at the time. At the time I was trying to diagnose an ineffective
vacuum and postgres' logs weren't giving me any hints about what was wrong.
I turned to the mailing list and got immediate help, but I
All,
I agree. The argument that this code is useful as example code has
been offered before, but the justification is pretty thin when the
example code is an example of a horrible design that no one should
ever copy.
People are already using ISN (or at least ISBN) in production. It's been
On Tue, Nov 15, 2011 at 7:18 PM, Jeff Janes jeff.ja...@gmail.com wrote:
When I apply this to HEAD and run make check, it freezes at:
test tablespace ...
[...]
Does anyone else see this?
It hangs for me, too, just slightly later:
== running regression test queries
Here is a patch for that for pg_dump. The sections provided for are
pre-data, data and post-data, as discussed elsewhere. I still feel that
anything finer grained should be handled via pg_restore's --use-list
functionality. I'll provide a patch to do the same switch for pg_restore
On Tue, Nov 15, 2011 at 7:59 PM, Royce Ausburn royce...@inomial.com wrote:
Personally I think some log output, done better, would have been more useful
for me at the time. At the time I was trying to diagnose an ineffective
vacuum and postgres' logs weren't giving me any hints about what was
On 16 November 2011 01:09, Joshua Berkus j...@agliodbs.com wrote:
People are already using ISN (or at least ISBN) in production. It's been
around for 12 years.
contrib/isn has been around since 2006. The argument some unknowable
number of people are using this feature in production could
On 16/11/2011, at 12:26 PM, Robert Haas wrote:
On Tue, Nov 15, 2011 at 7:59 PM, Royce Ausburn royce...@inomial.com wrote:
Personally I think some log output, done better, would have been more
useful for me at the time. At the time I was trying to diagnose an
ineffective vacuum and
Well, this discussion veering off into ISN has certainly validated my
gut feel that I should touch only the minimum number of things that
kills my pain points, rather than trying any more ambitious
restructuring. I hope that packaged extensions become so popular that
some serious cutting can
Robert Haas robertmh...@gmail.com writes:
On Tue, Nov 15, 2011 at 10:36 AM, Alvaro Herrera
alvhe...@commandprompt.com wrote:
I'm wondering why we need an option for this, though. Assuming we
make DROP IF EXISTS work anywhere that it doesn't already, why not
just always produce that rather
Peter Geoghegan pe...@2ndquadrant.com writes:
If we can't put isn out of its misery, a sensible compromise would be
to rip out the prefix enforcement feature so that, for example, ISBN13
behaved exactly the same as EAN13.
That might be a reasonable compromise. Certainly the check-digit
On Tue, Nov 15, 2011 at 6:54 PM, Josh Kupershmidt schmi...@gmail.com wrote:
Commit c7f23494c1103f87bcf1ef7cbfcd626e73edb337 editorialized a bit on
Gurjeet Singh's patch to implement \ir for psql, particularly in
process_file(). Unfortunately, it looks like it broke the common case
of loading a
Two years ago Magnus submitted a patch to parse all the configuration
files in a directory. After some discussion I tried to summarize what I
thought the most popular ideas were for moving that forward:
http://archives.postgresql.org/pgsql-hackers/2009-10/msg01452.php
By recent popular request in the ongoing discussion saga around merging
the recovery.conf, I've added an includeifexists directive to the
postgresql.conf in the attached patch. Demo:
$ tail -n 1 $PGDATA/postgresql.conf
include 'missing.conf'
$ pg_ctl start -l $PGLOG
server starting
$ tail -n
On Tue, Nov 15, 2011 at 10:55:49AM -0600, Kevin Grittner wrote:
And I would be
surprised if some creative thinking didn't yield a far better FL
scheme for SSI than we can manage with existing LW locks.
One place I could see it being useful is for
SerializableFinishedListLock, which protects
On Tue, Nov 15, 2011 at 11:08 AM, Julien Tachoires jul...@gmail.com wrote:
Maybe I'd missed something, but the normal case is :
ALTER TABLE ... SET TABLESPACE = moves Table + moves associated TOAST Table
ALTER TABLE ... SET TABLE TABLESPACE = moves Table keeps associated
TOAST Table at its
On Mon, Nov 7, 2011 at 2:14 PM, Josh Berkus j...@agliodbs.com wrote:
2. standby_mode becomes an ENUM: off,standby,pitr. It can be reset on
server reload or through pg_ctl promote
I'm a little bit confused by the way we're dragging standby_mode into
this conversation. If you're using
Robert Haas robertmh...@gmail.com writes:
Thanks for the review. New version attached.
This looks sane to me too (though I only read the patch and didn't
actually test upgrading).
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
On 10/05/2011 03:02 AM, Greg Smith wrote:
Presumably you meant to ask if this makes sense to show when cost
accounting isn't enabled, because the code doesn't do that right now.
No cost accounting, no buffer usage/write rate data as this was
submitted.
This is done in the attached update.
Hello.
Are there any howto's or articles about building client access library
(libpq) for several target OSes, e.g. Win32, Win64, MacOS in the same
MinGW environment?
And is it possible at all? I know that there is MinGW-w64 to produce
Win64 binaries, but I want to have one farm for all.
If
78 matches
Mail list logo
