> Personally, my biggest gripe about the way we do compression is that
> it's easy to detoast the same object lots of times. More generally,
> our in-memory representation of user data values is pretty much a
> mirror of our on-disk representation, even when that leads to excess
> conversions. Be
Hi Tomas,
On Wed, Jan 9, 2013 at 6:38 AM, Tomas Vondra wrote:
>> Well, you need to ensure that the initial palloc is an array of that
>> size.
>
> Oh, right - I forgot to modify the palloc() call. Thanks for spotting
> this. Attached is a patch with increased threshold and fixed palloc call.
OK,
Tom,
> I poked at this a bit more, and AFAICS your real beef is with Debian's
> whacked-out packaging decisions for Perl.
Ah, I do so much Ubuntu these days I didn't recognize the pattern.
I'll try to figure out a good place to document a warning about it.
--
Josh Berkus
PostgreSQL Experts Inc
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> The code definitely will complain if you try to interactively SET
> temp_tablespaces to a space you lack permissions for. However, there
> has never been a case in which people would hold still for warnings
> emitted as a consequence of values read from pos
Stephen Frost writes:
> If I can come up with a doc or similar patch, I'll post it, but I have
> to admit that the docs are pretty clear that you need create rights.
> Still, it seems a little odd that we don't complain in any way in this
> case. Perhaps a NOTICE when the temp_tablespaces value i
On Tue, 2013-01-08 at 23:38 -0500, Stephen Frost wrote:
> If I can come up with a doc or similar patch, I'll post it, but I have
> to admit that the docs are pretty clear that you need create rights.
> Still, it seems a little odd that we don't complain in any way in this
> case. Perhaps a NOTICE
On Tue, 2013-01-08 at 17:17 -0500, Stephen Frost wrote:
> Seriously tho, the argument for not putting these things into the
> various individual catalogs is that they'd create bloat and these
> items
> don't need to be performant. I would think that the kind of
> timestamps
> that we're talking ab
Tom,
* 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 per
On Mon, 2013-01-07 at 17:37 -0500, Robert Haas wrote:
> If we make the postgres database undroppable, unrenamable, and
> strictly read-only, I will happily support a proposal to consider it a
> system object. Until then, it's no more a system object than the
> public schema - which, you will note,
On Tue, 2013-01-08 at 22:37 -0500, 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. Since I lack access to
I wrote:
> The control flow in spgdoinsert.c is flat enough that the stack trace
> alone isn't much help in understanding the bug, I'm afraid.
BTW, something that possibly *would* help, since you seem to be able to
reproduce the bug easily, is to do that and then capture the values of
the local va
On January 07, 2013 7:53 PM Boszormenyi Zoltan wrote:
>Since my other patch against pg_basebackup is now committed,
>this patch doesn't apply cleanly, patch rejects 2 hunks.
>The fixed up patch is attached.
Patch is verified. Thanks for rebasing the patch.
Regards,
Hari babu.
--
Sent via pg
Josh Berkus writes:
> The way it is now (9.2.2):
> 1. set up a new system
> 2. forget to install libperl-dev
> 3. ./configure --with-perl
> 4. get no failures or warnings
> 5. make
> 6. make errors out on plperl.so
> The way it should work:
> - configure should error out, as it does with python.
On Mon, Jan 7, 2013 at 8:12 PM, Peter Eisentraut wrote:
> On Sat, 2013-01-05 at 15:34 +0100, Magnus Hagander wrote:
>> On Fri, Jan 4, 2013 at 3:36 AM, Josh Kupershmidt wrote:
>> > I propose slimming down the pg_dump README, keeping intact the
>> > introductory notes and details of the tar format.
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", size 204521472
> CONTEXT: SQL statement "create in
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Simon Riggs writes:
> > On 9 January 2013 00:04, Tom Lane wrote:
> >> I don't think it's a bug. What you seem to be proposing is that CREATE
> >> INDEX ought to ignore temp_tablespaces and instead always put its temp
> >> files in the tablespace where the
Hackers, clustering/replication aficionados:
The 4th Cluster Hackers Summit will take place on May 21st, in Ottawa,
Canada. It will be held in a meeting room somewhere near the University
of Ottawa Campus.
Tentatively, we are planning a half-day event, back-to-back with a
PostgresXC workshop.
M
Josh Berkus writes:
> The way it is now (9.2.2):
> 1. set up a new system
> 2. forget to install libperl-dev
> 3. ./configure --with-perl
> 4. get no failures or warnings
> 5. make
> 6. make errors out on plperl.so
> The way it should work:
> - configure should error out, as it does with python.
All,
>> 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 in mind
>
On Tue, Jan 8, 2013 at 5:51 PM, Josh Berkus wrote:
> Daniel,
>
>
>> To briefly reiterate my objection, I observed that one may want to
>> enter a case of cyclicality on a temporary basis -- to assist with
>> some intermediate states in remastering, and it'd be nice if Postgres
>> didn't try to get
Daniel,
> To briefly reiterate my objection, I observed that one may want to
> enter a case of cyclicality on a temporary basis -- to assist with
> some intermediate states in remastering, and it'd be nice if Postgres
> didn't try to get in the way of that.
I don't think it *should* fail. I thi
The way it is now (9.2.2):
1. set up a new system
2. forget to install libperl-dev
3. ./configure --with-perl
4. get no failures or warnings
5. make
6. make errors out on plperl.so
The way it should work:
- configure should error out, as it does with python.
--
Josh Berkus
PostgreSQL Experts I
On 01/08/2013 08:08 PM, Tom Lane wrote:
Robert Haas writes:
On Tue, Jan 8, 2013 at 7:17 PM, Tom Lane wrote:
... And I don't especially like the idea of trying to
make it depend directly on the box's physical RAM, for the same
practical reasons Robert mentioned.
For the record, I don't beli
On Mon, Dec 31, 2012 at 1:38 AM, Pavan Deolasee wrote:
> On Sun, Dec 30, 2012 at 12:38 AM, Stephen Frost
> wrote:
> > * Pavan Deolasee (pavan.deola...@gmail.com) wrote:
> >> On Fri, Sep 7, 2012 at 6:06 PM, Kevin Grittner
> >> > That makes sense to me. The reason I didn't make that change when I
Robert Haas writes:
> On Tue, Jan 8, 2013 at 7:17 PM, Tom Lane wrote:
>> ... And I don't especially like the idea of trying to
>> make it depend directly on the box's physical RAM, for the same
>> practical reasons Robert mentioned.
> For the record, I don't believe those problems would be part
On Tue, Jan 8, 2013 at 7:57 PM, Tom Lane wrote:
> Robert Haas writes:
>> I was thinking more about a sprintf()-type function that only
>> understands a handful of escapes, but adds the additional and novel
>> escapes %I (quote as identifier) and %L (quote as literal). I think
>> that would allow
Robert Haas writes:
> I was thinking more about a sprintf()-type function that only
> understands a handful of escapes, but adds the additional and novel
> escapes %I (quote as identifier) and %L (quote as literal). I think
> that would allow a great deal of code simplification, and it'd be more
On Tue, Jan 8, 2013 at 7:17 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Tue, Jan 8, 2013 at 9:53 AM, Claudio Freire
>> wrote:
>>> Rather, I'd propose the default setting should be "-1" or something
>>> "default" and "automagic" that works most of the time (but not all).
>
>> A cruder heuris
On Tue, Jan 8, 2013 at 6:23 PM, Tom Lane wrote:
> Robert Haas writes:
>> And functions that return static buffers are evil incarnate. I've
>> spent way too much of my life dealing with the supreme idiocy that is
>> fmtId(). If someone ever finds a way to make that go away, I will buy
>> them a
Simon Riggs writes:
> On 9 January 2013 00:04, Tom Lane wrote:
>> I don't think it's a bug. What you seem to be proposing is that CREATE
>> INDEX ought to ignore temp_tablespaces and instead always put its temp
>> files in the tablespace where the finished index will reside.
> I don't think tha
Robert Haas writes:
> On Tue, Jan 8, 2013 at 9:53 AM, Claudio Freire wrote:
>> Rather, I'd propose the default setting should be "-1" or something
>> "default" and "automagic" that works most of the time (but not all).
> A cruder heuristic that might be useful is 3 * shared_buffers.
Both parts
On 9 January 2013 00:04, Tom Lane wrote:
> I don't think it's a bug. What you seem to be proposing is that CREATE
> INDEX ought to ignore temp_tablespaces and instead always put its temp
> files in the tablespace where the finished index will reside.
I don't think that's what he said.
--
Sim
Stephen Frost writes:
> * Bruce Momjian (br...@momjian.us) wrote:
>> Well, our docs for temp_tablespaces says:
>> This variable specifies tablespaces in which to create temporary
>> objects (temp tables and indexes on temp tables) when a
>> CREATE command does not explicitly specify a tablespace.
Robert Haas writes:
> And functions that return static buffers are evil incarnate. I've
> spent way too much of my life dealing with the supreme idiocy that is
> fmtId(). If someone ever finds a way to make that go away, I will buy
> them a beverage of their choice at the next conference we're b
On Tue, Jan 8, 2013 at 05:23:36PM -0500, Robert Haas wrote:
> > Rather, I'd propose the default setting should be "-1" or something
> > "default" and "automagic" that works most of the time (but not all).
>
> +1. I've found that a value of three-quarters of system memory works
> pretty well most
On 2013-01-08 17:28:33 -0500, Robert Haas wrote:
> On Tue, Jan 8, 2013 at 3:00 PM, Andres Freund wrote:
> > Uhm, we don't have & need palloc support and I don't think
> > relpathbackend() is a good justification for adding it.
>
> FWIW, I'm with Tom on this one. Any meaningful code sharing is goi
Robert Haas escribió:
> And functions that return static buffers are evil incarnate. I've
> spent way too much of my life dealing with the supreme idiocy that is
> fmtId().
+1
> If someone ever finds a way to make that go away, I will buy
> them a beverage of their choice at the next conference
I wrote:
> After digging around a bit, I can find only one place where it looks
> like somebody might be messing with the LockMethodProcLockHash table
> while not holding the appropriate lock-partition LWLock(s):
> 1. VirtualXactLock finds target xact holds its VXID lock fast-path.
> 2. VirtualXac
On Tue, Jan 8, 2013 at 3:00 PM, Andres Freund wrote:
> Uhm, we don't have & need palloc support and I don't think
> relpathbackend() is a good justification for adding it.
FWIW, I'm with Tom on this one. Any meaningful code sharing is going
to need that, so we might as well bite the bullet.
And
On Tue, Jan 8, 2013 at 9:53 AM, Claudio Freire wrote:
> On Tue, Jan 8, 2013 at 11:39 AM, Merlin Moncure wrote:
>> Reference:
>> http://postgresql.1045698.n5.nabble.com/Simple-join-doesn-t-use-index-td5738689.html
>>
>> This is a pretty common gotcha: user sets shared_buffers but misses
>> the es
* Bruce Momjian (br...@momjian.us) wrote:
> On Tue, Jan 8, 2013 at 05:09:47PM -0500, Stephen Frost wrote:
> > Greetings,
> >
> > We were surprised recently to note that the temp files that are
> > created during a CREATE INDEX don't go into either a temp tablespace
> > set for the user or i
* Pavel Stehule (pavel.steh...@gmail.com) wrote:
> 2013/1/8 Peter Eisentraut :
> > On 1/5/13 11:04 AM, Stephen Frost wrote:
> > Yeah, actually, the other day I was thinking we should get rid of all
> > the system catalogs and use a big EAV-like schema instead. We're not
> > getting any relational-
On Tue, Jan 8, 2013 at 05:09:47PM -0500, Stephen Frost wrote:
> Greetings,
>
> We were surprised recently to note that the temp files that are
> created during a CREATE INDEX don't go into either a temp tablespace
> set for the user or into the tablespace which the CREATE INDEX
> specifie
On Tue, Jan 8, 2013 at 9:51 AM, Claudio Freire wrote:
> On Tue, Jan 8, 2013 at 10:20 AM, Robert Haas wrote:
>> On Tue, Jan 8, 2013 at 4:04 AM, Takeshi Yamamuro
>> wrote:
>>> Apart from my patch, what I care is that the current one might
>>> be much slow against I/O. For example, when compressing
2013/1/8 Peter Eisentraut :
> On 1/5/13 11:04 AM, Stephen Frost wrote:
>> Creating a separate catalog (or two) every time we want to track XYZ for
>> all objects is rather overkill... Thinking about this a bit more, and
>> noting that pg_description/shdescription more-or-less already exist as a
>>
=?gb2312?B?wO66o8H6?= writes:
> I am very excited to say that I may have created a test case!
I've been running variants of this example for most of the afternoon,
and have not seen a failure :-(. So I'm afraid there is some aspect
of your situation that you've not provided enough information to
Greetings,
We were surprised recently to note that the temp files that are
created during a CREATE INDEX don't go into either a temp tablespace
set for the user or into the tablespace which the CREATE INDEX
specifies. Instead, they go only into base/pgsql_tmp/. This doesn't
allow for a
On 1/5/13 11:04 AM, Stephen Frost wrote:
> Creating a separate catalog (or two) every time we want to track XYZ for
> all objects is rather overkill... Thinking about this a bit more, and
> noting that pg_description/shdescription more-or-less already exist as a
> framework for tracking 'something
On Tue, Jan 8, 2013 at 11:51 AM, Simon Riggs wrote:
> On 8 January 2013 18:46, Josh Berkus wrote:
>> On 1/5/13 1:21 PM, Peter Geoghegan wrote:
>>>
>>> On 21 December 2012 14:08, Robert Haas wrote:
I'm sure it's possible; I don't *think* it's terribly easy.
>>>
>>>
>>> I'm inclined to a
On 01/08/2013 04:32 PM, Merlin Moncure wrote:
On Tue, Jan 8, 2013 at 3:19 PM, Peter Eisentraut wrote:
On 1/7/13 5:15 PM, Andrew Dunstan wrote:
You (Merlin) have kindly volunteered to work on documentation, so before
we go too far with that any bikeshedding on names, or on the
functionality be
I wrote:
> This is a bit disturbing:
> http://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=bushpig&dt=2013-01-07%2019%3A15%3A02
> ...
> The assertion failure seems to indicate that the number of
> LockMethodProcLockHash entries found by hash_seq_search didn't match the
> number that had been cou
On 8.1.2013 22:30, Alvaro Herrera wrote:
> Tomas Vondra wrote:
>> On 8.1.2013 03:47, Shigeru Hanada wrote:
>
> * +1 for Alvaro's suggestion about avoiding palloc traffic by starting
> with 8 elements or so.
Done.
>>>
>>> Not yet. Initial size of srels array is still 1 element.
>
On Tue, Jan 8, 2013 at 3:19 PM, Peter Eisentraut wrote:
> On 1/7/13 5:15 PM, Andrew Dunstan wrote:
>> You (Merlin) have kindly volunteered to work on documentation, so before
>> we go too far with that any bikeshedding on names, or on the
>> functionality being provided, should now take place.
>
>
You can use COPY from a stored procedure, but only to and from files.
I think that's in the chocolate fireguard realm though as far as
efficiency for this sort of scenario goes, even if its handled by
retaining an mmap'd file as workspace.
If SPI provided a way to perform a copy to a temp
Tomas Vondra wrote:
> On 8.1.2013 03:47, Shigeru Hanada wrote:
> >>> * +1 for Alvaro's suggestion about avoiding palloc traffic by starting
> >>> with 8 elements or so.
> >>
> >> Done.
> >
> > Not yet. Initial size of srels array is still 1 element.
>
> I've checked the patch and I see there 'm
On 1/8/13 11:55 AM, Daniele Varrazzo wrote:
>>> >> 'bar': '22'}]>
> This looks more a repr-style format to me (if you implement repr but
> not str, the latter will default to the former).
The repr style was the only guideline I found. There is no guideline
for how str should look like when it's n
On Tue, Jan 8, 2013 at 10:23 PM, Peter Eisentraut wrote:
> On 1/8/13 4:32 AM, Magnus Hagander wrote:
>> How does it work if there are many rows in there? Say the result
>> contains 10,000 rows - will the string contain all of them? If so,
>> might it be worthwhile to cap the number of rows shown a
On 1/8/13 4:32 AM, Magnus Hagander wrote:
> How does it work if there are many rows in there? Say the result
> contains 10,000 rows - will the string contain all of them? If so,
> might it be worthwhile to cap the number of rows shown and then follow
> with a "..." or something?
I don't think so.
On 1/7/13 5:15 PM, Andrew Dunstan wrote:
> You (Merlin) have kindly volunteered to work on documentation, so before
> we go too far with that any bikeshedding on names, or on the
> functionality being provided, should now take place.
Hmm, I was going to say, this patch contains no documentation, s
On 2013-01-08 23:02:15 +0200, Heikki Linnakangas wrote:
> On 08.01.2013 23:00, Andres Freund wrote:
> >>Note that the xlogreader facility doesn't need any more emulation. I'm quite
> >>satisfied with that part of the patch now. However, the rmgr desc routines
> >>do, and I'm not very happy with tho
On Tue, Jan 8, 2013 at 04:11:41PM -0500, Peter Eisentraut wrote:
> On 1/8/13 4:04 PM, Bruce Momjian wrote:
> > On Tue, Jan 8, 2013 at 01:08:44PM -0500, Tom Lane wrote:
> >> In a tree in which I previously ran "make check" in contrib/pg_upgrade:
> >>
> >> $ make -s distclean
> >> $ git status
> >>
On Tue, Jan 8, 2013 at 04:08:42PM -0500, Tom Lane wrote:
> Bruce Momjian writes:
> > On Tue, Jan 8, 2013 at 01:08:44PM -0500, Tom Lane wrote:
> >> In a tree in which I previously ran "make check" in contrib/pg_upgrade:
> >>
> >> $ make -s distclean
> >> $ git status
> >> # On branch master
> >>
On 1/8/13 4:04 PM, Bruce Momjian wrote:
> On Tue, Jan 8, 2013 at 01:08:44PM -0500, Tom Lane wrote:
>> In a tree in which I previously ran "make check" in contrib/pg_upgrade:
>>
>> $ make -s distclean
>> $ git status
>> # On branch master
>> # Untracked files:
>> # (use "git add ..." to include i
On 2013-01-08 15:45:07 -0500, Tom Lane wrote:
> Andres Freund writes:
> > To what extent do you want palloc et al. emulation? Provide actual pools
> > or just make redirect to malloc and provide the required symbols (at the
> > very least CurrentMemoryContext)?
>
> I don't see any need for memory
Bruce Momjian writes:
> On Tue, Jan 8, 2013 at 01:08:44PM -0500, Tom Lane wrote:
>> In a tree in which I previously ran "make check" in contrib/pg_upgrade:
>>
>> $ make -s distclean
>> $ git status
>> # On branch master
>> # Untracked files:
>> # (use "git add ..." to include in what will be c
On Tue, Jan 8, 2013 at 01:08:44PM -0500, Tom Lane wrote:
> In a tree in which I previously ran "make check" in contrib/pg_upgrade:
>
> $ make -s distclean
> $ git status
> # On branch master
> # Untracked files:
> # (use "git add ..." to include in what will be committed)
> #
> # contrib/
On 08.01.2013 23:00, Andres Freund wrote:
Note that the xlogreader facility doesn't need any more emulation. I'm quite
satisfied with that part of the patch now. However, the rmgr desc routines
do, and I'm not very happy with those. Not sure what to do about it. As you
said, we could add enough i
On 2013-01-08 22:47:43 +0200, Heikki Linnakangas wrote:
> On 08.01.2013 22:39, Andres Freund wrote:
> >On 2013-01-08 15:27:23 -0500, Tom Lane wrote:
> >>Andres Freund writes:
> >>>Uhm, we don't have& need palloc support and I don't think
> >>>relpathbackend() is a good justification for adding it
On 8.1.2013 03:47, Shigeru Hanada wrote:
>>> * naming of DROP_RELATIONS_BSEARCH_LIMIT (or off-by-one bug?)
>>> IIUC bsearch is used when # of relations to be dropped is *more* than
>>> the value of DROP_RELATIONS_BSEARCH_LIMIT (10). IMO this behavior is
>>> not what the macro name implies; I thoug
Alvaro Herrera writes:
> Andres Freund wrote:
>> Sorry, misremembered the problem somewhat. The problem is that code that
>> includes postgres.h atm ends up with ExceptionalCondition() et
>> al. declared even if FRONTEND is defined. So if anything uses an assert
>> you need to provide wrappers for
On 08.01.2013 22:39, Andres Freund wrote:
On 2013-01-08 15:27:23 -0500, Tom Lane wrote:
Andres Freund writes:
Uhm, we don't have& need palloc support and I don't think
relpathbackend() is a good justification for adding it.
I've said from the very beginning of this effort that it would be
i
Andres Freund writes:
> To what extent do you want palloc et al. emulation? Provide actual pools
> or just make redirect to malloc and provide the required symbols (at the
> very least CurrentMemoryContext)?
I don't see any need for memory pools, at least not for frontend
applications of the curr
On 2013-01-08 17:36:19 -0300, Alvaro Herrera wrote:
> Andres Freund wrote:
> > On 2013-01-08 14:35:12 -0500, Tom Lane wrote:
> > > Andres Freund writes:
> > > > On 2013-01-08 14:25:06 -0500, Tom Lane wrote:
> > > >> This patch seems unnecessary given that we already put a version of
> > > >> Asse
On 2013-01-08 15:27:23 -0500, Tom Lane wrote:
> Andres Freund writes:
> > Uhm, we don't have & need palloc support and I don't think
> > relpathbackend() is a good justification for adding it.
>
> I've said from the very beginning of this effort that it would be
> impossible to share any meaningf
Tom Lane wrote:
> Andres Freund writes:
> > Uhm, we don't have & need palloc support and I don't think
> > relpathbackend() is a good justification for adding it.
>
> I've said from the very beginning of this effort that it would be
> impossible to share any meaningful amount of code between fron
Andres Freund wrote:
> On 2013-01-08 14:35:12 -0500, Tom Lane wrote:
> > Andres Freund writes:
> > > On 2013-01-08 14:25:06 -0500, Tom Lane wrote:
> > >> This patch seems unnecessary given that we already put a version of
> > >> Assert()
> > >> into postgres_fe.h.
> >
> > > The problem is that s
On 8 January 2013 19:53, David Fetter wrote:
> On Tue, Jan 08, 2013 at 10:46:12AM -0800, Josh Berkus wrote:
>> On 1/5/13 1:21 PM, Peter Geoghegan wrote:
>> >On 21 December 2012 14:08, Robert Haas wrote:
>> >>I'm sure it's possible; I don't *think* it's terribly easy.
>> >
>> >I'm inclined to agre
Andres Freund writes:
> Uhm, we don't have & need palloc support and I don't think
> relpathbackend() is a good justification for adding it.
I've said from the very beginning of this effort that it would be
impossible to share any meaningful amount of code between frontend and
backend environment
On 01/08/2013 03:07 PM, james wrote:
Yes - but I don't think I can use COPY from a stored proc context can
I? If I could use binary COPY from a stored proc that has received a
binary param and unpacked to the data, it would be handy.
You can use COPY from a stored procedure, but only to
On 01/08/2013 03:12 PM, Andrew Dunstan wrote:
On 01/08/2013 09:58 AM, Andrew Dunstan wrote:
If you have such a datum, parsing it involves having it in memory and
then taking a copy (I wonder if we could avoid that step - will take
a look).
Here is a Proof Of Concept patch against my deve
On 2013-01-08 14:35:12 -0500, Tom Lane wrote:
> Andres Freund writes:
> > On 2013-01-08 14:25:06 -0500, Tom Lane wrote:
> >> This patch seems unnecessary given that we already put a version of
> >> Assert()
> >> into postgres_fe.h.
>
> > The problem is that some (including existing) pieces of co
On 01/08/2013 09:58 AM, Andrew Dunstan wrote:
If you have such a datum, parsing it involves having it in memory and
then taking a copy (I wonder if we could avoid that step - will take a
look).
Here is a Proof Of Concept patch against my development tip on what's
involved in getting the J
I had been wondering how to do such an insertion efficiently in the context of
SPI, but it seems that there is no SPI_copy equiv that would allow a query
parse and plan to be avoided.
Your query above would need to be planned too, although the plan will be
trivial.
Ah yes, I meant that I h
On 2013-01-08 14:53:29 -0500, Tom Lane wrote:
> Andres Freund writes:
> > On 2013-01-08 14:28:14 -0500, Tom Lane wrote:
> >> I'm 100% unimpressed with making relpathbackend return a pointer to a
> >> static buffer. Who's to say whether that won't create bugs due to
> >> overlapping usages?
>
> >
On Tue, Jan 08, 2013 at 10:46:12AM -0800, Josh Berkus wrote:
> On 1/5/13 1:21 PM, Peter Geoghegan wrote:
> >On 21 December 2012 14:08, Robert Haas wrote:
> >>I'm sure it's possible; I don't *think* it's terribly easy.
> >
> >I'm inclined to agree that this isn't a terribly pressing issue.
> >Certa
Andres Freund writes:
> On 2013-01-08 14:28:14 -0500, Tom Lane wrote:
>> I'm 100% unimpressed with making relpathbackend return a pointer to a
>> static buffer. Who's to say whether that won't create bugs due to
>> overlapping usages?
> I say it ;). I've gone through all callers and checked. Not
On 8 January 2013 18:46, Josh Berkus wrote:
> On 1/5/13 1:21 PM, Peter Geoghegan wrote:
>>
>> On 21 December 2012 14:08, Robert Haas wrote:
>>>
>>> I'm sure it's possible; I don't *think* it's terribly easy.
>>
>>
>> I'm inclined to agree that this isn't a terribly pressing issue.
>> Certainly, t
On 2013-01-08 14:28:14 -0500, Tom Lane wrote:
> Andres Freund writes:
> maxpg> From: Andres Freund
> > relpathbackend() (via some of its wrappers) is used in *_desc routines
> > which we
> > want to be useable without a backend environment arround.
>
> I'm 100% unimpressed with making relpathbac
Andres Freund writes:
> On 2013-01-08 14:25:06 -0500, Tom Lane wrote:
>> This patch seems unnecessary given that we already put a version of Assert()
>> into postgres_fe.h.
> The problem is that some (including existing) pieces of code need to
> include postgres.h itself, those can't easily inclu
On 2013-01-08 14:25:06 -0500, Tom Lane wrote:
> Andres Freund writes:
> > From: Andres Freund
> > c.h already had parts of the assert support (StaticAssert*) and its the
> > shared
> > file between postgres.h and postgres_fe.h. This makes it easier to build
> > frontend programs which have to do
Andres Freund writes:
maxpg> From: Andres Freund
> relpathbackend() (via some of its wrappers) is used in *_desc routines which
> we
> want to be useable without a backend environment arround.
I'm 100% unimpressed with making relpathbackend return a pointer to a
static buffer. Who's to say whe
On 2013-01-08 20:09:42 +0100, Andres Freund wrote:
> From: Andres Freund
> Subject: [PATCH] xlogreader-v4
> In-Reply-To:
>
> Hi,
>
> this is the latest and obviously best version of xlogreader & xlogdump with
> changes both from Heikki and me.
>
> Changes:
> * windows build support for pg_xlog
Andres Freund writes:
> From: Andres Freund
> c.h already had parts of the assert support (StaticAssert*) and its the shared
> file between postgres.h and postgres_fe.h. This makes it easier to build
> frontend programs which have to do the hack.
This patch seems unnecessary given that we alread
On 8 January 2013 19:15, Thom Brown wrote:
> On 8 January 2013 19:09, Andres Freund wrote:
>
>> From: Andres Freund
>> Subject: [PATCH] xlogreader-v4
>> In-Reply-To:
>>
>> Hi,
>>
>> this is the latest and obviously best version of xlogreader & xlogdump
>> with
>> changes both from Heikki and me
On 8 January 2013 19:09, Andres Freund wrote:
> From: Andres Freund
> Subject: [PATCH] xlogreader-v4
> In-Reply-To:
>
> Hi,
>
> this is the latest and obviously best version of xlogreader & xlogdump with
> changes both from Heikki and me.
Aren't you forgetting something?
--
Thom
From: Andres Freund
Authors: Andres Freund, Heikki Linnakangas
---
contrib/Makefile | 1 +
contrib/pg_xlogdump/Makefile | 37 +++
contrib/pg_xlogdump/compat.c | 58
contrib/pg_xlogdump/pg_xlogdump.c | 654 ++
contrib/pg_xlog
From: Andres Freund
---
src/backend/access/rmgrdesc/standbydesc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/backend/access/rmgrdesc/standbydesc.c
b/src/backend/access/rmgrdesc/standbydesc.c
index c38892b..5fb6f54 100644
--- a/src/backend/access/rmgrdesc/standbydesc
From: Andres Freund
relpathbackend() (via some of its wrappers) is used in *_desc routines which we
want to be useable without a backend environment arround.
Change signature to return a 'const char *' to make misuse easier to
detect. That necessicates also changing the 'FileName' typedef to 'co
From: Andres Freund
c.h already had parts of the assert support (StaticAssert*) and its the shared
file between postgres.h and postgres_fe.h. This makes it easier to build
frontend programs which have to do the hack.
---
src/include/c.h | 65
From: Andres Freund
Subject: [PATCH] xlogreader-v4
In-Reply-To:
Hi,
this is the latest and obviously best version of xlogreader & xlogdump with
changes both from Heikki and me.
Changes:
* windows build support for pg_xlogdump
* xlogdump moved to contrib
* xlogdump option parsing enhancements
*
1 - 100 of 123 matches
Mail list logo
