Hello
I try to implement SQL/PSM in PostgreSQL. I experimented with
rewriting a plpgsql - you can check this implementation
http://postgres.cz/index.php/SQL/PSM_Manual.
I though so we can have some common PL stack. But I don't think it
now. It means a some more uglification of current code or
On Mon, Nov 15, 2010 at 14:37, Pavel Stehule pavel.steh...@gmail.com wrote:
Maybe can be useful to implement a searching on sorted array.
You can hold a flag if multiset is sorted or not.
Are you suggesting to add an IS_SORTED bit to for each ArrayType value?
It might be possible, but I'm not
With help of Oleg I found, that line *left = *right = FirstOffsetNumber;
was needed only for 7.X compatibility, and it isn't needed any more.
Also, I've replaced i - 1 by i - FirstOffsetNumber in array filling.
I believe it's more correct way, because it'll work correctly in the case
when
2010/11/15 Itagaki Takahiro itagaki.takah...@gmail.com:
On Mon, Nov 15, 2010 at 14:37, Pavel Stehule pavel.steh...@gmail.com wrote:
Maybe can be useful to implement a searching on sorted array.
You can hold a flag if multiset is sorted or not.
Are you suggesting to add an IS_SORTED bit to for
On Monday 15 November 2010 09:47:15 Itagaki Takahiro wrote:
On Mon, Nov 15, 2010 at 14:37, Pavel Stehule pavel.steh...@gmail.com
wrote:
Maybe can be useful to implement a searching on sorted array.
You can hold a flag if multiset is sorted or not.
Are you suggesting to add an IS_SORTED
--On 14. November 2010 11:08:13 -0500 Robert Haas robertmh...@gmail.com
wrote:
+1. The current master branch fails to build on my (rather new) Mac with
make -j2. I could upgrade my toolchain but it seems like more trouble
than it's worth, not to mention a possible obstacle to new users
We can rename each field in VALUES clause:
=# SELECT * FROM (VALUES(123, 'ABC', NULL)) AS t(a,b,c);
a | b | c
-+-+---
123 | ABC |
(1 row)
But I cannot find ways for ROW expression to do the same thing:
=# SELECT ROW(123, 'ABC', NULL) AS (a,b,c);
ERROR: syntax error at or near (
Hello
I am checking a patch. I found a problem with initdb
[postg...@pavel-stehule postgresql]$ /usr/local/pgsql/bin/initdb -D
/usr/local/pgsql/data/
could not change directory to /home/pavel/src/postgresql
The files belonging to this database system will be owned by user postgres.
This user
I keep wondering if there's a role for GPUs in Postgres and haven't
figure out how to integrate them yet but the day when we'll be
expected to exploit them seems to be getting nearer:
http://aws.typepad.com/aws/2010/11/new-ec2-instance-type-the-cluster-gpu-instance.html
--
greg
--
Sent via
On 15 November 2010 11:26, Greg Stark st...@mit.edu wrote:
I keep wondering if there's a role for GPUs in Postgres and haven't
figure out how to integrate them yet but the day when we'll be
expected to exploit them seems to be getting nearer:
On Mon, Nov 15, 2010 at 11:37 AM, Thom Brown t...@linux.com wrote:
Is this somewhere OpenCL is an option?
Sure.
Personally I wonder whether the context switching is fast enough to
handle a multi-user system. In the past graphics cards have always
been targeted at the idea of a single-user
On 2010-11-15 12:37, Thom Brown wrote:
On 15 November 2010 11:26, Greg Stark st...@mit.edu
mailto:st...@mit.edu wrote:
I keep wondering if there's a role for GPUs in Postgres and haven't
figure out how to integrate them yet but the day when we'll be
expected to exploit them seems
Excerpts from Tom Lane's message of lun nov 15 02:41:40 -0300 2010:
I believe also that there are probably race conditions in several of
the steps you listed; in particular there is certainly a risk involved
in changing the database-we-advertise-being-connected-to versus a
concurrent DROP
On Mon, Nov 15, 2010 at 12:41 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
Looking through the code, it appears to me that we'd need to do the
following (not necessarily in this order):
Don't forget
9. Unload loadable modules that do not exist according
On Mon, Nov 15, 2010 at 2:15 AM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
Can you elaborate?
Weak memory ordering means that stores into shared memory initiated by
one processor are not guaranteed to be observed to occur in the same
sequence by another processor. This
On 15.11.2010 15:22, Robert Haas wrote:
On Mon, Nov 15, 2010 at 2:15 AM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
Can you elaborate?
Weak memory ordering means that stores into shared memory initiated by
one processor are not guaranteed to be observed to occur in the
On Mon, Nov 15, 2010 at 8:45 AM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
It's not a question of code rearrangement.
Rearrangement of code, rearrangement of CPU instructions, or rearrangement
of the order the changes in the memory become visible to other processes.
The
Excerpts from Tom Lane's message of sáb nov 13 19:07:50 -0300 2010:
Stefan Kaltenbrunner ste...@kaltenbrunner.cc writes:
On 11/13/2010 06:58 PM, Tom Lane wrote:
Just looking at it, I think that the logic in canAcceptConnections got
broken by somebody in 8.4, and then broken some more in
Excerpts from Bruce Momjian's message of sáb nov 13 22:36:31 -0300 2010:
OK, I found out how to get the IP address with the attached patch. The
problem is that only pghost is set, never pghostaddr. I am not even
sure how that would get set for this code because my tests show it is
not:
Heikki Linnakangas heikki.linnakan...@enterprisedb.com writes:
Hmm, SetLatch only sets one flag, so I don't see how it could malfunction
all by itself. And I would've thought that declaring the Latch variable
volatile prevents rearrangements.
It's not a question of code rearrangement.
David Fetter da...@fetter.org wrote:
That it's not ready for commit this minute does not mean that it
shouldn't be in the CF this month. Delaying the first review of
the patch until the next CF pretty much ensures that we'll miss
9.1 with it, so please add to the current CF :)
Well, I had
On Mon, Nov 15, 2010 at 9:51 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Heikki Linnakangas heikki.linnakan...@enterprisedb.com writes:
Hmm, SetLatch only sets one flag, so I don't see how it could malfunction
all by itself. And I would've thought that declaring the Latch variable
volatile prevents
Itagaki Takahiro itagaki.takah...@gmail.com writes:
Another issue for sorting is that we have 4 kinds of sorting: ASC/DESC
and NULLS FIRST/LAST.
We have a lot more kinds than that. See USING.
regards, tom lane
--
Sent via pgsql-hackers mailing list
Itagaki Takahiro itagaki.takah...@gmail.com writes:
Is it possible to change names fields in ROW?
We can use CREATE TYPE AS on ahead, but I'd like to
change names of ROW expression in ad-hoc queries.
Why? It's an anonymous type, you shouldn't care about names.
If you do, make a real named
On 15.11.2010 16:51, Tom Lane wrote:
Heikki Linnakangasheikki.linnakan...@enterprisedb.com writes:
I believe it's safe to
assume that two operations using a volatile pointer will not be
rearranged wrt. each other.
This is entirely wrong, so far as cross-processor visibility of changes
is
Kevin Grittner wrote:
That went in an hour and a half before the CF deadline, but I just
didn't feel right putting it into the CF in that shape.
Then keep on working on it and we can revisit its state when you're
happy with it. The purpose of the CommitFest cut-off is not to block
work on
Excerpts from Greg Smith's message of lun nov 15 12:32:25 -0300 2010:
I could use a brief reminder of how this bit fits into the serializable
lock consistency patch that's already sitting into the CF queue as
Ready for Committer though.
I remind you, though, that the most painful point that
On Sun, Nov 14, 2010 at 02:16, Robert Haas robertmh...@gmail.com wrote:
Here is a series of three patches related to unlogged tables.
Just wondering, have you thought of any mechanisms how application
code might detect that an unlogged table was truncated due to restart?
While polling with
Greg Smith g...@2ndquadrant.com wrote:
I could use a brief reminder of how this bit fits into the
serializable lock consistency patch that's already sitting into
the CF queue as Ready for Committer though.
Florian's patch prevents an integrity inversion that PostgreSQL
has had for ages,
Hi,
I've been trying to summarise the last month of work into a single wiki
page, to ease approaching the review of this now quite large patch. It
touches lots of things but the design and goal are simple enough to fit
in my mind, that should be no problem for you guys here :)
Heikki Linnakangas heikki.linnakan...@enterprisedb.com writes:
In SetLatch, is it enough to add the SpinLockAcquire() call *after*
checking that is_set is not already set? Ie. still do the quick exit
without holding a lock. Or do we need a memory barrier operation before
the fetch, to
On Sun, Oct 31, 2010 at 5:41 PM, Andres Freund and...@anarazel.de wrote:
While at it:
These words always make me a bit frightened when reviewing a patch,
since it's generally simpler if a single patch only does one thing.
However, in this case...
* I remove the outdated
-- NOTE: int[24]
On Mon, Nov 15, 2010 at 10:56 AM, Kevin Grittner
kevin.gritt...@wicourts.gov wrote:
Greg Smith g...@2ndquadrant.com wrote:
I could use a brief reminder of how this bit fits into the
serializable lock consistency patch that's already sitting into
the CF queue as Ready for Committer though.
On 2010-11-15 18:49, Greg Stark wrote:
I've seen papers on doing relational joins using GPUs and I'm sure
there are other algorithms we wonderful stuff we could do. But if it
comes at the cost of being able to handle arbitrary join clauses it'll
be a tough sacrifice to make.
Perhaps the
Alvaro Herrera alvhe...@commandprompt.com wrote:
I remind you, though, that the most painful point that caused the
commitfest process to come into existance was the HOT patch, which
was very large and intrusive and didn't get any review until very
late in the cycle. So getting some review
On Monday 15 November 2010 17:12:25 Robert Haas wrote:
It would speed things up for me if you or someone else could take a
quick pass over what remains here and fix the formatting and
whitespace to be consistent with our general project style, and make
the comment headers more consistent among
On Mon, Nov 15, 2010 at 10:54 AM, Marti Raudsepp ma...@juffo.org wrote:
On Sun, Nov 14, 2010 at 02:16, Robert Haas robertmh...@gmail.com wrote:
Here is a series of three patches related to unlogged tables.
Just wondering, have you thought of any mechanisms how application
code might detect
Marti Raudsepp ma...@juffo.org writes:
Would there be a problem with invoking this trigger from the session
that first touches the table?
Other than security?
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to
With Informix VTI, indexing is the same for native tables as for
virtual tables, except the interpretation of the 32 bit rowid is left
up to the developer. When you define the VTI class, you optionally
supply a method that can fetch data based on a 32 bit rowid, and it's
the responsibility of
On Mon, Nov 15, 2010 at 18:25, Tom Lane t...@sss.pgh.pa.us wrote:
Marti Raudsepp ma...@juffo.org writes:
Would there be a problem with invoking this trigger from the session
that first touches the table?
Other than security?
Right, I guess that would only make sense with SECURITY DEFINER.
On Mon, Nov 15, 2010 at 12:02 PM, Marti Raudsepp ma...@juffo.org wrote:
On Mon, Nov 15, 2010 at 18:25, Tom Lane t...@sss.pgh.pa.us wrote:
Marti Raudsepp ma...@juffo.org writes:
Would there be a problem with invoking this trigger from the session
that first touches the table?
Other than
On Mon, Nov 15, 2010 at 11:22 AM, Robert Haas robertmh...@gmail.com wrote:
Yeah, this infrastructure doesn't really allow that. The truncate
happens way too early on in startup to execute any user-provided code.
But you could use the very feature of unlogged tables to know if
you've
On Sun, Nov 14, 2010 at 8:31 PM, Robert Haas robertmh...@gmail.com wrote:
On Sun, Nov 14, 2010 at 7:19 PM, Greg Smith g...@2ndquadrant.com wrote:
But if this is generating a lot of log data or adding a lot of
overhead, then you have bigger problems anyway:
+ elog(DEBUG1, Unable
Greg, Tom,
We *already* have separate bitmap outside the table for transaction
commit bits. It's the clog.
You didn't read my whole e-mail. I talk about the CLOG further down.
Josh is ignoring the proposal that is on the table and seems actually
workable, which is to consult the visibility
Josh Berkus j...@agliodbs.com writes:
No, I'm not. I'm pointing out that it doesn't unblock the other 4
features/improvements I mentioned, *all* of which would be unblocked by
not storing the hint bits in the table, whatever means we use to do so.
You, for your part, are consistently
I'm not ignoring them; I just choose to work on other issues, since
there is no viable proposal for fixing them. I don't intend to put
my time into dead ends.
So, that's a show me a patch and we'll talk? Understood, then.
--
-- Josh Berkus
On Mon, Nov 15, 2010 at 10:13:40AM -0500, Tom Lane wrote:
Itagaki Takahiro itagaki.takah...@gmail.com writes:
Another issue for sorting is that we have 4 kinds of sorting: ASC/DESC
and NULLS FIRST/LAST.
We have a lot more kinds than that. See USING.
USING pretty much gives us no chance
On Mon, Nov 15, 2010 at 2:06 PM, Josh Berkus j...@agliodbs.com wrote:
I'm not ignoring them; I just choose to work on other issues, since
there is no viable proposal for fixing them. I don't intend to put
my time into dead ends.
So, that's a show me a patch and we'll talk? Understood, then.
=?UTF-8?B?SmFuIFVyYmHFhHNraQ==?= wulc...@wulczer.org writes:
On 24/10/10 00:32, Jan UrbaÅski wrote:
On 21/10/10 20:48, Alvaro Herrera wrote:
... and presumably somebody can fix the real bug that Jean-Baptiste hit,
too.
AFAICS the error comes from PLy_function_handler disconnecting from SPI
On Sun, Nov 14, 2010 at 7:04 PM, Greg Smith g...@2ndquadrant.com wrote:
It might. One trade-off is that if you're looking at the sync write detail,
the summary comes out in a similar form. And it was easy to put in
here--I'd have to return some new data out of the sync phase call in order
David Fetter da...@fetter.org writes:
On Mon, Nov 15, 2010 at 10:13:40AM -0500, Tom Lane wrote:
Itagaki Takahiro itagaki.takah...@gmail.com writes:
Another issue for sorting is that we have 4 kinds of sorting: ASC/DESC
and NULLS FIRST/LAST.
We have a lot more kinds than that. See USING.
Robert Haas robertmh...@gmail.com writes:
On Mon, Nov 15, 2010 at 2:06 PM, Josh Berkus j...@agliodbs.com wrote:
I'm not ignoring them; I just choose to work on other issues, since
there is no viable proposal for fixing them. I don't intend to put
my time into dead ends.
So, that's a show me
Robert Haas robertmh...@gmail.com writes:
I would be very surprised if we can find a system where gettimeofday()
takes a significant amount of time compared with fsync(). It might be
(probably is) too expensive to stick into code paths that are heavily
CPU-bounded, but surely the cost here is
So my task list is:
0) Rebase against the HEAD that just code related to this touched today
1) Assume that log_checkpoints is sufficient control over whether the
timing overhead added is worth collecting, and therefore remove the
half-baked idea of also wrapping with a compile-time option.
On Mon, Nov 15, 2010 at 2:48 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
I would be very surprised if we can find a system where gettimeofday()
takes a significant amount of time compared with fsync(). It might be
(probably is) too expensive to stick into
On Sun, Nov 14, 2010 at 2:07 PM, Greg Smith g...@2ndquadrant.com wrote:
The attached patch adds a new field to pg_stat_bgwriter, counting the number
of times backends execute their own fsync calls. Normally, when a backend
needs to fsync data, it passes a request to the background writer,
On mån, 2010-11-15 at 11:13 +0100, Bernd Helmle wrote:
--On 14. November 2010 11:08:13 -0500 Robert Haas robertmh...@gmail.com
wrote:
+1. The current master branch fails to build on my (rather new) Mac with
make -j2. I could upgrade my toolchain but it seems like more trouble
than
Hello
2010/11/15 Peter Eisentraut pete...@gmx.net:
On mån, 2010-11-15 at 11:34 +0100, Pavel Stehule wrote:
I am checking a patch. I found a problem with initdb
Ah, late night brain farts, it appears. Here is a corrected version.
yes, it's ok now.
I see still a few issues:
a) default
On Tue, Nov 16, 2010 at 00:18, Tom Lane t...@sss.pgh.pa.us wrote:
Why? It's an anonymous type, you shouldn't care about names.
If you do, make a real named rowtype.
If so, we cannot extract any fields in an anonymous type, right?
We cannot lookup fields with (an anonymous type).name because
On Mon, Sep 20, 2010 at 12:17 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Personally I think this demonstrates that piggybacking replication
data transfer on the COPY protocol was a bad design to start with.
It's probably time to split them apart.
This appears to be the only obvious unresolved
On Mon, Nov 15, 2010 at 4:06 AM, Alexander Korotkov
aekorot...@gmail.com wrote:
With help of Oleg I found, that line *left = *right = FirstOffsetNumber;
was needed only for 7.X compatibility, and it isn't needed any more.
Also, I've replaced i - 1 by i - FirstOffsetNumber in array filling.
I
Robert Haas robertmh...@gmail.com writes:
On Mon, Sep 20, 2010 at 12:17 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Personally I think this demonstrates that piggybacking replication
data transfer on the COPY protocol was a bad design to start with.
It's probably time to split them apart.
This
... and if so, isn't postmaster.c's code to transfer a HANDLE value to a
child process all wet?
sprintf(paramHandleStr, %lu, (DWORD) paramHandle);
...
paramHandle = (HANDLE) atol(id);
BTW, it seems like it'd be a good thing if we had a Win64 machine in the
buildfarm.
On Mon, Nov 15, 2010 at 7:26 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
On Mon, Sep 20, 2010 at 12:17 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Personally I think this demonstrates that piggybacking replication
data transfer on the COPY protocol was a bad
I am attempting to test this
https://commitfest.postgresql.org/action/patch_view?id=424
but I'm not sure which version of PG this should be applied to. (it would be
really neat, on here:
https://commitfest.postgresql.org/action/commitfest_view?id=8
if there was a note that said, this test
On Sun, Nov 14, 2010 at 6:48 PM, Greg Smith g...@2ndquadrant.com wrote:
The second issue is that the delay between sync calls is currently
hard-coded, at 3 seconds. I believe the right path here is to consider the
current checkpoint_completion_target to still be valid, then work back from
On Sun, Nov 14, 2010 at 9:33 PM, Greg Stark st...@mit.edu wrote:
This is an update to my earlier patch to add getrusage resource
tracking to EXPLAIN ANALYZE.
With this patch you get something like:
QUERY PLAN
Jeff Janes wrote:
Do you know where this competition is happening? Is it on the
platters, or is it in the hard drive write cache (I thought high-end
hardware had tagged writes to avoid that), or in the kernel?
Kernel. Linux systems with lots of memory will happily queue up
gigabytes of
On Mon, Nov 15, 2010 at 4:10 PM, Peter Eisentraut pete...@gmx.net wrote:
ld: file not found: ../../../../../../src/backend/postgres
collect2: ld returned 1 exit status
make[3]: *** [ascii_and_mic.so] Error 1
make[2]: *** [all-ascii_and_mic-recurse] Error 2
make[1]: ***
Robert Haas robertmh...@gmail.com writes:
Very odd, but this completely blew up the first time I tried it.
In file included from path.c:34:
pg_config_paths.h:2:11: error: missing terminating character
FWIW, I didn't replicate that, but I did get this during one attempt
with -j4:
I tried another experiment, which was make -j100 all on my relatively
new Linux box (2 dual-core CPUs). It blew up real good, as per attached
stderr output, which shows evidence of more missing dependencies as well
as some additional cases of concurrent attempts to build the same
target.
It's
71 matches
Mail list logo
