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 thi
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
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 ora
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
s
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 he
> "Kevin" == "Kevin Grittner" 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
>> 'Chile/Santiago', '
Andrew Chernow 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 CHECK_FOR_INTE
Tom Lane wrote:
Andrew Chernow 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 st
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 the
Andrew Chernow 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 committing,
Andrew Dunstan 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 finish setting
Tom Lane wrote:
Andrew Chernow 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 are full on wr
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.
Andrew Chernow 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 make changes
Josh Berkus 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 unreliable signali
Andrew Dunstan 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, tom lane
--
Sent v
Joachim Wieland 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 signalled
>
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 ow
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 vi
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
> proce
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 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.
--
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
shared_preload_librar
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 wrote:
>
>> In addition, I could find a few matters.
>> * TOAST may be necessary for pg_trigger?
>
> I added
On Thu, Nov 19, 2009 at 1:48 AM, Tom Lane wrote:
> Joachim Wieland 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 c
On Mon, Nov 16, 2009 at 2:35 PM, Andrew Chernow 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 rathe
Joachim Wieland 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 overhead
when t
"Joshua D. Drake" 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 were you expecting
"Joshua D. Drake" 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:
http://www.postgresql.org
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 select
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
Itagaki Takahiro writes:
> "Albe Laurenz" 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 modifications. Aside from the added valuntil
paramete
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 *wi
Itagaki Takahiro 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 policies
tend to want a lim
> 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 proc
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 -
Andrew Gierth 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
> 'Chile/Santiago', 'Chile/San
"Joshua D. Drake" 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 reasonable if we c
On Wed, 2009-11-18 at 12:28 -0500, Tom Lane wrote:
> "Joshua D. Drake" 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 choos
"Joshua D. Drake" 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 disaster.
> Agr
George Gensure 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 the approach
yo
On Wed, 2009-11-18 at 12:06 -0500, Tom Lane wrote:
> Nathan Boley 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. Tha
Tom Lane 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 sets that readi
Nathan Boley 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 upthread. I'm not
a P
> 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 be
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,
2009/11/18 Oleg Bartunov :
> 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
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 develop
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 expec
Peter Eisentraut 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 that, but the wo
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 case
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 anomal
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 s
Robert Haas 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 operator class.
Wild gue
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
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 t
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 declar
2009/11/18 Peter Eisentraut :
> 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 SQL/PSM part
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 (pgsql-hackers@postgres
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] == '
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/
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
2009/11/18 Peter Eisentraut :
> 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 if SQL s
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 ma
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 tim
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
is
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 i
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,
virtualxi
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 (pgsql-hackers@postg
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 bac
On ons, 2009-11-18 at 12:52 +0900, Itagaki Takahiro wrote:
> Peter Eisentraut 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 cmd.exe. Bu
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
Th
On Wed, 2009-11-18 at 13:24 +0900, Itagaki Takahiro wrote:
> Simon Riggs 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 partitioning
> into se
73 matches
Mail list logo
