I have to say that as a 3rd party observer it is quite obvious to
understand why the PostgreSQL software is so good - people are very
passionate about the work they are doing. However, in this instance,
as a by-stander, it seems that there is a lot of energy being spent on
pointing fingers. At the
2010/2/11 Oleg Bartunov :
> This is very disgraceful from my point of view and reflects real problem
> in scheduling of CF. The patch was submitted Nov 23 2009, discussed and
> reworked Nov 25. Long holidays in December-January, probably are reason why
> there were no any movement on reviewing the
Oleg Bartunov writes:
> This is very disgraceful from my point of view and reflects real problem
> in scheduling of CF. The patch was submitted Nov 23 2009, discussed and
> reworked Nov 25. Long holidays in December-January, probably are reason why
> there were no any movement on reviewing the pa
> The only case that I think still has any merit is where you get a
> significantly better plan with known parameter values than without.
> The projected-cost threshold might be a reasonable approach for
> attacking that, ie, if estimated cost of generic plan exceeds X
> then take the time to build
This is very disgraceful from my point of view and reflects real problem
in scheduling of CF. The patch was submitted Nov 23 2009, discussed and
reworked Nov 25. Long holidays in December-January, probably are reason why
there were no any movement on reviewing the patch. People with
inspiration
>> I'd like to see a requirement for the use of PQexecParams() over PQexec() -
>> even when using libpq's PQescapeStringConn(), PQexec() makes me uneasy.
>
>Such a rule seems pretty entirely pointless, unless you have a way to
>enforce that the query string passed to the function hasn't been
>asse
Tom Lane wrote:
If you feel that a BSD/MIT license is a must-have for your purposes,
you're certainly free to push development of one of the other driver
projects instead, and to try to organize some other people to help.
I don't believe anyone is trying to funnel all development effort into
psyc
Andrew McNamara writes:
>> That's just a matter of prioritizing the issues. Put the big ones at
>> the top, the trivia at the bottom, [...]
> I'd like to see a requirement for the use of PQexecParams() over PQexec() -
> even when using libpq's PQescapeStringConn(), PQexec() makes me uneasy.
S
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Wed, Feb 10, 2010 at 04:49:59PM -0800, Ragi Y. Burhum wrote:
> Hello,
>
> I noticed this morning that the k nearest neighbor gist patch
> https://commitfest.postgresql.org/action/patch_view?id=230 was still being
> considered for inclusion in 9. Sa
>That's just a matter of prioritizing the issues. Put the big ones at
>the top, the trivia at the bottom, [...]
I'd like to see a requirement for the use of PQexecParams() over PQexec() -
even when using libpq's PQescapeStringConn(), PQexec() makes me uneasy.
--
Andrew McNamara, Senior Develo
u235sentinel escreveu:
> I'm curious what context you were expecting and which group this should
> go to. I've posted similar questions in the other groups and they
> seem... lost at times.
>
What group? AFAICS this question belongs to -general. What about starting to
show us the definition of m_
Kevin Ar18 wrote:
Based on that, I guess my question is what would it have taken to have
picked one of BSD/MIT projects and working with those people instead?
In other words, what key things affected the decision for psycopg?
What areas is it so far ahead in or that would have just been too
Tom Lane wrote:
u235sentinel writes:
I have a strange problem we noticed the other day with triggers. We're
running 8.3.3 on Solaris 10 (intel) and have a feed that comes in
regularly to populate a table we're working on. The feed works just
fine inserting rows however the following trig
Bruce Momjian writes:
> Can someone explain to me why we only do "delayed binding" for unnamed
> prepared queries?
It was a way of shoehorning in some driver control over the behavior
without the protocol bump that would be involved in adding an actual
option to Parse messages.
> Well, all else being equal we'd certainly prefer a library that was
> licensed more like the core Postgres database. However, we don't have
> infinite resources, and an LGPL license is not a showstopper (at least
> not to the people who seem to be willing to work on this problem).
> The attract
Tom Lane escreveu:
> I'm still quite dubious about the usefulness, but I could live with this
> if someone explains to me how the printout is going to stay within 24x80
> given the inevitable growth in number of configure options ...
>
AFAICS, we have > 40 configure options. If we want this to fit
Tom Lane wrote:
> Bruce Momjian writes:
> > Right now, log_error_verbosity displays the source code error location
> > in this format:
>
> > LOCATION: parserOpenTable, parse_relation.c:858
>
> > I think it would be clearer to add '()' next to the function name. We
> > use '() to display fu
Kevin Ar18 writes:
> When I first heard about the endeavor, I thought the goal was to take
> one or several of the non-copyleft projects, which were rather
> unfocused, and work with those teams to produce a really good
> implementation for Python. However, as I understand it (based on what
> Gre
Tom Lane wrote:
> Robert Haas writes:
> > On Tue, Feb 9, 2010 at 7:08 AM, Jeroen Vermeulen wrote:
> >> Periodically re-plan prepared statements on EXECUTE. ?This is also a chance
> >> for queries that were being re-planned every time to go back to a generic
> >> plan.
>
> > The most common probl
Kris Jurka wrote:
>
> The JDBC driver has two methods of disabling permanently planned prepared
> statements:
>
> 1) Use the version two frontend/backend protocol via adding
> protocolVersion=2 to your URL. This interpolates all parameters into
> the query on the client side.
>
> 2) Execute
On Wed, Feb 10, 2010 at 9:17 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Wed, Feb 10, 2010 at 3:30 PM, Alvaro Herrera
>> wrote:
>>> If this doesn't fit in 24x80 maybe we need to find a more compact way to
>>> display things.
>
>> +1. I wouldn't mind a one-line summary, but a two page summar
Jim Nasby writes:
> On Jan 13, 2010, at 9:32 PM, Tom Lane wrote:
>> Jim Nasby writes:
>>> I noticed odd stuff showing up when I fired up an 8.3 psql after using psql
>>> in HEAD. It shows up in .psql_history as well:
>>
>> Platform? readline version?
> This is on snow leopard. FWIW it's still
On Monday 08 February 2010 05:53:23 Robert Haas wrote:
> On Sun, Feb 7, 2010 at 10:09 PM, Alvaro Herrera
>
> wrote:
> > Andres Freund escribió:
> >> I personally think the fsync on the directory should be added to the
> >> stable branches - other opinions?
> >> If wanted I can prepare patches for
Robert Haas writes:
> On Wed, Feb 10, 2010 at 3:30 PM, Alvaro Herrera
> wrote:
>> If this doesn't fit in 24x80 maybe we need to find a more compact way to
>> display things.
> +1. I wouldn't mind a one-line summary, but a two page summary seems
> like a lot.
So it seems there's some consensus
u235sentinel writes:
> I have a strange problem we noticed the other day with triggers. We're
> running 8.3.3 on Solaris 10 (intel) and have a feed that comes in
> regularly to populate a table we're working on. The feed works just
> fine inserting rows however the following trigger stops the
On 2010-02-11 02:13 +0200, I wrote:
> On 2010-02-11 01:58 +0200, Robert Haas wrote:
>> I have to admit I've been starting to have a feeling over the last
>> couple of days that this patch isn't going to make it for 9.0... but
>> obviously I'm in no position to guarantee anything one way or the
>>
I hope people don't mind my asking about this on the list... as I hinted at
before, I don't really follow the development of PostgreSQL, I was just
interested in the Python driver project that I heard about.
Anyways, as I understand it, the current goal is to use psycopg and get it
changed to
Hello,
I noticed this morning that the k nearest neighbor gist patch
https://commitfest.postgresql.org/action/patch_view?id=230 was still being
considered for inclusion in 9. Sadly, this feature appears to have been
dropped from 9.
It seems to me that the functionality this brings is one of the m
Bruce Momjian writes:
> Right now, log_error_verbosity displays the source code error location
> in this format:
> LOCATION: parserOpenTable, parse_relation.c:858
> I think it would be clearer to add '()' next to the function name. We
> use '() to display function names in our docs and I
Takahiro Itagaki wrote:
>
> Bruce Momjian wrote:
>
> > Where are we on this patch? We should at least implement the completion
> > for 'LANGUAGE' in 'DO', and use the existing pg_language query for
> > completion. I am attaching a patch that does exactly this.
>
> I don't think we need the pa
On 2010-02-11 01:58 +0200, Robert Haas wrote:
> On Wed, Feb 10, 2010 at 6:25 PM, Marko Tiikkaja
> wrote:
>> On 2010-02-11 00:50 +0200, Marko Tiikkaja wrote:
>> Ok, what about the following:
>> - after planning the original query, standard_planner() goes through
>>the list of top-level CTEs an
On Jan 13, 2010, at 9:32 PM, Tom Lane wrote:
> Jim Nasby writes:
>> I noticed odd stuff showing up when I fired up an 8.3 psql after using psql
>> in HEAD. It shows up in .psql_history as well:
>
> Platform? readline version?
This is on snow leopard. FWIW it's still doing it with today's HEAD.
On Wed, Feb 10, 2010 at 6:25 PM, Marko Tiikkaja
wrote:
> On 2010-02-11 00:50 +0200, Marko Tiikkaja wrote:
>> On 2010-02-10 23:57 +0200, Tom Lane wrote:
>>> Robert Haas writes:
If the executor has buried in it the assumption that the snapshot
can't change after startup, then does that me
Right now, log_error_verbosity displays the source code error location
in this format:
LOCATION: parserOpenTable, parse_relation.c:858
I think it would be clearer to add '()' next to the function name. We
use '() to display function names in our docs and I think using '()'
would clarify
On 2010-02-11 00:50 +0200, Marko Tiikkaja wrote:
> On 2010-02-10 23:57 +0200, Tom Lane wrote:
>> Robert Haas writes:
>>> If the executor has buried in it the assumption that the snapshot
>>> can't change after startup, then does that mean that we need to start
>>> up and shut down the executor for
On 2/10/2010 7:12 AM, Tom Lane wrote:
Kurt, you seem to be more or less impervious to advice :-(.
Thank you for reviewing my patch. It is a rare honor to
have my personal qualities reviewed here as well.
Since this forum is archived for posterity, I suppose I
must point out that I have in fac
On 2010-02-10 23:57 +0200, Tom Lane wrote:
> Robert Haas writes:
>> If the executor has buried in it the assumption that the snapshot
>> can't change after startup, then does that mean that we need to start
>> up and shut down the executor for each subquery?
>
> Yes, I think so. That's the way i
Robert Haas writes:
> If the executor has buried in it the assumption that the snapshot
> can't change after startup, then does that mean that we need to start
> up and shut down the executor for each subquery?
Yes, I think so. That's the way it's always worked in the past;
see for example Porta
On Wed, Feb 10, 2010 at 3:30 PM, Alvaro Herrera
wrote:
> Euler Taveira de Oliveira escribió:
>> Alvaro Herrera escreveu:
>> > The general idea seems sensible to me. I can't comment on the
>> > specifics.
>> >
>> +1. A lot of other programs have this summary at the end of configure
>> execution. T
On Tue, Feb 09, 2010 at 09:34:10AM -0500, Andrew Chernow wrote:
> Tollef Fog Heen wrote:
> >(please Cc me on replies, I am not subscribed)
> >
> >Hi,
> >
> >libpq currently does not use TCP keepalives. This is a problem in our
> >case where we have some clients waiting for notifies and then the
>
Euler Taveira de Oliveira escribió:
> Alvaro Herrera escreveu:
> > The general idea seems sensible to me. I can't comment on the
> > specifics.
> >
> +1. A lot of other programs have this summary at the end of configure
> execution. The problem is that PostgreSQL has too many options. Do we want
Alvaro Herrera escreveu:
> The general idea seems sensible to me. I can't comment on the
> specifics.
>
+1. A lot of other programs have this summary at the end of configure
execution. The problem is that PostgreSQL has too many options. Do we want to
list all of them?
--
Euler Taveira de Ol
On 2010-02-10 21:59 +0200, Robert Haas wrote:
> On Wed, Feb 10, 2010 at 5:05 AM, Marko Tiikkaja
> wrote:
>> On 2010-02-10 03:20 +0200, Tom Lane wrote:
>>> Marko Tiikkaja writes:
On 2010-02-10 02:19 +0200, Tom Lane wrote:
> You still haven't explained why it's a good idea to change the sn
On Wed, Feb 10, 2010 at 5:05 AM, Marko Tiikkaja
wrote:
> On 2010-02-10 03:20 +0200, Tom Lane wrote:
>> Marko Tiikkaja writes:
>>> On 2010-02-10 02:19 +0200, Tom Lane wrote:
You still haven't explained why it's a good idea to change the snapshot
after the executor has started. Right at
I have a strange problem we noticed the other day with triggers. We're
running 8.3.3 on Solaris 10 (intel) and have a feed that comes in
regularly to populate a table we're working on. The feed works just
fine inserting rows however the following trigger stops the feed until
we remove the tri
Hey, but rb_freefunc is still there ...
It will be reintroduced when ts_stat will be rewrited to use rbtree
One very minor quibble: please make the $PostgreSQL$ lines be just that
(i.e. remove everything between the : to the terminating $, keeping the
latter)
ok
--
Teodor Sigaev
On Wed, Feb 10, 2010 at 2:16 PM, Alvaro Herrera
wrote:
> Maybe you didn't type it, but it came from elsewhere? Maybe you're
> inheriting settings from some environment variable, or a file? Maybe
> you're eval'ing pg_config --configure?
Yeah, could be.
> The general idea seems sensible to me.
Robert Haas escribió:
> On Wed, Feb 10, 2010 at 12:01 PM, Priit Laes wrote:
> >> Also, it's quite unclear which items deserve a place in the list.
> >> If it's just to repeat what was in the configure command-line, what
> >> is the value of that?
> >
> > It might avoid the 'UU, I forgot to
I've been working on this
http://pgsql.privatepaste.com/2a81432f4f
for 8.3 (there should be some comments to port it to 8.4).
tsvector_tsquery_size works as expected.
But whatever I pass to the function I get an empty tsquery. Yet no
memory allocation problem or hang etc... just an empty vector,
On Wed, Feb 10, 2010 at 12:01 PM, Priit Laes wrote:
>> Also, it's quite unclear which items deserve a place in the list.
>> If it's just to repeat what was in the configure command-line, what
>> is the value of that?
>
> It might avoid the 'UU, I forgot to enable python support.',
> after
On Wed, Feb 10, 2010 at 12:08 PM, Alvaro Herrera
wrote:
> Robert Haas escribió:
>> On Wed, Feb 10, 2010 at 11:58 AM, Alvaro Herrera
>> wrote:
>
>> > Is Redhat's Visual Explain still alive? And what about Tom Raney's stuff?
>>
>> The core of Tom Raney's work was not so much the EXPLAIN format per
2010/2/10 Teodor Sigaev :
>> So suppose at this point that step is the largest integer that can be
>> represented...
>>>
>>> ! step ++;
>>
>> Boom.
>>>
>>> ! step>>= 1;
>
> step>>= 1;
> step ++'
>
> Unboom?
Yeah, that'll work.
>>> !
>>> ! while(step> 0) {
>>> ! in
Teodor Sigaev escribió:
> Also, rb_free is removed per Tom's comment. Can I commit the patch?
Hey, but rb_freefunc is still there ...
One very minor quibble: please make the $PostgreSQL$ lines be just that
(i.e. remove everything between the : to the terminating $, keeping the
latter)
--
Alva
So suppose at this point that step is the largest integer that can be
represented...
! step ++;
Boom.
! step>>= 1;
step>>= 1;
step ++'
Unboom?
!
! while(step> 0) {
! int i;
! for (i = step-1; i< nentry; i += 2 * step)
And similarly here...
>Perhaps you could supply a .sql file containing a testcase
> illustrating the performance benefits you tested with your patch
Sure.
Attached the updated patch (should solve a bug) and a script.
The sql scripts generates a 2M rows table ("orig"); then the
table is copied and the copy clustered
Markus Wanner wrote:
> On Wed, 10 Feb 2010 11:36:41 +0100, Joachim Wieland
> wrote:
>> http://www.postgresql.org/docs/8.4/static/backup-dump.html already
>> states about pg_dump: "In particular, it must have read access to all
>> tables that you want to back up, so in practice you almost always ha
On Wed, Feb 10, 2010 at 12:16 PM, Heikki Linnakangas
wrote:
> If they want to implement the warm standby using the (new) built-in
> logic to keep retrying restore_command, they would set
> standby_mode='on'. standby_mode='on' doesn't imply streaming replication.
>
> If you want to use pg_standby o
Hi Joachim,
On Wed, 10 Feb 2010 11:36:41 +0100, Joachim Wieland
wrote:
http://www.postgresql.org/docs/8.4/static/backup-dump.html already
states about pg_dump: "In particular, it must have read access to all
tables that you want to back up, so in practice you almost always have
to run it as a d
Alvaro Herrera writes:
> Tom Lane escribió:
>> ... It would be
>> really nice if we could get some feedback on the non-text formats
>> *before* they're set in stone.
> Is Redhat's Visual Explain still alive? And what about Tom Raney's stuff?
Visual Explain is dead as far as Red Hat is concerne
On Wed, Feb 10, 2010 at 07:01:19PM +0200, Priit Laes wrote:
>
> It might avoid the 'UU, I forgot to enable python support.',
> after you have waited a while for the build to finish...
>
+1 from me, for that very reason!
Ross
--
Ross Reedstrom, Ph.D. reed
Ühel kenal päeval, K, 2010-02-10 kell 10:39, kirjutas Tom Lane:
> Priit Laes writes:
> > This patch enables showing configure status at the end of ./configure
> > run and thus makes ./configure process a bit easier to follow (in the
> > sense of what features are actually enabled).
>
> I don't th
Robert Haas escribió:
> On Wed, Feb 10, 2010 at 11:58 AM, Alvaro Herrera
> wrote:
> > Is Redhat's Visual Explain still alive? And what about Tom Raney's stuff?
>
> The core of Tom Raney's work was not so much the EXPLAIN format per se
> (which is really mooted by the changes already made in CVS
On Wed, Feb 10, 2010 at 11:58 AM, Alvaro Herrera
wrote:
> Tom Lane escribió:
>> Dave Page writes:
>> > On Wed, Feb 10, 2010 at 4:15 PM, Robert Haas wrote:
>> >> On Wed, Feb 10, 2010 at 9:46 AM, Tom Lane wrote:
>> >>> We can still hope that some feedback comes in during beta.
>>
>> >> I'm not op
Tom Lane escribió:
> Dave Page writes:
> > On Wed, Feb 10, 2010 at 4:15 PM, Robert Haas wrote:
> >> On Wed, Feb 10, 2010 at 9:46 AM, Tom Lane wrote:
> >>> We can still hope that some feedback comes in during beta.
>
> >> I'm not opposed to that in principal, but in practice the PGadmin
> >> fol
On Wed, Feb 10, 2010 at 4:50 PM, Tom Lane wrote:
> Dave Page writes:
>> On Wed, Feb 10, 2010 at 4:15 PM, Robert Haas wrote:
>>> On Wed, Feb 10, 2010 at 9:46 AM, Tom Lane wrote:
We can still hope that some feedback comes in during beta.
>
>>> I'm not opposed to that in principal, but in pra
Tom Lane escribió:
> Alvaro Herrera writes:
> > Kevin Grittner escribi�:
> >> Robert Haas wrote:
> > Tom Lane wrote:
> We try to avoid using nonstandard SQL in dumps.
>
> >>> How often do we succeed? It seems unlikely that our dumps would
> >>> be restorable into any other database.
>
>
Aidan Van Dyk wrote:
> * Heikki Linnakangas [100210 02:33]:
>
>> Hmm, so after running restore_command, check the file size and if it's
>> too short, treat it the same as if restore_command returned non-zero?
>> And it will be retried on the next iteration. Works for me, though OTOH
>> it will t
Dave Page writes:
> On Wed, Feb 10, 2010 at 4:15 PM, Robert Haas wrote:
>> On Wed, Feb 10, 2010 at 9:46 AM, Tom Lane wrote:
>>> We can still hope that some feedback comes in during beta.
>> I'm not opposed to that in principal, but in practice the PGadmin
>> folks may not like us very much if w
Alvaro Herrera writes:
> Kevin Grittner escribió:
>> Robert Haas wrote:
> Tom Lane wrote:
We try to avoid using nonstandard SQL in dumps.
>>> How often do we succeed? It seems unlikely that our dumps would
>>> be restorable into any other database.
>> When we were running in a mixed envi
Robert Haas escribió:
> On Wed, Feb 10, 2010 at 9:46 AM, Tom Lane wrote:
> > Robert Haas writes:
> >> I sort of assumed we might get some feedback from pgadmin or other
> >> tool writers between the time this was committed six months ago and
> >> now, but I haven't seen a single message from anyo
On Wed, Feb 10, 2010 at 4:15 PM, Robert Haas wrote:
> On Wed, Feb 10, 2010 at 9:46 AM, Tom Lane wrote:
>> Robert Haas writes:
>>> I sort of assumed we might get some feedback from pgadmin or other
>>> tool writers between the time this was committed six months ago and
>>> now, but I haven't seen
Kevin Grittner escribió:
> Robert Haas wrote:
> > Tom Lane wrote:
>
> >> We try to avoid using nonstandard SQL in dumps.
> >
> > How often do we succeed? It seems unlikely that our dumps would
> > be restorable into any other database.
>
> When we were running in a mixed environment we had
Robert Haas wrote:
> Tom Lane wrote:
>> We try to avoid using nonstandard SQL in dumps.
>
> How often do we succeed? It seems unlikely that our dumps would
> be restorable into any other database.
When we were running in a mixed environment we had several occasions
where it was useful to fe
On Wed, Feb 10, 2010 at 10:16 AM, Tom Lane wrote:
> Takahiro Itagaki writes:
>> Is it a TODO item to replace "DROP" into "DROP IF EXISTS"
>> for cleanup commands in pg_restore?
>
> No. We try to avoid using nonstandard SQL in dumps.
How often do we succeed? It seems unlikely that our dumps wou
On Wed, Feb 10, 2010 at 9:46 AM, Tom Lane wrote:
> Robert Haas writes:
>> I sort of assumed we might get some feedback from pgadmin or other
>> tool writers between the time this was committed six months ago and
>> now, but I haven't seen a single message from anyone who has actually
>> tried to
Hans-Jürgen Schönig wrote:
> hi,
>
> this patch implements SQL side tracing / tracking of statements and
> statement execution times.
> it is primarily intended to allow programmers to gather information
> about the runtime behavior of a program and to figure out easily
> where the bottlenecks are
Magnus Hagander writes:
> If someone didn't notice, I have applied that fix and it appears to
> have solved it.
... and there was much rejoicing.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription
Priit Laes writes:
> This patch enables showing configure status at the end of ./configure
> run and thus makes ./configure process a bit easier to follow (in the
> sense of what features are actually enabled).
I don't think anybody actually reads configure's output anyway, so I'm
not sure about
2010/2/9 Magnus Hagander :
> On Tue, Feb 9, 2010 at 17:11, Tom Lane wrote:
>> Magnus Hagander writes:
>>> Here's a patch that "fixes" this. I put it locally for the radius
>>> authentication for now, since we don't use this anywhere else. Should
>>> we put this in /port/ somewhere, or is this goo
Takahiro Itagaki writes:
> Is it a TODO item to replace "DROP" into "DROP IF EXISTS"
> for cleanup commands in pg_restore?
No. We try to avoid using nonstandard SQL in dumps.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To mak
Kurt Harriman writes:
> On 1/19/2010 8:01 AM, Peter Eisentraut wrote:
>> One principle that I suppose should have been made more explicit is that
>> -- in my mind -- we should avoid littering our code with nonstandard
>> constructs in place of standard constructs.
> Everyone seems to hate the nam
Robert Haas writes:
> I sort of assumed we might get some feedback from pgadmin or other
> tool writers between the time this was committed six months ago and
> now, but I haven't seen a single message from anyone who has actually
> tried to write a tool. As you imply, I think it will be very har
On Wed, Feb 10, 2010 at 9:09 AM, Greg Stark wrote:
> Perhaps this is just a terminology difference but it seems
> ridiculously *narrow* to me:
Try "select * from pg_class".
>> Or as I said at the time... nobody liked anything about the patch
>> except that they didn't have to write it.
>
> I kno
On Wed, Feb 10, 2010 at 1:26 PM, Robert Haas wrote:
> For example, EXPLAIN (VERBOSE, FORMAT JSON) is often ridiculously
> wide because each output list is printed on a single line.
Perhaps this is just a terminology difference but it seems
ridiculously *narrow* to me:
QUERY PLAN
-
I think I've found the problem:
tuple->t_data wasn't at HEAPTUPLESIZE distance from tuple.
I guess the code makes that assumption somewhere, so I had
to do:
tuple->t_data = (HeapTupleHeader) ((char *) tuple +
HEAPTUPLESIZE);
Now that
* Heikki Linnakangas [100210 02:33]:
> Hmm, so after running restore_command, check the file size and if it's
> too short, treat it the same as if restore_command returned non-zero?
> And it will be retried on the next iteration. Works for me, though OTOH
> it will then fail to complain about a
Hi!
This patch enables showing configure status at the end of ./configure
run and thus makes ./configure process a bit easier to follow (in the
sense of what features are actually enabled).
Päikest,
Priit
From c6ab747e581c7ebeb954b2ccb4dbd932e1a61de7 Mon Sep 17 00:00:00 2001
From: Priit Laes
Dat
On Wed, Feb 10, 2010 at 5:39 AM, Greg Stark wrote:
> On Wed, Feb 10, 2010 at 3:59 AM, Robert Haas wrote:
>> Yes. We could add every bell and whistle imaginable to the text
>> format and it still would not begin to approach the verbosity of the
>> machine-readable formats. Have you looked at the
> I think you're confusing HeapTuple and HeapTupleHeader. SortTuple->tuple
> field should point to a HeapTupleHeader, not a HeapTuple.
Mmh, I don't get it: that would mean I might be using more info than required,
but I still don't understand why it's not working... at the end, CLUSTER is
going
Leonardo F wrote:
> static void
> writetup_rawheap(Tuplesortstate *state, int tapenum, SortTuple *stup)
> {
> HeapTupletuple = (HeapTuple) stup->tuple;
I think you're confusing HeapTuple and HeapTupleHeader. SortTuple->tuple
field should point to a HeapTupleHeader, not a HeapTuple.
The right
On 09/02/2010 23:37, Greg Smith wrote:
[snip]
>> So the logical choice is plain LGPL3. I am open to motivated
>> suggestions about other
>> licenses but I'll ignore such crap as "BSD is more open than LGPL".
>>
>
> I agree with your general logic and while I can't speak for everyone, I
> would
Joachim Wieland wrote:
> We want to teach people that Hot Standby and Streaming Replication are
> two different features.
I'm not sure about that, actually. Now that they're both in the tree,
they work nicely together and many users will think of them as one.
> However, Streaming Replication call
We want to teach people that Hot Standby and Streaming Replication are
two different features. However, Streaming Replication calls its main
parameter "standby_mode" which reminds more of Hot Standby than of
Streaming Replication.
People could also run a warm standby without streaming replication,
On Wed, Feb 10, 2010 at 3:59 AM, Robert Haas wrote:
> Yes. We could add every bell and whistle imaginable to the text
> format and it still would not begin to approach the verbosity of the
> machine-readable formats. Have you looked at them on a complex plan?
> They are really, really long, and
Hi Markus,
On Fri, Feb 5, 2010 at 6:29 PM, Markus Wanner wrote:
>
> So, let's first concentrate on the intended use case: allowing parallel
> pg_dump. To me it seems like a pragmatic and quick solution, however, I'm
> not sure if requiring superuser privileges is acceptable.
http://www.postgresq
On 12/16/2009 8:21 AM, Tom Lane wrote:
I would only suggest that the cleanest coding would be
#ifdef USE_INLINE
static inline foo(...) ...
#else
... non-inline definition of foo
#endif
ie, go ahead and rely on autoconf's definition (if any) of "inline
On 2010-02-10 03:20 +0200, Tom Lane wrote:
> Marko Tiikkaja writes:
>> On 2010-02-10 02:19 +0200, Tom Lane wrote:
>>> You still haven't explained why it's a good idea to change the snapshot
>>> after the executor has started. Right at the moment I'm prepared to
>>> reject the patch on that ground
On 12/16/2009 8:40 AM, Tom Lane wrote:
Alvaro Herrera writes:
IIRC Kurt was also on about getting rid of some ugly macros that could
instead be coded as inline functions (fastgetattr for example)
I'd just bounce that as useless activity. If they are macros now,
and work, the only possible ef
On 1/19/2010 8:01 AM, Peter Eisentraut wrote:
On tis, 2010-01-19 at 01:29 -0800, Kurt Harriman wrote:
On 1/18/2010 11:48 PM, Peter Eisentraut wrote:
We have some existing inline functions in .c files. These can be
more complicated, so it might be ok if the compiler decides to
leave them out-of-
On Wed, Feb 10, 2010 at 4:32 PM, Heikki Linnakangas
wrote:
> Hmm, so after running restore_command, check the file size and if it's
> too short, treat it the same as if restore_command returned non-zero?
Yes, only in standby mode case. OTOH I think that normal archive recovery
should treat it as
1 - 100 of 104 matches
Mail list logo
