On Wed, 2009-11-18 at 13:24 +0900, Itagaki Takahiro wrote:
Simon Riggs si...@2ndquadrant.com wrote:
Why not just wait until we have a whole patch and then apply?
A whole patch can be written by many contributers instead of only
one person, no? I think we need to split works for
Wojciech,
your polish_english, polish configurations uses ispell language and slow,
while english configuration doesn't contains ispell. So, what's your
complains ? Try add ispell dictionary to english configuration and see
timings.
Oleg
On Wed, 18 Nov 2009, Wojciech Knapik wrote:
Hello
On ons, 2009-11-18 at 12:52 +0900, Itagaki Takahiro wrote:
Peter Eisentraut pete...@gmx.net wrote:
Together, that should cover a lot of cases. Not perfect, but far from
useless.
For Japanese users on Windows, the client encoding are always set to SJIS
because of the restriction of
On tis, 2009-11-17 at 23:22 -0500, Andrew Dunstan wrote:
Itagaki Takahiro wrote:
I don't want user to check the encoding of scripts before executing
--
it is far from fail-safe.
That's what we require in all other cases. Why should UTF8 be special?
But now we're back to the
On tis, 2009-11-17 at 17:09 -0500, Tom Lane wrote:
I can see the following definitional issues:
Should we be able to find the answers to those, or at least a basis of
discussion about those, in the SQL standard? Has anyone checked?
--
Sent via pgsql-hackers mailing list
Thank you for the hints.
Why only those modes? I'd search for locks with granted=false, then see
all the other locks held by the process that's holding the conflicting
lock with granted=true (i.e. the one you're waiting on).
Something like this?
SELECT
granted,
pid,
virtualxid,
Tom Lane wrote:
I tested on 8.3.1 on G5/OSX 10.5.8 and Xeon/Gentoo AMD64-2008.0
(2.6.21), then switched both installations to 8.3.8 (both packages
compiled from source, but provided by the distro - port/emerge). The
Polish dictionaries and config were created according to this article
(it's
your polish_english, polish configurations uses ispell language and slow,
while english configuration doesn't contains ispell. So, what's your
complains ? Try add ispell dictionary to english configuration and see
timings.
Oh, so this is not anomalous ? These are the expected speeds for an
Itagaki Takahiro wrote:
Looks good. I change status of the patch to Ready for Committer.
Thanks for the help!
BTW, it might not be a work for this patch, we also need to
reject too long VALID UNTIL setting. If the password is
complex, we should not use the same password for a long time.
On Nov 18, 2009, at 5:46 AM, Andrew Dunstan wrote:
Joshua Tolley wrote:
+plperl_call_data *save_call_data = current_call_data;
+boololdcontext = trusted_context;
+ + if (SPI_connect() != SPI_OK_CONNECT)
+elog(ERROR, could not connect to SPI manager);
2009/11/18 Peter Eisentraut pete...@gmx.net:
On tis, 2009-11-17 at 17:09 -0500, Tom Lane wrote:
I can see the following definitional issues:
Should we be able to find the answers to those, or at least a basis of
discussion about those, in the SQL standard? Has anyone checked?
I am not sure
Looking at how byteain detects whether the input it is passed is the new
hex format escape or the old octal escape, it uses:
char *inputText = PG_GETARG_CSTRING(0);
if (inputText[0] == '\\' inputText[1] == 'x')
Doesn't this read off the end of inputText in the case of
Tatsuo Ishii wrote:
Please correct me if I'm wrong. Parse will result in obtaining
RowExclusiveLock on the target table if it is parsing
INSERT/UPDATE/DELETE. If so, is this ok in the standby?
Any attempt to take RowExclusiveLock will fail.
Any attempt to execute INSERT/UPDATE/DELETE will
On ons, 2009-11-18 at 06:46 -0500, Kris Jurka wrote:
Looking at how byteain detects whether the input it is passed is the new
hex format escape or the old octal escape, it uses:
char *inputText = PG_GETARG_CSTRING(0);
if (inputText[0] == '\\' inputText[1] == 'x')
On ons, 2009-11-18 at 11:46 +0100, Pavel Stehule wrote:
I am not sure if SQL standard is good inspiration in this case.
I'm not sure either, but I think it's premature to make a conclusion
about that without having checked at all.
--
Sent via pgsql-hackers mailing list
2009/11/18 Peter Eisentraut pete...@gmx.net:
On ons, 2009-11-18 at 11:46 +0100, Pavel Stehule wrote:
I am not sure if SQL standard is good inspiration in this case.
I'm not sure either, but I think it's premature to make a conclusion
about that without having checked at all.
ok, I recheck
Peter Eisentraut wrote:
But now we're back to the original problem. Certain editors insert BOMs
at the beginning of the file. And that is by any definition before the
embedded client encoding declaration. I think the only ways to solve
this are:
1) Ignore the BOM if a client encoding
I'm in Tokyo right now, so please excuse my abbreviated reply.
On Tue, 2009-11-17 at 23:13 -0500, Robert Haas wrote:
Forgive me if this is discussed before, but why does this store the
strategy numbers of the relevant operators instead of the operators
themselves?
At constraint definition
On ons, 2009-11-18 at 08:52 -0500, Andrew Dunstan wrote:
4) set the client encoding before the file is read in any of the ways
that have already been discussed and then allow psql to eat the BOM.
This is certainly a workaround, just like piping the file through a
suitable sed expression would
Robert Haas robertmh...@gmail.com writes:
Forgive me if this is discussed before, but why does this store the
strategy numbers of the relevant operators instead of the operators
themselves? It seems like this could lead to surprising behavior if
the user modifies the definition of the
All,
FWIW, I'm doing a redesign of a client's production web application
right now. I was able, by combining OEC and the Period type from
pgfoundry, to make a set of constraints for declaratively asserting in a
sports database:
That the same player couldn't belong to two different teams at the
On Wed, 18 Nov 2009, Wojciech Knapik wrote:
your polish_english, polish configurations uses ispell language and slow,
while english configuration doesn't contains ispell. So, what's your
complains ? Try add ispell dictionary to english configuration and see
timings.
Oh, so this is not
Attached is a patch to perform parameter reference lookups by name in
the body of functions. I'm hesitant to put it in for the commitfest
as is, without a couple of questions posed to the group:
1. palloc needs no free? I suppose this is a general knowledge
question, but it seemed to be the
Peter Eisentraut pete...@gmx.net writes:
This is certainly a workaround, just like piping the file through a
suitable sed expression would be, but conceptually, the client encoding
is a property of the file and should therefore be marked in the file.
In a perfect world things would be like
Oleg Bartunov wrote:
your polish_english, polish configurations uses ispell language
and slow, while english configuration doesn't contains ispell.
So, what's your complains ? Try add ispell dictionary to english
configuration and see timings.
Oh, so this is not anomalous ? These are the
On sön, 2009-11-15 at 18:39 -0700, James Pye wrote:
I can see how function modules might look like a half-step backwards from
function fragments at first, but the benefits of a *natural* initialization
section (the module body) was enough to convince me. The added value on the
PL
2009/11/18 Oleg Bartunov o...@sai.msu.su:
On Wed, 18 Nov 2009, Wojciech Knapik wrote:
your polish_english, polish configurations uses ispell language and slow,
while english configuration doesn't contains ispell. So, what's your
complains ? Try add ispell dictionary to english configuration
On Wed, 18 Nov 2009, Wojciech Knapik wrote:
Yes, for 4-word texts the results are similar.
Try that with a longer text and the difference becomes more and more
significant. For the lorem ipsum text, 'polish' is about 4 times slower, than
'english'. For 5 repetitions of the text, it's 6 times,
Again, I'm only one user. But so far I haven't seen anyone else speak
up here, and clearly accepting this for inclusion will need nontrivial
convincing.
Well, FWIW, I am excited about better type integration.
Also, I am a little skeptical about this patch. I am sorry if this has
already been
Nathan Boley npbo...@gmail.com writes:
Also, I am a little skeptical about this patch. I am sorry if this has
already been discussed, but would this mean that I need to choose
whether pl/python is built against Python 2.* or Python 3.*?
Yes. That's exactly what I was complaining about
Tom Lane t...@sss.pgh.pa.us wrote:
there is a constituency that cares --- mainly people who use
client-side code that tends to fall over if it doesn't see a
suitable maxlength attached to query result columns.
I suspect it will primarily be software which is dealing with large
enough result
On Wed, 2009-11-18 at 12:06 -0500, Tom Lane wrote:
Nathan Boley npbo...@gmail.com writes:
Also, I am a little skeptical about this patch. I am sorry if this has
already been discussed, but would this mean that I need to choose
whether pl/python is built against Python 2.* or Python 3.*?
George Gensure wer...@gmail.com writes:
Attached is a patch to perform parameter reference lookups by name in
the body of functions. I'm hesitant to put it in for the commitfest
as is, without a couple of questions posed to the group:
I looked through this very quickly. I'm not in favor of
Joshua D. Drake j...@commandprompt.com writes:
On Wed, 2009-11-18 at 12:06 -0500, Tom Lane wrote:
Yes. That's exactly what I was complaining about upthread. I'm not
a Python user, but from what I can gather of the 2-to-3 changes,
having to choose one at package build time is going to be a
On Wed, 2009-11-18 at 12:28 -0500, Tom Lane wrote:
Joshua D. Drake j...@commandprompt.com writes:
On Wed, 2009-11-18 at 12:06 -0500, Tom Lane wrote:
Yes. That's exactly what I was complaining about upthread. I'm not
a Python user, but from what I can gather of the 2-to-3 changes,
having
Joshua D. Drake j...@commandprompt.com writes:
On Wed, 2009-11-18 at 12:28 -0500, Tom Lane wrote:
Peter was concerned about duplicative maintenance effort, but what I
think this patch shows is that (at least for the near future) both
could be built from a single source file.
That seems
Andrew Gierth and...@tao11.riddles.org.uk wrote:
If he meant (A), then you store the event as:
(ts,tz) = (timestamp '2010-07-27 10:30:00',
'Chile/Santiago')
If he meant (B), then you store the event as
(tsz,tz) = (timestamp '2010-07-27 10:30:00' at time zone
Oleg Bartunov wrote:
Yes, for 4-word texts the results are similar.
Try that with a longer text and the difference becomes more and more
significant. For the lorem ipsum text, 'polish' is about 4 times
slower, than 'english'. For 5 repetitions of the text, it's 6 times,
for 10 repetitions -
Here's the patch to support Python =3.1 with PL/Python. The
compatibility code is mostly in line with the usual 2-3 C porting
practice and is documented inline.
I took a cursory look at this patch and, while the logic seems sound
and roughly in line with the suggested python porting
Itagaki Takahiro itagaki.takah...@oss.ntt.co.jp writes:
BTW, it might not be a work for this patch, we also need to
reject too long VALID UNTIL setting. If the password is
complex, we should not use the same password for a long time.
This is a good point --- people who have password strength
On Nov 18, 2009, at 8:37 AM, Peter Eisentraut wrote:
The question is whether it helps the user, not the implementer.
Sure, but do you have a patch waiting to implement tracebacks?
I'd argue the reason it's never been done is due to the way procedures are
currently managed in PL/Python. And
Itagaki Takahiro itagaki.takah...@oss.ntt.co.jp writes:
Albe Laurenz laurenz.a...@wien.gv.at wrote:
I agree on the second point, and I changed the patch accordingly.
Here's the latest version.
Looks good. I change status of the patch to Ready for Committer.
Applied with some minor
Hey,
So I ran across this today:
CREATE OR REPLACE FUNCTION RETURN_LOTS(INT) RETURNS SETOF INT AS
$$
SELECT generate_series(1,$1);
$$
COST 0.5 ROWS 50 SET work_mem TO '5MB' LANGUAGE 'SQL';
postgres=# explain analyze select return_lots(1000);
QUERY PLAN
I was just writing a syntical example and wanted to make sure it worked.
I found this:
CREATE OR REPLACE FUNCTION RETURN_LOTS(INT) RETURNS SETOF INT AS
$$
SELECT generate_series(1,$1);
$$ COST 0.5 ROWS 1000 SET work_mem TO '5MB' LANGUAGE 'SQL';
postgres=# explain analyze
Joshua D. Drake j...@commandprompt.com writes:
Shouldn't the estimated rows be 50?
It is if you do select * from return_lots(1000).
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
Joshua D. Drake j...@commandprompt.com writes:
This is repeatable. I expect a little regression because we have to
compile the SQL but 14 seconds?
generate_series is a quite efficient C function. I think it's pretty
damn good that the overhead of a SQL function on top of that is only 2X.
Or
Joachim Wieland j...@mcknight.de writes:
4) Allow readers to read uncommitted notifications as well.
The question that strikes me here is one of timing --- apparently,
readers will now have to check the queue *without* having received
a signal? That could amount to an unpleasant amount of extra
On Mon, Nov 16, 2009 at 2:35 PM, Andrew Chernow a...@esilo.com wrote:
1) drop new notifications if the queue is full (silently or with
rollback)
I like this one best, but not with silence of course. While it's not the
most
polite thing to do, this is for a super extreme edge case. I'd
On Thu, Nov 19, 2009 at 1:48 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Joachim Wieland j...@mcknight.de writes:
4) Allow readers to read uncommitted notifications as well.
The question that strikes me here is one of timing --- apparently,
readers will now have to check the queue *without* having
Itagaki-san,
I don't have any more comments in this patch, so I hope it to be reviewed
by committers then upstreamed.
Thanks for your good jobs.
Itagaki Takahiro wrote:
KaiGai Kohei kai...@ak.jp.nec.com wrote:
In addition, I could find a few matters.
* TOAST may be necessary for
So I went to investigate bug #5196: turned on log_destination = csvlog
etc, and restarted the postmaster. I got this on stderr:
2009-11-18 20:08:52.104 EST : : LOG: loaded library passwordcheck
Not safe to send CSV data
The first line is a consequence of having still got
On Nov 18, 2009, at 1:36 PM, James Pye wrote:
At this point, I'm not going to try getting it into PG. (apparent futility
and such)
ugh, on second thought, I think I've written a bit too much code to stop now.
I'm going to get plpython3 as far as I can and submit it to the next commitfest.
--
That is, if the queue overflows what you should do is drop the
payloads and condense all the messages for a given class into a single
notification for that class with unknown payload. That way if a
cache which wants to invalidate specific objects gets a queue overflow
condition then at least it
On 11/16/09 3:19 AM, Joachim Wieland wrote:
1) drop new notifications if the queue is full (silently or with rollback)
2) block until readers catch up (what if the backend that tries to write the
notifications actually is the lazy reader that everybody is waiting for
to
proceed?)
We should probably also log the fact that we ran out of room, so that
the DBA knows that they ahve a design issue.
Can't they just bump allowed memory and avoid a redesign?
Alternately, it would be great to have a configuration option which
would allow the DBA to choose any of 3 behaviors
Overview:
Patch to make data output that includes newlines wrapped lines
consistent with the headers for that data.
Link: https://commitfest.postgresql.org/action/patch_view?id=220
Submission review:
* is in context diff
* applies cleanly to current HEAD
* includes its
Joachim Wieland j...@mcknight.de writes:
The sequence in CommitTransaction() is like that:
1) add notifications to queue
2) commit to clog
3) signal backends
Only those backends are signalled that listen to at least one channel,
if the notify system isn't in use, then nobody will ever be
Andrew Dunstan and...@dunslane.net writes:
So the logger there has been doing CSV logging for quite a while without
memory ballooning.
I was able to generate a noticeable leak by cranking log_rotation_size
way down ... it's about 1K per size rotation event.
regards,
Josh Berkus j...@agliodbs.com writes:
(4) drop *old* notifications if the queue is full.
Since everyone has made the point that LISTEN is not meant to be a full
queueing system, I have no problem dropping notifications LRU-style.
NO, NO, NO, a thousand times no!
That turns NOTIFY into an
Andrew Chernow a...@esilo.com writes:
I mentioned this up thread. I completely agree that overflow behavior should
be
tunable.
There is only one correct overflow behavior.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To
Itagaki Takahiro escreveu:
Here is a patch to add ProcessUtility_hook to handle all DDL
commands in user modules. (ProcessUtility_hook_20091021.patch)
It adds a global variable 'ProcessUtility_hook' and
export the original function as 'standard_ProcessUtility'.
I've reviewed your patch. It
Tom Lane wrote:
Andrew Chernow a...@esilo.com writes:
I mentioned this up thread. I completely agree that overflow behavior should be
tunable.
There is only one correct overflow behavior.
I count three.
1. wait
2. error
3. skip
#1 and #2 are very similar to a file system. If FS buffers
Andrew Dunstan and...@dunslane.net writes:
Tom Lane wrote:
And the fact that it comes out at all suggests that
the csvlog startup logic is rather broken. Comments?
Not sure why you say that. This can only happen very early in the
startup process before the postmaster has had a chance to
Andrew Chernow a...@esilo.com writes:
Tom Lane wrote:
There is only one correct overflow behavior.
I count three.
Waiting till you can insert is reasonable (especially if we have some
behavior that nudges other backends to empty the queue). If by skip
you mean losing the notify but still
Tom Lane wrote:
In any case
there will certainly always be *some* postmaster messages that could
be emitted after setting the log_destination GUC and before launching
the syslogger child. If the designed behavior is that we dump to
stderr during that interval, we should just do it, without
Tom Lane wrote:
Andrew Chernow a...@esilo.com writes:
Tom Lane wrote:
There is only one correct overflow behavior.
I count three.
Waiting till you can insert is reasonable (especially if we have some
behavior that nudges other backends to empty the queue). If by skip
you mean losing the
Andrew Chernow a...@esilo.com writes:
Personally, I would just wait until room became available or the transaction
was
canceled.
Works for me, as long as there's a CHECK_FOR_INTERRUPTS in there to
allow a cancel to happen. The current patch seems to have a lot of
pointless logging and no
Kevin == Kevin Grittner kevin.gritt...@wicourts.gov writes:
If he meant (A), then you store the event as:
(ts,tz) = (timestamp '2010-07-27 10:30:00',
'Chile/Santiago')
If he meant (B), then you store the event as
(tsz,tz) = (timestamp '2010-07-27 10:30:00' at time zone
ts_headline calls ts_lexize equivalent to break the text. Off course there
is algorithm to process the tokens and generate the headline. I would be
really surprised if the algorithm to generate the headline is somehow
dependent on language (as it only processes the tokens). So Oleg is right
when
Tom Lane wrote:
So I went to investigate bug #5196: turned on log_destination = csvlog
etc, and restarted the postmaster. I got this on stderr:
2009-11-18 20:08:52.104 EST : : LOG: loaded library passwordcheck
Not safe to send CSV data
The first line is a consequence of having still got
Andrew Dunstan wrote:
I've been reading over the documentation to find an alternative to
the deprecated xpath_table functionality. I think it may be a
possibility but I'm not seeing a clear alternative.
Thanks,
Chris Graner
The standard is XMLTABLE and is implemented by both db2 and
On Wed, 2009-11-18 at 14:51 +0200, Heikki Linnakangas wrote:
Tatsuo Ishii wrote:
Please correct me if I'm wrong. Parse will result in obtaining
RowExclusiveLock on the target table if it is parsing
INSERT/UPDATE/DELETE. If so, is this ok in the standby?
Any attempt to take
Tom Lane wrote:
Applied with some minor modifications. Aside from the added valuntil
parameter, I changed the isencrypted parameter to an int with some
#define'd values. It seems easily foreseeable that we'll replace the
MD5 encryption scheme someday, and it'd be good to ensure that this
73 matches
Mail list logo
