Hello,
Many of the links in the TODO wiki page result in a "page not found" error.
Is this page up-to-date?
Can anything be inferred about the status of these items from the broken
link?
Thanks.
http://wiki.postgresql.org/wiki/Todo
-Original Message-
From: pgsql-hackers-ow...@postgresql.org
[mailto:pgsql-hackers-ow...@postgresql.org] On Behalf Of Tom Lane
Sent: Tuesday, April 16, 2013 7:52 PM
To: Peter Eisentraut
Cc: pgsql-hackers@postgresql.org
Subject: Re: [HACKERS] ancient sequence point bug
>Peter Eisentraut wr
Peter Eisentraut writes:
> This code in bootstrap.c contains a sequence point violation (or
> whatever that is really called):
> while ((tup = heap_getnext(scan, ForwardScanDirection)) != NULL)
> {
> (*app)->am_oid = HeapTupleGetOid(tup);
> memmove((char *)
This code in bootstrap.c contains a sequence point violation (or
whatever that is really called):
while ((tup = heap_getnext(scan, ForwardScanDirection)) != NULL)
{
(*app)->am_oid = HeapTupleGetOid(tup);
memmove((char *) &(*app++)->am_typ,
On Apr16, 2013, at 23:41 , Ants Aasma wrote:
> On Tue, Apr 16, 2013 at 11:20 PM, Florian Pflug wrote:
>> On Apr13, 2013, at 17:14 , Ants Aasma wrote:
>>> Based on current analysis, it is particularly good at detecting single
>>> bit errors, as good at detecting burst errors as can be expected fr
I propose the attached patch to change pg_test_fsync's output from
"microsecs" to "usecs", which is the designation we use in other places.
Also remove parentheses, e.g.
1 * 16kB open_sync write8012.933 ops/sec 125 usecs/op
2 * 8kB open_sync writes 5399.901 op
On 4/13/13 12:44 PM, Tomas Vondra wrote:
I'm currently struggling with (quite uncommon) deployments where
databases are created/dropped regularly (not to mention tables and
indexes), and it's surprisingly difficult to process such stats to get
reasonable values.
Yes, it's a pain. If you aggreg
On Tue, Apr 16, 2013 at 11:20 PM, Florian Pflug wrote:
> On Apr13, 2013, at 17:14 , Ants Aasma wrote:
>> Based on current analysis, it is particularly good at detecting single
>> bit errors, as good at detecting burst errors as can be expected from
>> 16 bits and not horrible at detecting burst w
On Tue, Apr 16, 2013 at 6:09 PM, Tom Lane wrote:
>
> [...]
>
> Or, if you'd rather a more direct answer: wanting this sounds like
> evidence of bad application design. Why is your app dependent on
> getting failures from currval, and isn't there a better way to do it?
>
>
The sequence cache (seq
Ants Aasma writes:
> On Tue, Apr 16, 2013 at 5:05 PM, Simon Riggs wrote:
>> My only review comments are to ask for some explanation of the magic
>> numbers...
> The specific values used are mostly magic to me too. As mentioned in a
> short sentence in the patch, the values are experimentally ch
Bruce Momjian writes:
> I think his point is why don't we clear currval() on DISCARD ALL? I
> can't think of a good reason we don't.
Because we'd have to invent a new suboperation DISCARD SEQUENCES,
for one thing, in order to be consistent. I'd rather ask why it's
important that we should throw
On Tue, Apr 16, 2013 at 5:05 PM, Simon Riggs wrote:
> On 9 April 2013 03:35, Ants Aasma wrote:
>> On Fri, Apr 5, 2013 at 9:39 PM, Ants Aasma wrote:
>>> Unless somebody tells me not to waste my time I'll go ahead and come
>>> up with a workable patch by Monday.
>>
>> And here you go. I decided to
On Tue, Apr 16, 2013 at 12:13:48PM -0700, Adrian Klaver wrote:
> On 04/16/2013 08:07 AM, Nigel Heron wrote:
> >
> >On 04/15/2013 05:57 PM, Adrian Klaver wrote:
> >>On 04/15/2013 02:42 PM, Nigel Heron wrote:
> >>>Hi,
> >>>is there a way to clear the session state of sequence values fetched by
> >>>c
On Apr13, 2013, at 17:14 , Ants Aasma wrote:
> Based on current analysis, it is particularly good at detecting single
> bit errors, as good at detecting burst errors as can be expected from
> 16 bits and not horrible at detecting burst writes of zeroes. It is
> quite bad at detecting multiple unco
On 16 April 2013 20:27, Tom Lane wrote:
> Greg Stark writes:
>> On Fri, Apr 12, 2013 at 9:42 PM, Simon Riggs wrote:
>>> * WAL checksum is not used as the sole basis for end-of-WAL discovery.
>>> We reuse the WAL files, so the prev field in each WAL record shows
>>> what the previous end of WAL w
Greg Stark writes:
> On Fri, Apr 12, 2013 at 9:42 PM, Simon Riggs wrote:
>> * WAL checksum is not used as the sole basis for end-of-WAL discovery.
>> We reuse the WAL files, so the prev field in each WAL record shows
>> what the previous end of WAL was. Hence if the WAL checksums give a
>> false
On 4/16/13 7:49 AM, Robert Haas wrote:
> On Mon, Apr 15, 2013 at 11:57 PM, Peter Eisentraut wrote:
>> I'm having trouble finding documentation about how to write event
>> triggers. The chapter in the documentation
>>
>> http://www.postgresql.org/docs/devel/static/event-triggers.html
>>
>> says th
On Fri, Apr 12, 2013 at 9:42 PM, Simon Riggs wrote:
> * WAL checksum is not used as the sole basis for end-of-WAL discovery.
> We reuse the WAL files, so the prev field in each WAL record shows
> what the previous end of WAL was. Hence if the WAL checksums give a
> false positive we still have a d
On 16 April 2013 15:07, Tom Lane wrote:
> Bruce Momjian writes:
>> I found Simon's nextval()/COPY timings without this patch sobering. I
>> assume he can apply this for 9.3, right? I believe it is a fix for a
>> new 9.3 feature.
>
> It is not a "fix", it is not for a 9.3 feature (the multi-inse
On Tue, Apr 16, 2013 at 10:07:07AM -0400, Tom Lane wrote:
> Bruce Momjian writes:
> > I found Simon's nextval()/COPY timings without this patch sobering. I
> > assume he can apply this for 9.3, right? I believe it is a fix for a
> > new 9.3 feature.
>
> It is not a "fix", it is not for a 9.3 fe
Bruce Momjian writes:
> I found Simon's nextval()/COPY timings without this patch sobering. I
> assume he can apply this for 9.3, right? I believe it is a fix for a
> new 9.3 feature.
It is not a "fix", it is not for a 9.3 feature (the multi-insert thing
went in in 9.2), and personally I'd vote
On 9 April 2013 03:35, Ants Aasma wrote:
> On Fri, Apr 5, 2013 at 9:39 PM, Ants Aasma wrote:
>> Unless somebody tells me not to waste my time I'll go ahead and come
>> up with a workable patch by Monday.
>
> And here you go. I decided to be verbose with the comments as it's
> easier to delete a c
On Tue, Apr 16, 2013 at 02:37:33PM +0100, Simon Riggs wrote:
> On 16 April 2013 13:57, Heikki Linnakangas wrote:
>
> > You still need to check the args, if the function is nextval, otherwise you
> > incorrectly perform the optimization for something like
> > "nextval(myvolatilefunc())".
>
> Gues
On 16 April 2013 13:57, Heikki Linnakangas wrote:
> You still need to check the args, if the function is nextval, otherwise you
> incorrectly perform the optimization for something like
> "nextval(myvolatilefunc())".
Guess so. At least its an easy change.
Thanks for checking.
--
Simon Riggs
On 16.04.2013 14:38, Simon Riggs wrote:
On 15 April 2013 21:53, Simon Riggs wrote:
So I'll treat this as two separate cases:
* add special case for sequences
Patch attached.
+ if (IsA(node, FuncExpr))
+ {
+ FuncExpr *expr = (FuncExpr *) node;
+
+ /*
On Mon, Apr 15, 2013 at 11:57 PM, Peter Eisentraut wrote:
> I'm having trouble finding documentation about how to write event
> triggers. The chapter in the documentation
>
> http://www.postgresql.org/docs/devel/static/event-triggers.html
>
> says they can be written in C or supported PLs, but do
On 15 April 2013 21:53, Simon Riggs wrote:
> So I'll treat this as two separate cases:
> * add special case for sequences
Patch attached.
> * use the NO SQL mechanism, as described, which implies no reads or
> writes of database state. We could test that, but its somewhat harder
> and we'd need
Hi,
Here's a new version of a small patch to psql I'm using locally.
It adds a command \ns to psql which is a shortcut to set the
SEARCH_PATH variable.
I'd like to make a case for including this patch as it makes use of
schemas/namespaces much easier. There was resistance to including this
befor
Hello
2013/4/16 aasat
> Is "stored procedures" planned in future? I think is a "most missing"
> future
> today in Postgres.
>
It is in ToDo, but nobody working on this feature in this moment, probably.
>
> Using a dblink to emulate commit in transaction is very complicated
>
>
probably auton
Is "stored procedures" planned in future? I think is a "most missing" future
today in Postgres.
Using a dblink to emulate commit in transaction is very complicated
--
View this message in context:
http://postgresql.1045698.n5.nabble.com/stored-procedures-tp4331060p5752274.html
Sent from the P
30 matches
Mail list logo
