On Tue, Apr 26, 2011 at 1:10 PM, Alexander Korotkov wrote:
> Since algorithm is focused to reduce I/O, we should expect best
> acceleration in the case when index doesn't fitting to memory. Size of
> buffers is comparable to size of whole index. It means that if we can hold
> buffers in memory the
Dear pgsql-hackers,
My name is Sivasankar Ramasubramanian (you can call me Shiv). I am one of
the students taking part in this years Google Summer of Code program. I am
Indian but I study and live in Singapore (at the National University of
Singapore).
On the program I hope to learn as much about
Alvaro Herrera writes:
> Excerpts from Tomas Vondra's message of mar abr 26 17:39:19 -0300 2011:
>> Dne 25.4.2011 18:16, Alvaro Herrera napsal(a):
>> I think I'll move the integrity check to the db, so that it's possible
>> to check the column lengths etc. (pageinspect seems like a good module
>>
Andrew Dunstan writes:
> All or almost all the warnings seen on Windows/Mingw of the type
> "warning: unknown conversion type character 'm' in format" come from
> checking of three functions: errmsg, elog and errdetail. I therefore
> propose to disable the attribute checking of those three func
All or almost all the warnings seen on Windows/Mingw of the type
"warning: unknown conversion type character 'm' in format" come from
checking of three functions: errmsg, elog and errdetail. I therefore
propose to disable the attribute checking of those three functions, on
Windows only (since
Both "%lld" and "%I64d" can be used with mingw to print 64 bit integers.
However, modern versions of gcc spit warnings with the former, and not
the latter. However, since "%lld" works, it is chosen by our config
setup since it comes first in the list of formats tried. Therefore, to
keep the c
With Postgres 8.4 query like
SELECT *
FROM core.tag_links ctl
WHERE (ctl.tag_id = ANY (
SELECT array_agg(ct.id)
FROM core.tags ct
WHERE (LOWER(ct.tag) LIKE LOWER(('search tag')::text || '%') ESCAPE
E'\\')
));
produces error:
ERROR: operator does not e
On Mon, Apr 25, 2011 at 12:07 PM, Peter Eisentraut wrote:
> Another point, as there appear to be diverging camps about
> supertransactional stored procedures vs. autonomous transactions, what
> would be the actual use cases of any of these features? Let's collect
> some, so we can think of ways t
On Tue, Apr 26, 2011 at 07:23:12PM -0400, Tom Lane wrote:
[input functions aren't the only problematic source of uninitialized datum
bytes]
> We've run into other manifestations of this issue before. Awhile ago
> I made a push to ensure that datatype input functions didn't leave any
> ill-define
Alvaro Herrera wrote:
> Excerpts from Bruce Momjian's message of mar abr 26 12:58:19 -0300 2011:
>
> > Wow, I am so glad someone documented this. I often do factorial(4000)
> > which generates 12673 digits when teaching classes, and it bugged me
> > that we documented the limit as 1000 digits.
>
On Wed, Apr 27, 2011 at 12:23 AM, Tom Lane wrote:
> Any ideas about better answers?
>
Here's a crazy idea. We could use string equality of the out
function's representation instead. If an output function doesn't
consistently output the same data for things that are equal or
different data for thi
Excerpts from Bruce Momjian's message of mar abr 26 12:58:19 -0300 2011:
> Wow, I am so glad someone documented this. I often do factorial(4000)
> which generates 12673 digits when teaching classes, and it bugged me
> that we documented the limit as 1000 digits.
I keep wondering why you want to
Excerpts from Tomas Vondra's message of mar abr 26 17:39:19 -0300 2011:
> Dne 25.4.2011 18:16, Alvaro Herrera napsal(a):
> > This reminds me -- we need to have pg_filedump be able to dump the
> > relmapper stuff. I was going to write a patch for it but then I forgot.
>
> Was this a polite questi
On Tue, Apr 26, 2011 at 11:55 PM, Josh Berkus wrote:
> Here's where I wanted autonomous transactions just last week, and didn't
> have them so I had to use a python script outside the database:
>
> -- doing a CREATE INDEX CONCURRENTLY for 150 partitions on a partitioned
> table.
>
> -- doing a bac
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> What it would mostly
> do is decouple the development community entirely from release
> stabilization work, and I think that would be a seriously bad idea.
+1000%, seriously. This is a huge concern that we need to make sure is
addressed in a sensible way.
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
> Any ideas about better answers?
Seems like you covered it - anything other than memcmp() is going
to require a lot of brainz and have lots of sharp edges.
> But this example shows that we'd really have to enforce the rule
> of "no ill-defi
Josh Berkus writes:
>> Huh? We've never guaranteed anyone a regular annual cycle, and we've
>> never had one. We agreed to use the same schedule for 9.1 as for 9.0;
>> I don't remember anything more than that being discussed anywhere,
>> ever.
> We *want* to have a regular annual cycle which do
I looked into David Johnston's report of curious planner behavior:
http://archives.postgresql.org/pgsql-general/2011-04/msg00885.php
What is happening is that the planner doesn't reliably see the
expression ti_status = ANY ('{ACTIVE,DISPATCHED,FAILURE}'::text[])
as equal to other copies of itself,
> Huh? We've never guaranteed anyone a regular annual cycle, and we've
> never had one. We agreed to use the same schedule for 9.1 as for 9.0;
> I don't remember anything more than that being discussed anywhere,
> ever.
We *want* to have a regular annual cycle which doesn't vary by more than
a
Josh Berkus wrote:
> -- doing a backfill operation for 10GB of computed data, taking 8
> hours, where I don't want to hold a transaction open for 8 hours
> since this is a high-volume OLTP database.
Been there, done that. Definitely not a rare use case.
-Kevin
--
Sent via pgsql-hackers ma
Tom Lane wrote:
> No, but what you *would* need is the ability to return multiple
> result sets from one call.
At least.
> Even then, you could not exactly duplicate the current output of
> \d; but you could duplicate the functionality.
I would think that psql could duplicate the output pr
> Another point, as there appear to be diverging camps about
> supertransactional stored procedures vs. autonomous transactions, what
> would be the actual use cases of any of these features? Let's collect
> some, so we can think of ways to make them work.
Here's where I wanted autonomous transa
Peter Eisentraut wrote:
> On mån, 2011-04-25 at 14:35 -0500, Kevin Grittner wrote:
>> (1) All the \d commands in psql should be implemented in SPs so
>> that they are available from any client, through calling one SP
>> equivalent to one \d command.
>
> You don't need stored procedures with spec
Peter Eisentraut writes:
> On mån, 2011-04-25 at 14:35 -0500, Kevin Grittner wrote:
>> (1) All the \d commands in psql should be implemented in SPs so
>> that they are available from any client, through calling one SP
>> equivalent to one \d command.
> You don't need stored procedures with spec
On mån, 2011-04-25 at 19:25 -0400, Andrew Dunstan wrote:
> I came across this today, while helping a customer. The following
> will
> happily create a piece of XML with an embedded ^A:
>
> select xmlelement(name foo, null, E'abc\x01def');
>
> Now, a ^A is totally forbidden in XML version 1.0
On mån, 2011-04-25 at 14:35 -0500, Kevin Grittner wrote:
> (1) All the \d commands in psql should be implemented in SPs so
> that they are available from any client, through calling one SP
> equivalent to one \d command.
You don't need stored procedures with special transaction behavior for
this.
On 04/26/2011 05:31 PM, Tom Lane wrote:
Andrew Dunstan writes:
(gdb) p 'postmaster.c'::ProcGlobal->startupProcPid
$1 = 0
(gdb) p 'postmaster.c'::ProcGlobal->startupProc
$2 = (PGPROC *) 0x0
Oh ... you need this patch:
http://git.postgresql.org/gitweb?p=postgresql.git&a=commitdiff&h=9bb1ddec4
Andrew Dunstan writes:
> (gdb) p 'postmaster.c'::ProcGlobal->startupProcPid
> $1 = 0
> (gdb) p 'postmaster.c'::ProcGlobal->startupProc
> $2 = (PGPROC *) 0x0
Oh ... you need this patch:
http://git.postgresql.org/gitweb?p=postgresql.git&a=commitdiff&h=9bb1ddec4cd998c5fbac278a54d8ad5a5011e4e1
Upda
> Now the little question. I don't loose time and refactoring my code (XML
> validation functions). I created new data types for DTD, XSD and RNG but
> don't know where may I put validation code. Is better place in
> src/backend/utils/adt/xml.c or create new file inside contrib/xml2 folder.
We
Hello,
at first i would like to say thanks a lot for your confidence. I will do my
best.
Now the little question. I don't loose time and refactoring my code (XML
validation functions). I created new data types for DTD, XSD and RNG but don't
know where may I put validation code. Is better plac
On Tue, Apr 26, 2011 at 3:19 PM, Merlin Moncure wrote:
> On Tue, Apr 26, 2011 at 1:48 PM, Tom Lane wrote:
>> I wrote:
>>> A different angle of attack on the issue is that aset.c's use of
>>> exact-power-of-2 sizes for both malloc requests and the available space
>>> in chunks is inefficient when
Peter Eisentraut writes:
> We currently don't represent the sequence privileges in the information
> schema. We could perhaps do a subset of them.
> In the SQL standard, there is only the USAGE privilege, and its only
> purpose (AFAICT) is to allow the NEXT VALUE FOR expression.
> PostgreSQL's n
On Apr 26, 2011, at 3:32 PM, Markus Wanner wrote:
> Remember the bgworker patches extracted from Postgres-R?
Oh, right. I should have remembered that.
> [ Interestingly enough, one of the complaints I heard back then (not
> necessarily from you) was that there's no user for bgworkers, yet.
> Sm
On Mon, Apr 25, 2011 at 07:25:02PM -0400, Andrew Dunstan wrote:
> I came across this today, while helping a customer. The following will
> happily create a piece of XML with an embedded ^A:
>
>select xmlelement(name foo, null, E'abc\x01def');
>
> Now, a ^A is totally forbidden in XML version
Markus Wanner wrote:
> On 04/26/2011 02:25 PM, Robert Haas wrote:
>> We've talked about a number of features that could benefit from
>> some kind of "worker process" facility (e.g. logical replication,
>> parallel query). So far no one has stepped forward to build such
>> a facility, and I think
On 04/26/2011 04:45 PM, Tom Lane wrote:
I wrote:
Well, that's pretty interesting: refcount is only 1, and the
BM_PIN_COUNT_WAITER flag is not set. AFAICS this *must* mean that the
buffer had been pinned and whoever had it (presumably bgwriter) did
UnpinBuffer(). So it appears that the signal
I wrote:
> Well, that's pretty interesting: refcount is only 1, and the
> BM_PIN_COUNT_WAITER flag is not set. AFAICS this *must* mean that the
> buffer had been pinned and whoever had it (presumably bgwriter) did
> UnpinBuffer(). So it appears that the signal just plain got lost :-(,
> which sug
On 04/26/2011 04:28 PM, Tom Lane wrote:
Andrew Dunstan writes:
This has happened again. This time we have some debug info available,
and can possible get more, if people tell me what will be helpful:
(gdb) f 2
#2 0x005de735 in LockBufferForCleanup (buffer=310163) at
bu
On 04/25/2011 05:45 PM, Andres Freund wrote:
The profile I used in this case was:
pgbench -h /tmp/ -p5433 -s 30 pgbench -S -T 20
I'd suggest collecting data from running this with "-M prepared" at some
point too, so that you can get a basic idea which of these allocations
are avoided whe
Dne 25.4.2011 18:16, Alvaro Herrera napsal(a):
> Excerpts from Tomas Vondra's message of dom abr 24 13:49:31 -0300 2011:
>
>> I've figured out the catalog-to-file mapping (in relmapper.c), but now
>> I'm wondering - it's just another relation, so I'd have to read the
>> block, parse the items and
Andrew Dunstan writes:
> This has happened again. This time we have some debug info available,
> and can possible get more, if people tell me what will be helpful:
> (gdb) f 2
> #2 0x005de735 in LockBufferForCleanup (buffer=310163) at
> bufmgr.c:2432
> 2432
We currently don't represent the sequence privileges in the information
schema. We could perhaps do a subset of them.
In the SQL standard, there is only the USAGE privilege, and its only
purpose (AFAICT) is to allow the NEXT VALUE FOR expression.
PostgreSQL's nextval(), by contrast, requires both
On Tue, Apr 26, 2011 at 1:48 PM, Tom Lane wrote:
> I wrote:
>> A different angle of attack on the issue is that aset.c's use of
>> exact-power-of-2 sizes for both malloc requests and the available space
>> in chunks is inefficient when maxBlockSize is constrained to be not much
>> larger than comm
On 02/22/2011 07:55 AM, Robert Haas wrote:
On Sun, Feb 20, 2011 at 12:39 PM, Greg Stark wrote:
On Fri, Feb 18, 2011 at 6:59 PM, Andrew Dunstan wrote:
The server is running as a warm standby, and the client's application tries
to connect to both the master and the slave, accepting whichever
Fujii Masao wrote:
> On Sat, Mar 19, 2011 at 10:20 AM, Robert Haas wrote:
> > On Fri, Mar 18, 2011 at 1:19 PM, Erik Rijkers wrote:
> >> This is OK and expected. ?But then it continues (in the logfile) with:
> >>
> >> FATAL: ?lock file "postmaster.pid" already exists
> >> HINT: ?Is another postmas
Josh Berkus wrote:
>
> > Was it really all that bad? IIRC we replaced ARC with the current clock
> > sweep due to patent concerns. (Maybe there were performance concerns as
> > well, I don't remember).
>
> Yeah, that was why the patent was frustrating. Performance was poor and
> we were planni
On Tue, Apr 26, 2011 at 7:15 PM, Alvaro Herrera
wrote:
> Excerpts from Heikki Linnakangas's message of mar abr 26 15:06:51 -0300 2011:
>
>> I tried to look around for other executor nodes that might
>> have the same problem. I didn't see any obvious leaks, although index
>> scan node seems to call
Robert,
On 04/26/2011 02:25 PM, Robert Haas wrote:
> We've talked about a number of features that could benefit from some
> kind of "worker process" facility (e.g. logical replication, parallel
> query). So far no one has stepped forward to build such a facility,
> and I think without that this c
> -Original Message-
> From: Jeff Davis [mailto:pg...@j-davis.com]
> Sent: Tuesday, April 26, 2011 11:44 AM
> To: Dann Corbit
> Cc: pgsql-hackers@postgresql.org
> Subject: Re: [HACKERS] What was the exact version of PostgreSQL where
> the column name length changed from 31 to 63 characters?
On Tue, 2011-04-26 at 18:35 +, Dann Corbit wrote:
> I need to know so that I can handle cases like:
>
> Create table foolongcols(
> nevermindthefurthermorejustpleadinselfdefense char(5),
> nevermindthefurthermorejustpleadguilty char(5)
> );
>
> I assume that other object names (t
I wrote:
> A different angle of attack on the issue is that aset.c's use of
> exact-power-of-2 sizes for both malloc requests and the available space
> in chunks is inefficient when maxBlockSize is constrained to be not much
> larger than common chunk request sizes. Maybe we should try to fix that
On Tue, Apr 26, 2011 at 1:35 PM, Dann Corbit wrote:
> I need to know so that I can handle cases like:
>
> Create table foolongcols(
> nevermindthefurthermorejustpleadinselfdefense char(5),
> nevermindthefurthermorejustpleadguilty char(5)
> );
>
> I assume that other object names (tab
I need to know so that I can handle cases like:
Create table foolongcols(
nevermindthefurthermorejustpleadinselfdefense char(5),
nevermindthefurthermorejustpleadguilty char(5)
);
I assume that other object names (table name, function name, etc.) are
similarly affected. Is that
Heikki Linnakangas writes:
> The trivial fix is to reset the per-tuple memory context between
> iterations.
Have you tested this with SRFs?
ForeignNext seems like quite the wrong place for resetting
exprcontext in any case ...
regards, tom lane
--
Sent via pgsql-hacke
On Tue, Apr 26, 2011 at 1:15 PM, Sim Zacks wrote:
> We have tried a similar approach, using plpythonu, by calling import pg and
> then creating a new connection to the database. This does give you an
> autonomous transaction, but not an asynchronous function.
> My use cases are mostly where the fu
Excerpts from Heikki Linnakangas's message of mar abr 26 15:06:51 -0300 2011:
> I tried to look around for other executor nodes that might
> have the same problem. I didn't see any obvious leaks, although index
> scan node seems to call AM's getnext without resetting the memory
> context in bet
Foreign data wrapper's IterateForeignScan() function is supposed to be
called in a short-lived memory context, but the memory context is
actually not reset during query execution. That's a pretty bad memory
leak. I've been testing this with file_fdw and a large file, and "SELECT
COUNT(*) FROM f
Robert Haas wrote:
> On Mon, Apr 11, 2011 at 1:39 PM, ? ? wrote:
> > 11.04.2011 5:19, Robert Haas ?:
> >>
> >> You only sent this to me, I think; I assume you meant to copy the list.
> >>
> >> ...Robert
> >>
> >> On Mar 16, 2011, at 12:46 AM, Zotov ?wrote:
> >
> > I send full patch, pr
Merlin Moncure writes:
> On Tue, Apr 26, 2011 at 11:46 AM, Tom Lane wrote:
>> After a bit longer, the reasoning came back to me ...
> right -- spell.c was deliberately trying to influence allocator
> behavior. Should it really do that though without direct
> participation of some form? (like, e
On 04/26/2011 06:32 PM, Merlin Moncure wrote:
On Tue, Apr 26, 2011 at 9:24 AM, Robert Haas wrote:
On Tue, Apr 26, 2011 at 10:02 AM, David Fetter wrote:
On Tue, Apr 26, 2011 at 04:17:48PM +0300, Sim Zacks wrote:
On 04/26/2011 03:15 PM, Merlin Moncure wrote:
On Tue, Apr 26, 2011 at 3:28 AM,
Hi people,
I am happy to say that my proposal "New phpPgAdmin Plugin
Architecture" was accepted in the Google Summer of Code 2011. I thank
my mentor Mr. Jehan-Guillaume de Rorthais, the co-mentor Andreas
Scherbaum, and the PostgreSQL Global Development Group for help and
accept me as student.
On Tue, Apr 26, 2011 at 11:46 AM, Tom Lane wrote:
> I wrote:
>> Hmm ... the idea behind that comment is evidently that it's best if the
>> blocks allocated by this code form independent malloc blocks in aset.c;
>> but right offhand I can't see why that'd be important. It's obviously
>> not functi
I wrote:
> Hmm ... the idea behind that comment is evidently that it's best if the
> blocks allocated by this code form independent malloc blocks in aset.c;
> but right offhand I can't see why that'd be important. It's obviously
> not functionally necessary, since the code works as-is, and I don't
Merlin Moncure writes:
> I was poking around in the allocator code out of curiosity after
> reading the thread 'Improving the memory allocator', and noticed the
> following in spell.c:
> #define COMPACT_ALLOC_CHUNK 8192/* must be > aset.c's allocChunkLimit
> */
> In aset.c, we have,
>
Robert Haas wrote:
> On Fri, Apr 1, 2011 at 7:51 AM, Noah Misch wrote:
> > On Fri, Apr 01, 2011 at 11:44:23AM +0100, Gianni Ciolli wrote:
> >> Please find attached v2 of the numeric-doc patch, which takes into
> >> account your remarks. In particular, numeric limits are now correct
> >> and docume
Simon Riggs wrote:
> On Wed, 2011-03-09 at 21:21 -0500, Bruce Momjian wrote:
> > Simon Riggs wrote:
> > > On Fri, 2011-03-04 at 23:15 +0900, Fujii Masao wrote:
> > >
> > > > postgres=# SELECT application_name, state, sync_priority, sync_state
> > > > FROM pg_stat_replication;
> > > > application_
=?ISO-8859-1?Q?Yves_Wei=DFig?= writes:
> Am 26.04.2011 14:28, schrieb Robert Haas:
>> On Tue, Apr 26, 2011 at 5:18 AM, Yves Weißig
>> wrote:
>>> CREATE OPERATOR CLASS abstime_ops
>>> DEFAULT FOR TYPE abstime USING ebi FAMILY abstime_ops AS
>>> OPERATOR 1 = (abstime,abstime),
>>> FUNCTION 1 hashin
On Tue, Apr 26, 2011 at 9:24 AM, Robert Haas wrote:
> On Tue, Apr 26, 2011 at 10:02 AM, David Fetter wrote:
>> On Tue, Apr 26, 2011 at 04:17:48PM +0300, Sim Zacks wrote:
>>> On 04/26/2011 03:15 PM, Merlin Moncure wrote:
>>>
>>> >On Tue, Apr 26, 2011 at 3:28 AM, Sim Zacks wrote:
>>> >>Asynchronou
(oops this mail never reached out, it seems, resending)
"Kevin Grittner" writes:
> Tom Lane wrote:
>> Yeah, I've come round to that position too. I think allowing
>> parameter names to be checked only after query names is probably
>> the best answer.
>
> That seems the most useful and least
Excerpts from Yves Weißig's message of mar abr 26 11:32:31 -0300 2011:
> I keep getting: ERROR: there is no built-in function named "ebibuild"
> This error message somehow leads me to fmgr.c where the contents of an
> array are inspected (in line 134). This array fmgr_builtins is built by
> fmgr_
Hi Hackers!
This is Zheng Yang from National University of Singapore.
I'm very glad to know that my proposal, "Enhancing Foreign-data Wrapper (FDW)
functionality for PostgreSQL", has been accepted
by this year's Google Summer of Code!
Thank you guys for the valuable comments and suggestions
2011/4/25 Christopher Browne :
> On Mon, Apr 25, 2011 at 2:03 PM, Jesper Krogh wrote:
>> On 2011-04-25 20:00, Leonardo Francalanci wrote:
The amount of data loss on a big table will be <1% of the data
loss caused by truncating the whole table.
>>>
>>> If that 1% is random (not time/trans
Excerpts from Alvaro Herrera's message of sáb abr 09 01:55:45 -0300 2011:
> Excerpts from Peter Eisentraut's message of lun mar 28 17:00:01 -0300 2011:
> > On mån, 2011-03-28 at 09:35 -0400, Robert Haas wrote:
> > > Actually those are all my fault. Sorry, I'm still learning the ropes.
> > > I did
Hi list,
I really have problems with the catalog entries for my AM.
In the doc
(http://developer.postgresql.org/pgdocs/postgres/index-catalog.html) it
says "anyone able to write a new access method is expected to be
competent to insert an appropriate row for themselves." :-) This is true
so far fo
On Tue, Apr 26, 2011 at 10:02 AM, David Fetter wrote:
> On Tue, Apr 26, 2011 at 04:17:48PM +0300, Sim Zacks wrote:
>> On 04/26/2011 03:15 PM, Merlin Moncure wrote:
>>
>> >On Tue, Apr 26, 2011 at 3:28 AM, Sim Zacks wrote:
>> >>Asynchronous functions
>> >>
>> >>*Problem*
>> >>Postgresql does not ha
The attached, applied patch changes pg_upgrade: now that it uses -w in
pg_ctl, remove loop that retried testing the connection; also
restructure the libpq connection code.
This patch also removes the unused variable postmasterPID and fixes a
libpq PQconn structure leak that was in the testing lo
On Tue, Apr 26, 2011 at 04:17:48PM +0300, Sim Zacks wrote:
> On 04/26/2011 03:15 PM, Merlin Moncure wrote:
>
> >On Tue, Apr 26, 2011 at 3:28 AM, Sim Zacks wrote:
> >>Asynchronous functions
> >>
> >>*Problem*
> >>Postgresql does not have support for asynchronous function calls.
> >Well, there is a
I was poking around in the allocator code out of curiosity after
reading the thread 'Improving the memory allocator', and noticed the
following in spell.c:
/*
* "Compact" palloc: allocate without extra palloc overhead.
*
* Since we have no need to free the ispell data items individually, there'
On 04/26/2011 04:22 PM, Stephen Frost wrote:
* Robert Haas (robertmh...@gmail.com) wrote:
On Tue, Apr 26, 2011 at 8:32 AM, Stephen Frost wrote:
Well, this specific thing could be done by just having PG close the
client connection, not care that it's gone, and have an implied
'commit;' at the
On 04/26/2011 03:32 PM, Stephen Frost wrote:
What I don't think we saw was any information about how, exactly, the OP
was planning to implement this in the backend.
Thanks,
Stephen
I'm at stage 1 of this proposal, meaning I know exactly what I want. I
am checking with
On Tuesday, April 26, 2011 03:21:05 PM Radosław Smogura wrote:
> On Tue, 26 Apr 2011 14:25:10 +0200, Andres Freund wrote:
> > On Tuesday, April 26, 2011 01:59:45 PM Radosław Smogura wrote:
> >> I didn't followed this topic carefully, so sorry If I wrote
> >>
> >> something
> >>
> >> that was w
* Robert Haas (robertmh...@gmail.com) wrote:
> On Tue, Apr 26, 2011 at 8:32 AM, Stephen Frost wrote:
> > Well, this specific thing could be done by just having PG close the
> > client connection, not care that it's gone, and have an implied
> > 'commit;' at the end. I'm not saying that I like thi
On Tue, 26 Apr 2011 14:25:10 +0200, Andres Freund wrote:
On Tuesday, April 26, 2011 01:59:45 PM Radosław Smogura wrote:
I didn't followed this topic carefully, so sorry If I wrote
something
that was written, but I thought about following approach at least
for
message sending, etc.:
1. Whe
On 04/26/2011 03:15 PM, Merlin Moncure wrote:
On Tue, Apr 26, 2011 at 3:28 AM, Sim Zacks wrote:
Asynchronous functions
*Problem*
Postgresql does not have support for asynchronous function calls.
Well, there is asynchronous support from the client of course. Thus
you can set up a asynchronou
On Tue, Apr 26, 2011 at 8:32 AM, Stephen Frost wrote:
> * Robert Haas (robertmh...@gmail.com) wrote:
>> We've talked about a number of features that could benefit from some
>> kind of "worker process" facility (e.g. logical replication, parallel
>> query). So far no one has stepped forward to bui
Am 26.04.2011 14:28, schrieb Robert Haas:
> On Tue, Apr 26, 2011 at 5:18 AM, Yves Weißig
> wrote:
>> CREATE OPERATOR CLASS abstime_ops
>> DEFAULT FOR TYPE abstime USING ebi FAMILY abstime_ops AS
>> OPERATOR 1 = (abstime,abstime),
>> FUNCTION 1 hashint4(abstime,abstime);
>>
>> it yields: ERROR:
* Robert Haas (robertmh...@gmail.com) wrote:
> We've talked about a number of features that could benefit from some
> kind of "worker process" facility (e.g. logical replication, parallel
> query). So far no one has stepped forward to build such a facility,
> and I think without that this can't ev
On Tue, Apr 26, 2011 at 5:18 AM, Yves Weißig
wrote:
> CREATE OPERATOR CLASS abstime_ops
> DEFAULT FOR TYPE abstime USING ebi FAMILY abstime_ops AS
> OPERATOR 1 = (abstime,abstime),
> FUNCTION 1 hashint4(abstime,abstime);
>
> it yields: ERROR: function hashint4(abstime, abstime) does not exist
On Tue, Apr 26, 2011 at 3:28 AM, Sim Zacks wrote:
> Add an Async command for functions ( ASYNC my_func(var1,var2) ) and add an
> async optional keyword in trigger statements ( CREATE TRIGGER ... EXECUTE
> ASYNC trig_func() ). This should cause an internal session to be started
> that the function
On Tuesday, April 26, 2011 01:59:45 PM Radosław Smogura wrote:
> I didn't followed this topic carefully, so sorry If I wrote something
> that was written, but I thought about following approach at least for
> message sending, etc.:
>
> 1. When initializing MemoryContext (pool) give one paramet
On Tue, Apr 26, 2011 at 2:45 AM, Prakash Itnal wrote:
> I assume that the access to act_rnc_pkey causes the blocking, however why?
> Or how I can resolve the blocking (commit one transaction solves the
> problem, but should Postgres not recognize the blocking situation and
> release one transactio
On Tue, Apr 26, 2011 at 3:28 AM, Sim Zacks wrote:
> Asynchronous functions
>
> *Problem*
> Postgresql does not have support for asynchronous function calls.
Well, there is asynchronous support from the client of course. Thus
you can set up a asynchronous call back to the database with dblink.
Th
I didn't followed this topic carefully, so sorry If I wrote something
that was written, but I thought about following approach at least for
message sending, etc.:
1. When initializing MemoryContext (pool) give one parameter that will
be stack size. Stack is addition to normal operations.
2. Op
Am 26.04.2011 01:15, schrieb Tom Lane:
> =?ISO-8859-15?Q?Yves_Wei=DFig?=
> writes:
>> But anyway I am having trouble creating an operator class:
>
>> CREATE OPERATOR CLASS abstime_ops
>> DEFAULT FOR TYPE abstime USING ebi FAMILY abstime_ops AS
>> OPERATOR 1 = ,
>> FUNCTION 1 abstimeeq(abstime
On Tue, Apr 26, 2011 at 10:46 AM, Heikki Linnakangas <
heikki.linnakan...@enterprisedb.com> wrote:
> Just palloc() the buffers in memory, at least in the first phase. That'll
> work fine for index creation. Dealing with concurrent searches and inserts
> makes it a lot more complicated, it's better
> > If that 1% is random (not time/transaction related), usually you'd rather
>have an empty table.
>
> Why do you think it would be random?
"Heap blocks would be zeroed if they were found to be damaged, following a
crash."
If you erase full blocks, you have no idea what data you erased; it
On Mon, Apr 25, 2011 at 3:19 PM, Stephen Frost wrote:
> * Robert Haas (robertmh...@gmail.com) wrote:
>> On balance, I think I prefer the
>> current arrangement, though if we could make the CommitFests a bit
>> shorter I would certainly like that better. I don't know how to make
>> that happen wit
On Mon, Apr 25, 2011 at 2:17 PM, Robert Haas wrote:
> if we
> make CommitFests more frequent and shorter, we can give people
> feedback more quickly
"We" can give people feedback more quickly. There is no "we" in that regard.
Some individuals may be in a position to give more frequent feedback,
Asynchronous functions
*Problem*
Postgresql does not have support for asynchronous function calls.
*Solution*
An asynchronous function would allow a user to call a function and have
it return immediately, while an internal session manages the actual
processing. Any return value(s) of the funct
On Mon, Apr 25, 2011 at 4:03 PM, Greg Stark wrote:
> On Mon, Apr 25, 2011 at 3:45 PM, Tom Lane wrote:
>> One small issue that would have to be resolved before branching is
>> whether and when to do a "final" pgindent run for 9.1. Seems like the
>> alternatives would be:
>>
>
> If the tools becom
100 matches
Mail list logo
