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 not,
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. I
Robert Haas 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)
To make changes to yo
On Mon, Nov 7, 2011 at 2:14 PM, Josh Berkus 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 pg_standby, you can s
On Tue, Nov 15, 2011 at 11:08 AM, Julien Tachoires 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 place
> AL
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
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
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
http://archives.postgresq
On Tue, Nov 15, 2011 at 6:54 PM, Josh Kupershmidt 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 .SQL file in p
Peter Geoghegan 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
calculation is much more
Robert Haas writes:
> On Tue, Nov 15, 2011 at 10:36 AM, Alvaro Herrera
> 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
>>> categ
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 h
On 16/11/2011, at 12:26 PM, Robert Haas wrote:
> On Tue, Nov 15, 2011 at 7:59 PM, Royce Ausburn 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 wer
On 16 November 2011 01:09, Joshua Berkus 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 equally
well apply
On Tue, Nov 15, 2011 at 7:59 PM, Royce Ausburn 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 wrong.
>> I
> > 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:18 PM, Jeff Janes 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=
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 be
>
>
> 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, bu
On 15 November 2011 23:57, Robert Haas 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 involved in the project
On Mon, Nov 14, 2011 at 2:08 AM, Simon Riggs 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 to sync rep.
>
> P
On Tue, Nov 15, 2011 at 9:02 PM, Kevin Grittner
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 currently lower-hanging fru
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 case
On Tue, Nov 15, 2011 at 6:44 PM, Peter Geoghegan wrote:
> On 15 November 2011 21:53, Tom Lane 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
On 15 November 2011 21:53, Tom Lane 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 pretty much all the
On Sat, November 12, 2011 8:56 pm, Andrew Dunstan wrote:
>
>
> On 08/26/2011 05:11 PM, Tom Lane wrote:
>> Alvaro Herrera writes:
>>> The "--section=data --section=indexes" proposal seems very reasonable
>>> to
>>> me -- more so than "--sections='data indexes'".
>> +1 ... not only easier to code an
On Tue, Nov 15, 2011 at 3:47 PM, Kevin Grittner
wrote:
> Alvaro Herrera 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 see
On 16/11/2011, at 8:04 AM, Tom Lane wrote:
> Robert Haas writes:
>> On Tue, Nov 15, 2011 at 10:29 AM, Alvaro Herrera
>> 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?
>
>>
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
Josh Berkus 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 documentation. DBlink i
> 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
Robert Haas writes:
> On Tue, Nov 15, 2011 at 10:29 AM, Alvaro Herrera
> 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 but there are transactions with old
Robert Haas wrote:
> Josh Berkus 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 instead of shipping it.
>
> Wel
Alvaro Herrera 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 glad I haven't gotten ar
On 15 November 2011 20:23, Peter Eisentraut 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 types. That wo
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 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
On Tue, Nov 15, 2011 at 2:01 PM, Josh Berkus 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 wi
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 inter
On Tue, Nov 15, 2011 at 1:40 PM, Simon Riggs 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 we only need to qu
On 15 November 2011 19:01, Josh Berkus 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 a
generic C mo
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 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
Florian Weimer 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 the gen
On 15 November 2011 18:03, Robert Haas 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 the moment, becaus
On Tue, Nov 15, 2011 at 1:50 PM, Robert Haas 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, observes
> that there
Robert Haas 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 noncompatible mode
>> 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 possibl
On Tue, Nov 15, 2011 at 1:33 PM, Robert Haas 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 collection:
- stil
Robert Haas wrote:
> Joshua Berkus 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.
By an international stand
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 t
On Tue, Nov 15, 2011 at 10:29 AM, Alvaro Herrera
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 wrote:
>> > I reviewed your patch. I think it is in good shape, my two main remarks
>> > (name of n_unremovable_tup and
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.
I
On Tue, Nov 15, 2011 at 12:00 PM, Greg Smith 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 looks
> goo
On Tue, Nov 15, 2011 at 12:54 PM, Joshua Berkus 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 for kicki
On Tue, Nov 15, 2011 at 10:36 AM, Alvaro Herrera
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 wrote:
>> > Pavel Stehule writes:
>> >> there is a request on enhancing of pg_backup to produce a conditional
>> >> DROP
On Tue, Nov 15, 2011 at 10:36 AM, Alvaro Herrera
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 better.
>
> I think
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.
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
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
Robert Haas 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
> infrastructure for err
On Tue, Nov 15, 2011 at 11:08 AM, Julien Tachoires 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 place
> AL
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 so
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 wrote:
> > Pavel Stehule 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 dynami
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 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 revie
On 2011-11-15 16:16, Robert Haas wrote:
On Tue, Nov 15, 2011 at 10:05 AM, Yeb Havinga 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
On Tue, Nov 15, 2011 at 10:05 AM, Yeb Havinga 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
> other people have
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 consiste
On Tue, Nov 15, 2011 at 9:14 AM, Tom Lane wrote:
> Pavel Stehule 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 "--con
On Thu, Nov 10, 2011 at 2:49 PM, Tom Lane wrote:
> Bruce Momjian 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, we're using an enum --- may
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 Nove
2011/11/15 Tom Lane :
> Pavel Stehule 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_
Simon Riggs 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 use-case. The reason
Pavel Stehule 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 produce a DROP IF
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/
Postg
On Sun, Nov 13, 2011 at 11:16 PM, Tom Lane 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 = txid_current()::in
* 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 i
On 2011-11-14 15:45, Yeb Havinga wrote:
On 2011-10-15 07:41, Tom Lane wrote:
Yeb Havinga 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
reporting.
Thanks again
2011/11/15 Pavel Stehule :
> 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 p
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 instea
78 matches
Mail list logo
