Jeff Janes writes:
> On Wednesday, January 2, 2013, Tom Lane wrote:
>> That scenario doesn't sound like it has anything to do with the one being
>> discussed in this thread. But what do you mean by "rule-based
>> partitioning" exactly? A rule per se wouldn't result in a cached plan
>> at all, le
On Thu, Jan 10, 2013 at 11:45 AM, Amit Kapila wrote:
> On Thursday, January 10, 2013 6:09 AM Josh Berkus wrote:
>>
>> Surely VACUUM FULL should rebuild the visibility map, and make tuples
>> in
>> the new relation all-visible, no?
>
> I think it cannot made all visible.
> How about if any transac
On Thursday, January 10, 2013 6:09 AM Josh Berkus wrote:
> On 01/09/2013 03:07 PM, Bruce Momjian wrote:
> > How do we want to handle the case where VACUUM FULL clears the
> > visibility map, causing loss of index-only scans?
> >
> > http://archives.postgresql.org/pgsql-performance/2012-
> 11/ms
On Tue, 2012-12-04 at 01:03 -0800, Jeff Davis wrote:
> For now, I rebased the patches against master, and did some very minor
> cleanup.
I think there is a problem here when setting PD_ALL_VISIBLE. I thought I
had analyzed that before, but upon review, it doesn't look right.
Setting PD_ALL_VISIBLE
I wrote:
> Bruce Momjian writes:
>> On Wed, Jan 9, 2013 at 10:27:54PM -0500, Tom Lane wrote:
>>> Something might have slipped through the cracks though.
>> In mvcc.sgml, I see:
>> --> some forms of ALTER TABLE.
> A bit of "git blame" later, the culprit is commit
> 7212c77d0cabcc468fec0b9cd
Bruce Momjian writes:
> On Wed, Jan 9, 2013 at 10:27:54PM -0500, Tom Lane wrote:
>> Bruce Momjian writes:
>>> EnterpriseDB reports that our documentation states that ALTER TABLE
>>> takes SHARE UPDATE EXCLUSIVE and ACCESS EXCLUSIVE lock modes.
>> Where do they see that? We certainly reverted a
Simon Riggs writes:
> Having it USERSET allows different settings for different roles, which
> is useful.
That would still be possible if it were SUSET; you'd just need a
superuser to set it for you (via ALTER ROLE SET, or perhaps a
security-definer wrapper function if you were desperate).
The r
On Wed, Jan 9, 2013 at 10:27:54PM -0500, Tom Lane wrote:
> Bruce Momjian writes:
> > EnterpriseDB reports that our documentation states that ALTER TABLE
> > takes SHARE UPDATE EXCLUSIVE and ACCESS EXCLUSIVE lock modes.
>
> Where do they see that? We certainly reverted all of the documentation
>
I wrote:
> Done, we'll soon see how much the buildfarm likes it.
Well, okapi (Gentoo) doesn't like it:
configure:29191: checking for libperl
configure:29217: icc -o conftest -O3 -xSSSE3 -parallel -ip -mp1
-fno-strict-aliasing -g -I/usr/lib64/perl5/5.12.4/x86_64-linux/CORE
-D_GNU_SOURCE -I/usr/
On Wednesday, January 9, 2013, Simon Riggs wrote:
> On 23 November 2012 22:34, Jeff Janes >
> wrote:
>
> > I got rid of need_eoxact_work entirely and replaced it with a short
> > list that fulfills the functions of indicating that work is needed,
> > and suggesting which rels might need that work.
Bruce Momjian writes:
> EnterpriseDB reports that our documentation states that ALTER TABLE
> takes SHARE UPDATE EXCLUSIVE and ACCESS EXCLUSIVE lock modes.
Where do they see that? We certainly reverted all of the documentation
that Simon changed in the original commit for that failed feature.
So
On Thu, Jan 10, 2013 at 11:22 AM, Bruce Momjian wrote:
> EnterpriseDB reports that our documentation states that ALTER TABLE
> takes SHARE UPDATE EXCLUSIVE and ACCESS EXCLUSIVE lock modes. However,
> their testing shows only ACCESS EXCLUSIVE locks. Is this accurate?
> Have we changed how ALTER
On Thu, Jan 10, 2013 at 02:45:36AM +, Simon Riggs wrote:
> On 8 January 2013 02:49, Noah Misch wrote:
> > There is a bug in lazy_scan_heap()'s
> > bookkeeping for the xid to place in that WAL record. Each call to
> > heap_page_prune() simply overwrites vacrelstats->latestRemovedXid, but
> > l
On Thu, Jan 10, 2013 at 02:48:23AM +, Simon Riggs wrote:
> On 10 January 2013 02:36, Noah Misch wrote:
> > On Wed, Jan 09, 2013 at 03:20:33PM -0500, Tom Lane wrote:
> >> What would people think of just eliminating the access-permissions
> >> checks involved in temp_tablespaces? It would likel
On 10 January 2013 02:36, Noah Misch wrote:
> On Wed, Jan 09, 2013 at 03:20:33PM -0500, Tom Lane wrote:
>> What would people think of just eliminating the access-permissions
>> checks involved in temp_tablespaces? It would likely be appropriate to
>> change temp_tablespaces from USERSET to SUSET
On 8 January 2013 02:49, Noah Misch wrote:
> There is a bug in lazy_scan_heap()'s
> bookkeeping for the xid to place in that WAL record. Each call to
> heap_page_prune() simply overwrites vacrelstats->latestRemovedXid, but
> lazy_scan_heap() expects it to only ever increase the value. I have a
On Wed, Jan 09, 2013 at 03:20:33PM -0500, Tom Lane wrote:
> What would people think of just eliminating the access-permissions
> checks involved in temp_tablespaces? It would likely be appropriate to
> change temp_tablespaces from USERSET to SUSET if we did so. So
> essentially the worldview woul
EnterpriseDB reports that our documentation states that ALTER TABLE
takes SHARE UPDATE EXCLUSIVE and ACCESS EXCLUSIVE lock modes. However,
their testing shows only ACCESS EXCLUSIVE locks. Is this accurate?
Have we changed how ALTER TABLE locks but didn't update our docs?
--
Bruce Momjian
Ian Lawrence Barwick writes:
> The documentation says:
> The view schemata contains all schemas in the current database that
> are owned by a currently enabled role.
> ( http://www.postgresql.org/docs/9.2/static/infoschema-schemata.html )
> However it shows all schemas if the user is a superuser
Hi Pavan,
Thanks for reviewing.
On Tue, Jan 08, 2013 at 02:41:54PM +0530, Pavan Deolasee wrote:
> On Tue, Jan 8, 2013 at 8:19 AM, Noah Misch wrote:
> > At that point in the investigation, I realized that the cost of being able
> > to
> > remove entire tuples in lazy_vacuum_heap() greatly exceeds
Andrew Dunstan writes:
> On 01/09/2013 04:12 PM, Tom Lane wrote:
>> Looks good. If you're happy with that then I can undertake to add a
>> libperl.so probe based on AC_TRY_LINK with the unmodified value of
>> $perl_embed_ldflags.
> Go for it.
Done, we'll soon see how much the buildfarm likes it
On 01/09/2013 03:07 PM, Bruce Momjian wrote:
> How do we want to handle the case where VACUUM FULL clears the
> visibility map, causing loss of index-only scans?
>
> http://archives.postgresql.org/pgsql-performance/2012-11/msg00317.php
>
> Do we document this behavior or add a TODO item?
>
On 9 January 2013 23:12, Tom Lane wrote:
>> My view is it would fix the root cause of the problem, as explained.
>
> No; what it would do is provide a feature we don't currently have, ie
> the ability to let unprivileged users select a specific tablespace for
> temp files but not real tables. Th
Simon Riggs writes:
> On 9 January 2013 22:09, Tom Lane wrote:
>> [ shrug... ] That's weird, ie unlike the behavior of other privileges,
>> and it *still* doesn't fix any of the problems Stephen complained of.
> I think we're having a disconnection half hour?
> The privs could be seen as CREAT
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Simon Riggs writes:
> > On 9 January 2013 21:42, Tom Lane wrote:
> > I wasn't suggesting that we test for TEMP instead of CREATE; what I
> > meant was we would test for CREATE *OR* TEMP to give more options for
> > management.
>
> [ shrug... ] That's wei
How do we want to handle the case where VACUUM FULL clears the
visibility map, causing loss of index-only scans?
http://archives.postgresql.org/pgsql-performance/2012-11/msg00317.php
Do we document this behavior or add a TODO item?
--
Bruce Momjian http://momjian.us
Enterpr
On 2013-01-09 17:28:35 -0500, Tom Lane wrote:
> Andres Freund writes:
> > On 2013-01-09 15:43:19 -0500, Tom Lane wrote:
> >> I had thought of proposing that we code
> >> palloc() like this:
> >>
> >> void *
> >> palloc(Size size)
> >> {
> >> MemoryContext context = CurrentMemoryContext;
> >>
>
On 9 January 2013 22:09, Tom Lane wrote:
> Simon Riggs writes:
>> On 9 January 2013 21:42, Tom Lane wrote:
>>> If we were designing this from scratch I'd agree that a separate TEMP
>>> privilege would be a good thing. But bolting one on now is likely
>>> to create more problems than it fixes.
Andres Freund writes:
> I wonder whether it makes sense to "inline" the contents pstrdup()
> additionally? My gut feeling is not, but...
I don't recall ever having seen MemoryContextStrdup amount to much,
so probably not worth the extra code space.
regards, tom lane
--
Andres Freund writes:
> On 2013-01-09 15:43:19 -0500, Tom Lane wrote:
>> I had thought of proposing that we code
>> palloc() like this:
>>
>> void *
>> palloc(Size size)
>> {
>> MemoryContext context = CurrentMemoryContext;
>>
>> AssertArg(MemoryContextIsValid(context));
>>
>> if (!
On 2013-01-09 15:07:10 -0500, Tom Lane wrote:
> Andres Freund writes:
> > Well, I *did* benchmark it as noted elsewhere in the thread, but thats
> > obviously just machine (E5520 x 2) with one rather restricted workload
> > (pgbench -S -jc 40 -T60). At least its rather palloc heavy.
>
> > Here ar
On 2013-01-09 15:43:19 -0500, Tom Lane wrote:
> I wrote:
> > I then applied the palloc.h and mcxt.c hunks of your patch and rebuilt.
> > Now I get an average runtime of 1 ms, a full 2% faster, which is a
> > bit astonishing, particularly because the oprofile results haven't moved
> > much:
>
>
Simon Riggs writes:
> On 9 January 2013 21:42, Tom Lane wrote:
>> If we were designing this from scratch I'd agree that a separate TEMP
>> privilege would be a good thing. But bolting one on now is likely
>> to create more problems than it fixes. Particularly since it doesn't
>> actually fix an
Simon Riggs writes:
> Overall, the WAL record is MAXALIGN'd, so with 8 byte alignment we
> waste 4 bytes per record. Or put another way, if we could reduce
> record header by 4 bytes, we would actually reduce it by 8 bytes per
> record. So looking for ways to do that seems like a good idea.
I thi
On 9 January 2013 21:42, Tom Lane wrote:
> Simon Riggs writes:
>> On 9 January 2013 21:21, Tom Lane wrote:
>>> This sounds like rather a lot of work to create a behavior that doesn't
>>> solve the originally-complained-of usability problem. All it does is
>>> make things even more complicated,
On 01/09/2013 04:12 PM, Tom Lane wrote:
Andrew Dunstan writes:
On 01/09/2013 10:16 AM, Tom Lane wrote:
Actually, if we were to try to clean this up, I'd suggest moving that
logic into the configure script --- it's not apparent to me why it's
a good idea to be changing configure-determined val
On Wed, Jan 9, 2013 at 09:15:16PM +, Simon Riggs wrote:
> On 9 January 2013 21:02, Heikki Linnakangas wrote:
>
> >> OK, crazy idea, but can we just record xl_len as a difference against
> >> xl_tot_len, and shorten the xl_len field?
> >
> >
> > Hmm, so it would essentially be the length of a
Simon Riggs writes:
> On 9 January 2013 21:21, Tom Lane wrote:
>> This sounds like rather a lot of work to create a behavior that doesn't
>> solve the originally-complained-of usability problem. All it does is
>> make things even more complicated, and add an extra step for the DBA
>> who's just
On 9 January 2013 21:21, Tom Lane wrote:
> Simon Riggs writes:
>> On 9 January 2013 20:53, Stephen Frost wrote:
>>> * Simon Riggs (si...@2ndquadrant.com) wrote:
I think we need to allow a TEMP permission on tablespaces, so that you
aren't allowed to create normal objects but you can cr
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> IIRC, we do have mechanism now whereby a superuser can establish settings
> for SUSET variables via ALTER ROLE SET/ALTER DATABASE SET, and
> everything works as expected.
I'm not entirely convinced that it works as expected, at least for
temp_tablespaces cu
Simon Riggs writes:
> On 9 January 2013 20:53, Stephen Frost wrote:
>> * Simon Riggs (si...@2ndquadrant.com) wrote:
>>> I think we need to allow a TEMP permission on tablespaces, so that you
>>> aren't allowed to create normal objects but you can create TEMP
>>> objects and sort files there.
>>
On 9 January 2013 20:54, Heikki Linnakangas wrote:
> Here's a better idea:
>
> Let's keep xl_tot_len as it is, but move xl_len at the very end of the WAL
> record, after all the backup blocks. If there are no backup blocks, xl_len
> is omitted. Seems more robust to keep xl_tot_len, so that you re
On 9 January 2013 21:02, Heikki Linnakangas wrote:
>> OK, crazy idea, but can we just record xl_len as a difference against
>> xl_tot_len, and shorten the xl_len field?
>
>
> Hmm, so it would essentially be the length of all the backup blocks. perhaps
> rename it to xl_bkpblk_len.
>
> However, th
Andrew Dunstan writes:
> On 01/09/2013 10:16 AM, Tom Lane wrote:
>> Actually, if we were to try to clean this up, I'd suggest moving that
>> logic into the configure script --- it's not apparent to me why it's
>> a good idea to be changing configure-determined values in the Makefile.
>> But in any
On 9 January 2013 20:53, Stephen Frost wrote:
> * Simon Riggs (si...@2ndquadrant.com) wrote:
>> I think we need to allow a TEMP permission on tablespaces, so that you
>> aren't allowed to create normal objects but you can create TEMP
>> objects and sort files there.
>
> I agree that this would be
On 01/09/2013 10:16 AM, Tom Lane wrote:
Andrew Dunstan writes:
On 01/08/2013 10:37 PM, Tom Lane wrote:
We could try adding an AC_TRY_LINK test using perl_embed_ldflags,
but given the weird stuff happening to redefine that value on Windows
in plperl/GNUmakefile I think there's a serious risk o
Stephen Frost writes:
> * Tom Lane (t...@sss.pgh.pa.us) wrote:
>> We do have mechanism that forces search_path to be recomputed across
>> changes of active role, but it's expensive to do that, and it seems
>> of rather debatable value to do it here --- it certainly wouldn't
>> improve Stephen's or
On 09.01.2013 22:59, Bruce Momjian wrote:
On Wed, Jan 9, 2013 at 10:54:33PM +0200, Heikki Linnakangas wrote:
On 09.01.2013 22:36, Simon Riggs wrote:
The WAL record header starts with xl_tot_len, a 4 byte field. There is
also another field, xl_len. The difference is that xl_tot_len includes
the
On Wed, Jan 9, 2013 at 10:54:33PM +0200, Heikki Linnakangas wrote:
> On 09.01.2013 22:36, Simon Riggs wrote:
> >Overall, the WAL record is MAXALIGN'd, so with 8 byte alignment we
> >waste 4 bytes per record. Or put another way, if we could reduce
> >record header by 4 bytes, we would actually redu
On 09.01.2013 22:36, Simon Riggs wrote:
Overall, the WAL record is MAXALIGN'd, so with 8 byte alignment we
waste 4 bytes per record. Or put another way, if we could reduce
record header by 4 bytes, we would actually reduce it by 8 bytes per
record. So looking for ways to do that seems like a good
* Simon Riggs (si...@2ndquadrant.com) wrote:
> I think we need to allow a TEMP permission on tablespaces, so that you
> aren't allowed to create normal objects but you can create TEMP
> objects and sort files there.
I agree that this would be valuable. Would we end up needing to burn
another bit
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> We do have mechanism that forces search_path to be recomputed across
> changes of active role, but it's expensive to do that, and it seems
> of rather debatable value to do it here --- it certainly wouldn't
> improve Stephen's original problem, much less the
I wrote:
> I then applied the palloc.h and mcxt.c hunks of your patch and rebuilt.
> Now I get an average runtime of 1 ms, a full 2% faster, which is a
> bit astonishing, particularly because the oprofile results haven't moved
> much:
I studied the assembly code being generated for palloc(), a
On Thu, Jan 3, 2013 at 07:45:32PM +, Simon Riggs wrote:
> On 3 January 2013 18:35, Josh Berkus wrote:
> > Robert,
> >
> >> In my view, the biggest problem with recovery.conf is that the
> >> parameters in there are not GUCs, which means that all of the
> >> infrastructure that we've built for
Overall, the WAL record is MAXALIGN'd, so with 8 byte alignment we
waste 4 bytes per record. Or put another way, if we could reduce
record header by 4 bytes, we would actually reduce it by 8 bytes per
record. So looking for ways to do that seems like a good idea.
The WAL record header starts with
Stephen Frost writes:
> Alright, this isn't quite as open-and-shut as it may have originally
> seemed. We're apparently cacheing the temp tablespaces which should be
> used, even across set role's and security definer functions, which I
> would argue isn't correct.
Ah. Yeah, that would be true.
On 9 January 2013 02:42, Tom Lane wrote:
> Stephen Frost writes:
>> Here's what we're seeing:
>
>> postgresql.conf:
>> temp_tablespaces = 'temp_01,temp_02'
>
>> I have temp file logging on in postgresql.conf, so here's what we see:
>
>> LOG: temporary file: path "base/pgsql_tmp/pgsql_tmp9221.4",
Andres Freund writes:
> Well, I *did* benchmark it as noted elsewhere in the thread, but thats
> obviously just machine (E5520 x 2) with one rather restricted workload
> (pgbench -S -jc 40 -T60). At least its rather palloc heavy.
> Here are the numbers:
> before:
> #101646.763208 101350.361595 1
* Stephen Frost (sfr...@snowman.net) wrote:
> Attached are two test scripts and results from them. The gist of it is
> this:
Now with the attachements. Apologies about that. Note that you'll need
to create the temp tablespace first.
Thanks,
Stephen
test_tblspace.sql
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Does the user running CREATE INDEX have CREATE permission on those
> tablespaces? (A quick way to double check is to try to SET
> temp_tablespaces to that value explicitly.) The code will silently
> ignore any temp tablespaces you don't have such permissio
On 12/23/12 3:17 PM, Simon Riggs wrote:
We already have PrintBufferLeakWarning() for this, which might be a bit neater.
It does look like basically the same info. I hacked the code to
generate this warning all the time. Patch from Andres I've been using:
WARNING: refcount of buf 1 contain
On 9 January 2013 17:50, Jeff Janes wrote:
> On Wed, Jan 9, 2013 at 3:59 AM, Simon Riggs wrote:
>> On 9 November 2012 18:50, Jeff Janes wrote:
>>
>>> quadratic behavior in the resource owner/lock table
>>
>> I didn't want to let that particular phrase go by without saying
>> "exactly what behavi
On 01/09/2013 01:08:39 PM, Jan Urbański wrote:
> > I can see arguments to be made for both sides. I'm asking that you
> > think it through to the extent you deem necessary and make
> > changes or not. At that point it should be ready to send
> > to a committer. (I'll re-test first, if you make
Tom Lane schrieb:
>Andres Freund writes:
>> On 2013-01-09 11:27:46 -0500, Tom Lane wrote:
>>> I'd prefer posting a single message with the discussion and the
>>> patch(es). If you think it's helpful to split a patch into separate
>>> parts for reviewing, add multiple attachments. But my expe
On 12/12/12 20:21, Karl O. Pinc wrote:
There were 2 outstanding issue raised:
Is this useful enough/proceeding in the right direction to commit
now?
Should some of the logic be moved out of a subroutine and into the
calling code?
I can see arguments to be made for both sides. I'm asking
Andres Freund writes:
> On 2013-01-09 11:27:46 -0500, Tom Lane wrote:
>> I'd prefer posting a single message with the discussion and the
>> patch(es). If you think it's helpful to split a patch into separate
>> parts for reviewing, add multiple attachments. But my experience is
>> that such sepa
Claudio,
> Not really. I'm convinced, and not only for e_c_s, that
> autoconfiguration is within the realm of possibility.
Hey, if you can do it, my hat's off to you.
> In any case, as eavesdroppers can infer a cryptographic key by timing
> operations or measuring power consumption, I'm pretty s
On Wed, Jan 9, 2013 at 3:39 PM, Josh Berkus wrote:
>> It seems to me that pgfincore has the smarts we need to know about that,
>> and that Cédric has code and refenrences for making it work on all
>> platforms we care about (linux, bsd, windows for starters).
>
> Well, fincore is Linux-only, and f
Dimitri,
> It seems to me that pgfincore has the smarts we need to know about that,
> and that Cédric has code and refenrences for making it work on all
> platforms we care about (linux, bsd, windows for starters).
Well, fincore is Linux-only, and for that matter only more recent
versions of linu
On 2013-01-09 12:32:20 -0500, Tom Lane wrote:
> Andres Freund writes:
> > On 2013-01-09 11:57:35 -0500, Tom Lane wrote:
> >> My objection is that you're forcing *all* backend code to go through
> >> the trampoline. That probably has a negative impact on performance, and
> >> if you think it'll ge
Tom Lane writes:
> Well, the problem of "find out the box's physical RAM" is doubtless
> solvable if we're willing to put enough sweat and tears into it, but
> I'm dubious that it's worth the trouble. The harder part is how to know
> if the box is supposed to be dedicated to the database. Bear i
Peter Eisentraut writes:
> On 1/9/13 11:00 AM, Tom Lane wrote:
>> The libperl-dev package, as constituted, doesn't make any sense: it's
>> got the symlink which people need, and a very large static (.a) library
>> that most people don't need. Even worse, you can't tell without close
>> inspection
On Wed, Jan 9, 2013 at 3:59 AM, Simon Riggs wrote:
> On 9 November 2012 18:50, Jeff Janes wrote:
>
>> quadratic behavior in the resource owner/lock table
>
> I didn't want to let that particular phrase go by without saying
> "exactly what behaviour is that?", so we can discuss fixing that also.
Andres Freund writes:
> On 2013-01-09 11:57:35 -0500, Tom Lane wrote:
>> My objection is that you're forcing *all* backend code to go through
>> the trampoline. That probably has a negative impact on performance, and
>> if you think it'll get committed without a thorough proof that there's
>> no
Hi guys,
let me announce PostgreSQL hackfest, which is held during Developer
Conference 2013. Everyone from users, admins to hackers is welcome.
Few words about Developer Conference:
Developer Conference is an yearly conference for all Linux and JBoss
Developers, Admins and Linux users organi
On 1/9/13 11:00 AM, Tom Lane wrote:
> The libperl-dev package, as constituted, doesn't make any sense: it's
> got the symlink which people need, and a very large static (.a) library
> that most people don't need. Even worse, you can't tell without close
> inspection which of those files is actuall
On 1/9/13 10:30 AM, Christian Ullrich wrote:
> * Christoph Berg wrote:
>
>> Re: Tom Lane 2013-01-09 <9802.1357702...@sss.pgh.pa.us>
>
>>> and Python.h. However, adding one won't fix your problem on
>>> Debian-based distros, because for some wacko reason they put the
>>> headers and the shlib .so
On 2013-01-09 11:57:35 -0500, Tom Lane wrote:
> Andres Freund writes:
> > On 2013-01-09 11:37:46 -0500, Tom Lane wrote:
> >> I agree that what dirmod is doing is pretty ugly, but it's localized
> >> enough that I don't care particularly. (Really, the only reason it's
> >> a hack and not The Solut
Dimitri Fontaine escribió:
> Alvaro Herrera writes:
> >> Given the OID, we use the ObjectProperty[] structure to know which cache
> >> or catalog to scan in order to get the name and namespace of the object.
> >
> > The changes to make ObjectPropertyType visible to code outside
> > objectaddress.
Andres Freund writes:
> On 2013-01-09 11:37:46 -0500, Tom Lane wrote:
>> I agree that what dirmod is doing is pretty ugly, but it's localized
>> enough that I don't care particularly. (Really, the only reason it's
>> a hack and not The Solution is that at the moment there's only one
>> file doing
On 2013-01-09 11:27:46 -0500, Tom Lane wrote:
> Magnus Hagander writes:
> > On Wed, Jan 9, 2013 at 1:47 PM, Andres Freund
> > wrote:
> >> On 2013-01-09 13:34:12 +0100, Magnus Hagander wrote:
> >>> Am I the only one who finds this way of posting patches really annoying?
>
> >> Well, I unsurprisi
On 9 January 2013 16:27, Tom Lane wrote:
> I'm with Magnus. This is seriously annoying, especially when the
> "discussion" thread has a title not closely related to the "patch"
> emails. (It doesn't help any that the list server doesn't manage to
> deliver the emails in order, at least not to me
On 2013-01-09 11:37:46 -0500, Tom Lane wrote:
> Andres Freund writes:
> > On 2013-01-09 13:46:53 +0200, Heikki Linnakangas wrote:
> >> I don't understand the need for this change. Can't you just:
> >> #define palloc(s) pg_malloc(s)
> >> in the frontend context?
>
> > Yes, that would be possible, b
On Tue, Jan 8, 2013 at 4:16 AM, Peter Eisentraut wrote:
> On Mon, 2012-11-19 at 14:03 +0800, JiangGuiqing wrote:
>> hi
>>
>> I install postgresql-9.1.5 from source code on windows successfully.
>> But there is not "libecpg_compat.lib" and "libpgtypes.lib" in the
>> installed lib directory .
>> If
Andres Freund writes:
> On 2013-01-09 13:46:53 +0200, Heikki Linnakangas wrote:
>> I don't understand the need for this change. Can't you just:
>> #define palloc(s) pg_malloc(s)
>> in the frontend context?
> Yes, that would be possible, but imo its the inferior solution:
I'm with Heikki: in fact
Magnus Hagander writes:
> On Wed, Jan 9, 2013 at 1:47 PM, Andres Freund wrote:
>> On 2013-01-09 13:34:12 +0100, Magnus Hagander wrote:
>>> Am I the only one who finds this way of posting patches really annoying?
>> Well, I unsurprisingly don't ;)
> Yeah, that's not surprising :)
I'm with Magnu
Christian Ullrich writes:
> * Christoph Berg wrote:
>> Re: Tom Lane 2013-01-09 <9802.1357702...@sss.pgh.pa.us>
>>> I am unfamiliar with a good reason for doing that. (I can certainly
>>> see segregating the .a static library, or even not shipping it at
>>> all, but what's it save to leave out the
On Wed, Jan 9, 2013 at 4:56 PM, Fujii Masao wrote:
> Hi,
>
> The pg_basebackup in HEAD caused a segmentation fault in my box.
>
> $ pg_basebackup -D mmm
> Segmentation fault: 11
>
> The cause is that WriteRecoveryConf() is wrongly called even if -R option is
> not specified in pg_basebackup. Attac
Hi,
The pg_basebackup in HEAD caused a segmentation fault in my box.
$ pg_basebackup -D mmm
Segmentation fault: 11
The cause is that WriteRecoveryConf() is wrongly called even if -R option is
not specified in pg_basebackup. Attached patch fixes this problem.
Regards,
--
Fujii Masao
pg_baseb
* Christoph Berg wrote:
Re: Tom Lane 2013-01-09 <9802.1357702...@sss.pgh.pa.us>
and Python.h. However, adding one won't fix your problem on
Debian-based distros, because for some wacko reason they put the
headers and the shlib .so symlink in different packages, cf
http://packages.debian.org/
On 2013-01-09 11:45:12 -0300, Alvaro Herrera wrote:
>
> How hard is the backend hit by palloc being now an additional function
> call? Would it be a good idea to make it (and friends) STATIC_IF_INLINE?
Missed this at first...
I don't think there's any measurable hit now as there is no additiona
Andrew Dunstan writes:
> On 01/08/2013 10:37 PM, Tom Lane wrote:
>> We could try adding an AC_TRY_LINK test using perl_embed_ldflags,
>> but given the weird stuff happening to redefine that value on Windows
>> in plperl/GNUmakefile I think there's a serious risk of breaking Cygwin
>> builds. Sinc
On 2013-01-09 11:45:12 -0300, Alvaro Herrera wrote:
>
> How hard is the backend hit by palloc being now an additional function
> call? Would it be a good idea to make it (and friends) STATIC_IF_INLINE?
>
> > diff --git a/src/include/port/palloc.h b/src/include/port/palloc.h
> > new file mode 10064
On Wed, Jan 9, 2013 at 2:17 PM, Peter Eisentraut wrote:
> I would like to have something like ssh-askpass for libpq. The main
> reason is that I don't want to have passwords in plain text on disk,
> even if .pgpass is read protected. By getting the password from an
> external program, I can inte
How hard is the backend hit by palloc being now an additional function
call? Would it be a good idea to make it (and friends) STATIC_IF_INLINE?
> diff --git a/src/include/port/palloc.h b/src/include/port/palloc.h
> new file mode 100644
> index 000..a7900bf
> --- /dev/null
> +++ b/src/include
Slightly modified patch applied. This is my last planned pg_upgrade
change for 9.3.
---
On Mon, Jan 7, 2013 at 10:51:21PM -0500, Bruce Momjian wrote:
> Pg_upgrade by default (without --link) copies heap/index files from th
On 2013-01-09 22:23:25 +0900, Michael Paquier wrote:
> On Wed, Jan 9, 2013 at 9:54 PM, Magnus Hagander wrote:
>
> > On Wed, Jan 9, 2013 at 1:47 PM, Andres Freund
> > wrote:
> >
> Yeah, so far it's also just my opinion in the other direction :)
> > Hopefully, some others will have thoughts about
On Wednesday, January 09, 2013 5:49 PM Andres Freund wrote:
> On 2013-01-09 15:06:04 +0530, Amit Kapila wrote:
> > On Wednesday, January 09, 2013 2:28 PM Andres Freund wrote:
> > > On 2013-01-09 14:04:32 +0530, Amit Kapila wrote:
> > > > On Tuesday, January 08, 2013 8:57 PM Andres Freund wrote:
> >
On Wed, Jan 9, 2013 at 9:54 PM, Magnus Hagander wrote:
> On Wed, Jan 9, 2013 at 1:47 PM, Andres Freund
> wrote:
>
Yeah, so far it's also just my opinion in the other direction :)
> Hopefully, some others will have thoughts about it too.
>
Just giving my 2c here...
Instead of posting multiple 5~
I would like to have something like ssh-askpass for libpq. The main
reason is that I don't want to have passwords in plain text on disk,
even if .pgpass is read protected. By getting the password from an
external program, I can integrate libpq tools with the host system's key
chain or wallet thin
1 - 100 of 127 matches
Mail list logo
