Magnus Hagander wrote:
> >> The existing mechanism
> >> works (as demonstrated by the fact that the contrib modules work on
> >> Windows).
> >
> > Did we use non-standard tools except msvc in the build framework
> > for core code? And what should I do for an external project?
>
> Yes, we use mi
Fujii Masao wrote:
> Currently pg_start_backup() accesses the shared ControlFile
> by using ControlFileLock with LW_EXCLUSIVE lock mode. But
> since that access is read-only operation, LW_SHARED should
> be chosen instead of LW_EXCLUSIVE.
Almost all operations of ControlFileLock is in LW_EXCLUS
Tom Lane wrote:
Hannu Krosing writes:
So SPI interface should also be fixed, either from perl side, or maybe
from inside SPI ?
SPI has every right to assume that data it's given is already in the
database encoding.
Yeah, looks like we missed a few spot
Hi,
Currently pg_start_backup() accesses the shared ControlFile
by using ControlFileLock with LW_EXCLUSIVE lock mode. But
since that access is read-only operation, LW_SHARED should
be chosen instead of LW_EXCLUSIVE.
The attached patch changes the lock mode which pg_start_backup()
uses. Is it wort
Tom Lane wrote:
> Bruce Momjian writes:
> > Tom Lane wrote:
> >> Shouldn't that be back-patched?
>
> > Uh, well, it is going to change the behavior of back branches, and
> > because we only got one report of the bug which has existed since 8.2, I
> > didn't want to risk it. Should I?
>
> I woul
On Sat, Mar 6, 2010 at 12:13 AM, Heikki Linnakangas
wrote:
> The REDO location of last checkpoint might deserve a function of its
> own, like we have pg_last_xlog_replay_location() and
> pg_last_xlog_receive_location().
Agreed. I submitted the patch which introduces new function returning
the RED
On 03/05/2010 10:28 AM, Greg Smith wrote:
> Heikki Linnakangas wrote:
>> Then again, if you don't use the copy in shared memory but just open the
>> pg_control file and read it in the UDF, you could implement this as a
>> pgfoundry module that works with older versions too.
>
> This is the directi
Bruce Momjian writes:
> Tom Lane wrote:
>> Shouldn't that be back-patched?
> Uh, well, it is going to change the behavior of back branches, and
> because we only got one report of the bug which has existed since 8.2, I
> didn't want to risk it. Should I?
I would say that the odds of the initial
Tom Lane wrote:
> Bruce Momjian writes:
> >> I thought some more about it and realized I had to check for the
> >> on-error-exit flag too. Updated patch attached.
>
> > Applied.
>
> Shouldn't that be back-patched?
Uh, well, it is going to change the behavior of back branches, and
because we onl
Hannu Krosing writes:
> So SPI interface should also be fixed, either from perl side, or maybe
> from inside SPI ?
SPI has every right to assume that data it's given is already in the
database encoding.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hac
Bruce Momjian writes:
>> I thought some more about it and realized I had to check for the
>> on-error-exit flag too. Updated patch attached.
> Applied.
Shouldn't that be back-patched?
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.or
Bruce Momjian wrote:
> BBruce Momjian wrote:
> > Tom Lane wrote:
> > > Bruce Momjian writes:
> > > > The attached patch checks for the proper return from BEGIN/COMMIT, and
> > > > properly frees the libpq structures. In testing, this does return 3 as
> > > > you expected.
> > >
> > > Really? It
Jaime Casanova wrote:
> On Mon, Mar 8, 2010 at 4:25 PM, Tom Lane wrote:
> > Jaime Casanova writes:
> >> can we add a parameter in pg_dump and pg_dumpall to disable
> >> log_min_duration_statement?
> >
> > export PGOPTIONS="-c log_min_duration_statement=-1"
> >
>
> ah! so, that is PGOPTIONS for :
On Sat, 2010-01-02 at 20:51 -0500, Andrew Dunstan wrote:
>
> Andrew Dunstan wrote:
> >
> > I think the plperl glue code should check returned strings using
> > pg_verifymbstr().
> >
> >
>
> Please test this patch. I think we'd probably want to trap the encoding
> error and issue a customised
On Mon, Mar 8, 2010 at 4:25 PM, Tom Lane wrote:
> Jaime Casanova writes:
>> can we add a parameter in pg_dump and pg_dumpall to disable
>> log_min_duration_statement?
>
> export PGOPTIONS="-c log_min_duration_statement=-1"
>
ah! so, that is PGOPTIONS for :)
and that works for every libpq applica
Jaime Casanova writes:
> can we add a parameter in pg_dump and pg_dumpall to disable
> log_min_duration_statement?
export PGOPTIONS="-c log_min_duration_statement=-1"
Or use ALTER USER SET to add that to the options for the account
you do pg_dump with; etc etc.
regards,
"Kevin Grittner" writes:
> TODO "not wanted" entry rewritten to address just this one issue.
> The other issues raise in the original post are valid possible
> enhancements, or is there something else to list?:
> http://archives.postgresql.org/pgsql-hackers/2010-03/msg00257.php
I'm not too sure e
Hi,
Every often, i analyze logs to find most slow queries... and every
time i found myself trying to ignore pg_dump's generated COPY commands
which could be very expensive...
can we add a parameter in pg_dump and pg_dumpall to disable
log_min_duration_statement?
--
Atentamente,
Jaime Casanova
So
Tom Lane wrote:
Yes, I think we should narrowly list things we don't want to do.
The current wording reads like "we aren't interested in adopting any
MySQL ideas", which I don't think is actually the project consensus,
not to mention that it doesn't look good from a PR standpoint.
Indeed
On Sun, 2010-03-07 at 16:37 +0100, Magnus Hagander wrote:
> With your interleave, you mean things like "psql -f first.sql -f - -f
> second.sql"? That does sound like it could be handy - and also really
> dangerous :-)
Multiple -f support would be a good thing.
As would mixed -f and -c options.
W
Tom Lane wrote:
> I believe we do have consensus that we aren't interested in
> adopting MySQL's nonstandard GROUP BY semantics. I don't recall
> what else there might be a definite "no" for.
TODO "not wanted" entry rewritten to address just this one issue.
The other issues raise in the ori
On Mon, Mar 8, 2010 at 10:14, Tom Lane wrote:
> "David E. Wheeler" writes:
>> On Mar 8, 2010, at 8:03 AM, Tom Lane wrote:
>>> #3 is still an absolute nonstarter, especially for a patch that we'd
>>> wish to backpatch.
>
>> You're at least going to want to exclude Safe 2.20 - 2.23, IIUC.
>
> If th
So, if php dev doesn't have time to learn to do things right then we
have to find time to learn to do things wrong? seems like a nosense
argument to me
The best ever reply I got from phpBB guys on I don't remember which
question was :
"WE DO IT THIS WAY BECAUSE WE WANT TO SUPPORT MYSQL 3.x
"Kevin Grittner" writes:
> I thought that some of the items on the OP's list were requests to
> add an alternative syntax for an existing feature, without a change
> in semantics. Did I misunderstand that? If not, is it something we
> want to consider?
I think the pre-existing TODO item is evid
Alex Hunsaker writes:
> That being said I would be in favor of at least saying "Hey! your
> using a known broken version of Safe". Maybe something like the below
> at pl_perl init time? (That is instead of requiring >v2.25 just
> complain about older versions)
> elog(WARNING, "Safe versions bef
On Mon, Mar 8, 2010 at 09:03, Tom Lane wrote:
> Tim Bunce writes:
>> 3. requires Safe 2.25 (which has assorted fixes, including security).
> #3 is still an absolute nonstarter, especially for a patch that we'd
> wish to backpatch.
FWIW I think its a given you probably always want the latest ver
Robert Haas wrote:
You do know that SQL is Turing-complete, right?
That seems largely irrelevant to the problem at hand. It's not
impossible to do syntactic transformations from one Turing-complete
langauge to another; if it were, there could be no such thing as a
compiler.
If we
On Mon, Mar 8, 2010 at 12:43 PM, David Fetter wrote:
> On Mon, Mar 08, 2010 at 12:18:31PM -0500, Robert Haas wrote:
>> On Mon, Mar 8, 2010 at 12:10 PM, David Fetter wrote:
>> > On Mon, Mar 08, 2010 at 11:58:20AM -0500, Jaime Casanova wrote:
>> >> On Mon, Mar 8, 2010 at 4:17 AM, Pierre C wrote:
>
2010/3/8 David E. Wheeler :
>> Particularly if the vendor chooses to back-patch
>> Safe security fixes without bumping the visible version number, as is
>> not unlikely for Red Hat in particular.
>
> This is why I hate packaging systems. Frankly, Red Hat's Perl has been
> consistently broken for c
On Mon, Mar 08, 2010 at 12:18:31PM -0500, Robert Haas wrote:
> On Mon, Mar 8, 2010 at 12:10 PM, David Fetter wrote:
> > On Mon, Mar 08, 2010 at 11:58:20AM -0500, Jaime Casanova wrote:
> >> On Mon, Mar 8, 2010 at 4:17 AM, Pierre C wrote:
> >> >
> >> >> My opinion is that PostgreSQL should accept a
On Mar 8, 2010, at 9:14 AM, Tom Lane wrote:
> If those aren't versions that are likely to be in wide use, no objection
> to that.
Yes, those are a series of releases in the last couple of months that had one
level of brokenness or another I'm going to test 2.25 today.
> I'm just concerned about
On Mon, Mar 08, 2010 at 11:03:27AM -0500, Tom Lane wrote:
> Tim Bunce writes:
> > Here's a patch that:
> > 1. adds wording like that to the docs.
> > 2. randomises the container package name (a simple and sound security
> > measure).
> > 3. requires Safe 2.25 (which has assorted fixes, including
On Mon, Mar 8, 2010 at 12:10 PM, David Fetter wrote:
> On Mon, Mar 08, 2010 at 11:58:20AM -0500, Jaime Casanova wrote:
>> On Mon, Mar 8, 2010 at 4:17 AM, Pierre C wrote:
>> >
>> >> My opinion is that PostgreSQL should accept any MySQL syntax and
>> >> return warnings. I believe that we should acc
"David E. Wheeler" writes:
> On Mar 8, 2010, at 8:03 AM, Tom Lane wrote:
>> #3 is still an absolute nonstarter, especially for a patch that we'd
>> wish to backpatch.
> You're at least going to want to exclude Safe 2.20 - 2.23, IIUC.
If those aren't versions that are likely to be in wide use, no
2010/3/9 Jaime Casanova :
> On Mon, Mar 8, 2010 at 4:17 AM, Pierre C wrote:
>>
>>> My opinion is that PostgreSQL should accept any MySQL syntax and return
>>> warnings. I believe that we should access even innodb syntax and turn it
>>> immediately into PostgreSQL tables. This would allow people wi
On Mon, Mar 08, 2010 at 11:58:20AM -0500, Jaime Casanova wrote:
> On Mon, Mar 8, 2010 at 4:17 AM, Pierre C wrote:
> >
> >> My opinion is that PostgreSQL should accept any MySQL syntax and
> >> return warnings. I believe that we should access even innodb
> >> syntax and turn it immediately into Pos
On Mon, Mar 8, 2010 at 4:17 AM, Pierre C wrote:
>
>> My opinion is that PostgreSQL should accept any MySQL syntax and return
>> warnings. I believe that we should access even innodb syntax and turn it
>> immediately into PostgreSQL tables. This would allow people with no
>> interest in SQL to migr
On Mar 8, 2010, at 8:03 AM, Tom Lane wrote:
> #3 is still an absolute nonstarter, especially for a patch that we'd
> wish to backpatch.
You're at least going to want to exclude Safe 2.20 - 2.23, IIUC.
Best,
David
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make c
Tom Lane wrote:
> I think the new item might be phrased a little too broadly. The
> problem with mysql's GROUP BY behavior is not the syntax but the
> nonstandard semantics, ie, that it will pick a random result row
> when the query is underspecified.
I thought that some of the items on the O
Tim Bunce writes:
> Here's a patch that:
> 1. adds wording like that to the docs.
> 2. randomises the container package name (a simple and sound security
> measure).
> 3. requires Safe 2.25 (which has assorted fixes, including security).
> 4. removed a harmless but suprious exclamation mark from
David Christensen writes:
> On Mar 8, 2010, at 9:16 AM, Kevin Grittner wrote:
> Wolfgang Wilhelm wrote:
>>> Isn*t that a good time to think to put that question into the
>>> list of things PostgreSQL doesn*t want to do?
>>
>> Done.
>>
>> http://wiki.postgresql.org/wiki/Todo#Features_We_Do_Not_Wa
Yes, I've seen quite a few of François's posts around on Drupal. Drupal
7 has an OO query building abstraction layer which _should_ address most
of the issues and differences between MySQL, PostgreSQL and SQLite
(newly supported in Drupal 7) because each driver can form the query
string specifi
On Mar 8, 2010, at 9:16 AM, Kevin Grittner wrote:
Robert Haas wrote:
Wolfgang Wilhelm wrote:
Isn*t that a good time to think to put that question into the
list of things PostgreSQL doesn*t want to do?
Yes.
Done.
http://wiki.postgresql.org/wiki/Todo#Features_We_Do_Not_Want
Does this
Robert Haas wrote:
> Wolfgang Wilhelm wrote:
>> Isn*t that a good time to think to put that question into the
>> list of things PostgreSQL doesn*t want to do?
>
> Yes.
Done.
http://wiki.postgresql.org/wiki/Todo#Features_We_Do_Not_Want
-Kevin
--
Sent via pgsql-hackers mailing list (pgsq
On Mon, Mar 8, 2010 at 9:48 AM, Wolfgang Wilhelm
wrote:
> +1
>
> Isn´t that a good time to think to put that question into the list of things
> PostgreSQL doesn´t want to do?
Yes.
...Robert
> Von: Andrew Dunstan
> François Pérou wrote:
>>
>> My opinion is that PostgreSQL should accept any MySQ
+1
Isn´t that a good time to think to put that question into the list of things
PostgreSQL doesn´t want to do?
Cheers
Von: Andrew Dunstan
An: francois.pe...@free.fr
CC: Josh Berkus ; Craig Ringer
; pgsql-hackers@postgresql.org; dp...@pgadmin.org
Gesendet: Sa
On Mon, Mar 8, 2010 at 4:58 AM, Marko Tiikkaja
wrote:
> On 2010-03-08 11:47 +0200, Pierre C wrote:
>>> As far as I can tell, we already do index skip scans:
>>
>> This feature is great but I was thinking about something else, like SELECT
>> DISTINCT, which currently does a seq scan, even if x is i
On Mon, Mar 8, 2010 at 1:39 AM, David Christensen wrote:
>
> On Mar 7, 2010, at 9:22 AM, Tom Lane wrote:
>
>> Magnus Hagander writes:
>>>
>>> 2010/3/6 Tom Lane :
The analogy I was thinking about was psql -X, but I agree that it's
not obvious why this shouldn't be thought of as an a
On Wed, Mar 03, 2010 at 07:01:56PM -0500, Andrew Dunstan wrote:
> Joshua D. Drake wrote:
> >On Wed, 2010-03-03 at 11:33 -0500, Andrew Dunstan wrote:
> >
> >>Well, we could put in similar weasel words I guess. But after
> >>all, Safe's very purpose is to provide a restricted execution
> >>environmen
On Thu, Feb 25, 2010 at 7:48 PM, Fujii Masao wrote:
> On Thu, Feb 25, 2010 at 7:22 PM, Heikki Linnakangas
> wrote:
>> Yeah. The current pg_*_last_location() functions don't cut it though,
>> you need to retain logs back to the redo location of the last
>> restartpoint. That's what %r returns. May
On Mon, Mar 08, 2010 at 10:46:03AM +0900, Takahiro Itagaki wrote:
> There is a complier warning in ecpg/ecpglib/error.c on HEAD:
> ...
> Instead, should we use "if (strcmp(...) == 0)" here?
Exactly. Thanks for spotting this, fixed in HEAD.
Michael
--
Michael Meskes
Michael at Fam-Meskes dot De,
On Fri, Mar 5, 2010 at 3:14 AM, Josh Berkus wrote:
> On 3/4/10 2:47 AM, Fujii Masao wrote:
>> This TODO item really needs to be addressed for 9.0? Frankly I'm not
>> familiar with that area, so I've not work on it at all yet, but I'm
>> going to create the patch if many people want it for 9.0. Wha
Oh, this is what I believe MySQL calls "loose index scans". I'm
Exactly :
http://dev.mysql.com/doc/refman/5.0/en/loose-index-scan.html
actually looking into this as we speak,
Great ! Will it support the famous "top-n by category" ?
but there seems to be a
non-trivial amount of work to b
2010/3/8 Takahiro Itagaki :
>
> Tom Lane wrote:
>
>> Takahiro Itagaki writes:
>> > I'd like to propose to define PGALWAYSEXPORT macro:
>> > #ifdef WIN32
>> > #define PGALWAYSEXPORT __declspec (dllexport)
>> > #endif
>> > and modify PG_MODULE_MAGIC and PG_FUNCTION_INFO_V1 to use it
>>
2010/3/7 Zdenek Kotala :
> Magnus Hagander píše v po 01. 03. 2010 v 16:55 +0100:
>> 2010/3/1 Zdenek Kotala :
>> > Magnus Hagander píše v čt 25. 02. 2010 v 15:17 +0100:
>> >> On Thu, Feb 25, 2010 at 15:04, Zdenek Kotala
>> >> wrote:
>> >> > Hi all,
>> >> >
>> >> > I got following stack:
>> >> >
>>
On 2010-03-08 11:47 +0200, Pierre C wrote:
>> As far as I can tell, we already do index skip scans:
>
> This feature is great but I was thinking about something else, like SELECT
> DISTINCT, which currently does a seq scan, even if x is indexed.
>
> Here is an example. In both cases it could us
As far as I can tell, we already do index skip scans:
This feature is great but I was thinking about something else, like SELECT
DISTINCT, which currently does a seq scan, even if x is indexed.
Here is an example. In both cases it could use the index to skip all
non-interesting rows, pulli
On 2010-03-08 11:17 +0200, Pierre C wrote:
> - index skip scans (well, MySQL doesn't really do index skip scans, but
> since it can do index-only scans, it's an approximation)
As far as I can tell, we already do index skip scans:
=> create index foo_a_b_idx on foo(a,b);
CREATE INDEX
=> explain
On Sun, Mar 07, 2010 at 12:11:26PM -0500, Tom Lane wrote:
> Tim Bunce writes:
> > I encountered a core dump running PL/Perl installcheck with a very
> > recent git HEAD of PostgreSQL and a not quite so recent git HEAD of perl.
>
> > The cause is a subtle difference between SvTYPE(sv) == SVt_RV an
My opinion is that PostgreSQL should accept any MySQL syntax and return
warnings. I believe that we should access even innodb syntax and turn it
immediately into PostgreSQL tables. This would allow people with no
interest in SQL to migrate from MySQL to PostgreSQL without any harm.
A solution
60 matches
Mail list logo
