On Thu, Feb 4, 2010 at 6:39 AM, Erik Rijkers wrote:
> However, whenever (re-)starting the slave the I get
> messages like:
>
> cp: cannot stat
> `/var/data1/pg_stuff/dump/replication_archive/00010002': No
> such
> file or directory
>
> At this point, /var/data1/pg_stuff/dump/rep
On Fri, Dec 5, 2008 at 11:41 PM, Randy Isbell wrote:
> An inconsistency exists between the segment name reported by
> pg_stop_backup() and the actual WAL file name.
>
>
> SELECT pg_start_backup('filename');
> pg_start_backup
> -
> 10/FE1E2BAC
> (1 row)
Tom Lane wrote:
> Alvaro Herrera writes:
>> FWIW I think there's another problem with streaming replication here,
>> which is that most data flows from client to server, so it would take
>> quite some time for the threshold to be reached. Note that there's no
>> size check in the libpq frontend c
On Wed, Feb 3, 2010 at 4:51 PM, Oleg Bartunov wrote:
> On Wed, 3 Feb 2010, Robert Haas wrote:
>
>>> I'll repeat my tests with current CVS HEAD.
>>
>> OK... can you post the exact queries that you are used for the
>> previous round of testing?
>
> Robert, Mark posted all queries in his post ! See
>
On Wed, Feb 3, 2010 at 5:57 PM, Andrew Dunstan wrote:
> marcin mank wrote:
>> A certain prominent web framework has a nasty SQL injection bug when
>> PG is configured with SCS. This bug is not present without SCS
>> (details per email for interested PG hackers). I say, hold it off.
>
> Any web fra
On Wed, Feb 3, 2010 at 6:41 PM, Andrew Dunstan wrote:
>> What I was actually wondering about, however, is the extent to which
>> the semantics of Perl code could be changed from an on_init hook ---
>> is there any equivalent of changing search_path or otherwise creating
>> trojan-horse code that m
Joe Conway writes:
> Any objection if I add these two macros to libpq-fe.h?
> ---
> + /* Useful macros for PQconnectdbParams() and PQconnectStartParams() */
> + #define DECL_PARAMS_ARRAYS(PARAMS_ARRAY_SIZE) \
> + const char **keywords = pg_malloc(PARAMS_ARRAY_SIZE * \
> +
[moving to hackers]
On 02/02/2010 10:23 PM, Tom Lane wrote:
> Joe Conway writes:
>> Should I also be looking to replace all (or most) other instances of
>> PQsetdbLogin()?
>
> I think we at least wanted to fix pg_dump(all)/pg_restore. Not sure if
> the others are worth troubling over.
Any obje
Tom Lane wrote:
Andrew Dunstan writes:
%_SHARED has been around for several years now, and if there are genuine
security concerns about it ISTM they would apply today, regardless of
these patches.
Yes. I am not at all happy about inserting nonstandard permissions
checks into GUC a
marcin mank wrote:
A certain prominent web framework has a nasty SQL injection bug when
PG is configured with SCS. This bug is not present without SCS
(details per email for interested PG hackers). I say, hold it off.
Any web framework that interpolates user supplied values into SQL rath
A certain prominent web framework has a nasty SQL injection bug when
PG is configured with SCS. This bug is not present without SCS
(details per email for interested PG hackers). I say, hold it off.
Greetings
Marcin Mańk
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To ma
On Wed, 3 Feb 2010, Robert Haas wrote:
I'll repeat my tests with current CVS HEAD.
OK... can you post the exact queries that you are used for the
previous round of testing?
Robert, Mark posted all queries in his post ! See
http://archives.postgresql.org/pgsql-hackers/2010-01/msg02927.php
Josh Berkus writes:
>> I still think that changing it now is going to open a can of worms that
>> we shouldn't be opening at this stage. We have got more than enough to
>> worry about for 9.0 already. I think it is absolute folly to believe
>> that this is only going to be a matter of "flip the
Hello,
Testing 9.0devel HS/SR: I used cvs HEAD (today) with
the new_smart_shutdown_20100201.patch of Fujii Masao.
Replication works well. The slave can be stopped and restarted.
However, whenever (re-)starting the slave the I get
messages like:
cp: cannot stat
`/var/data1/pg_stuff/dump/replic
Tom Lane writes:
> And that's just for the core code. I don't want to blindside driver
> writers and other third-party authors with a change like this made at
> the end of the cycle. If we do it at the beginning of the 9.1 devel
> cycle, no one will have room to argue that they didn't have adequ
On Wed, 03 Feb 2010 14:41:13 -0500, Tom Lane wrote:
> Indeed it is, which is one of the reasons to be cautious with changing
> it. We've been telling people to move away from \' for a long time,
> but actually flipping the switch that will make their apps insecure
> is not something to do on the
On Wed, Feb 3, 2010 at 4:17 PM, Oleg Bartunov wrote:
> On Wed, 3 Feb 2010, Robert Haas wrote:
>
>>> Robert, Mark described the test he did
>>> http://archives.postgresql.org/pgsql-hackers/2010-01/msg02927.php
>>
>> So why did he get totally different answers than you?
>
> Because I did tests with
On Wed, 3 Feb 2010, Robert Haas wrote:
Robert, Mark described the test he did
http://archives.postgresql.org/pgsql-hackers/2010-01/msg02927.php
So why did he get totally different answers than you?
Because I did tests with 8.3 and HEAD+rbtree, while Mark compared
HEAD and HEAD+rbtree. Also,
On Wed, Feb 03, 2010 at 02:32:47PM -0500, Tom Lane wrote:
> Joshua Tolley writes:
> > I'd really like to see the data from pg_config and pg_controldata available
> > through SQL, such as by adding output to pg_show_all_settings(), or adding
> > new
> > SRFs named something like pg_config() and pg
On Wed, Feb 3, 2010 at 2:38 PM, Tim Bunce wrote:
>> What I was actually wondering about, however, is the extent to which
>> the semantics of Perl code could be changed from an on_init hook ---
>> is there any equivalent of changing search_path or otherwise creating
>> trojan-horse code that might
Mark Mielke writes:
> On 02/03/2010 01:20 PM, Robert Haas wrote:
>> I am not sure I really understand why anyone is a rush to make this
>> change.
> For myself, it isn't so much a rush as a sense that the code out there
> that will break, will never change unless forced, and any time seems
> be
On 02/03/2010 10:18 AM, Tom Lane wrote:
> Joe Conway writes:
>> The problem exists with all three dblink_build_sql_* functions. Here is
>> a more complete patch. If there are no objections I'll apply this to
>> HEAD and look at back-patching -- these functions have hardly been
>> touched since inc
On Wed, Feb 03, 2010 at 02:04:47PM -0500, Tom Lane wrote:
> Andrew Dunstan writes:
> > %_SHARED has been around for several years now, and if there are genuine
> > security concerns about it ISTM they would apply today, regardless of
> > these patches.
>
> Yes. I am not at all happy about inse
On Wed, Feb 3, 2010 at 2:25 PM, Mark Mielke wrote:
> On 02/03/2010 01:20 PM, Robert Haas wrote:
>> I am not sure I really understand why anyone is a rush to make this
>> change. What harm is being done by the status quo? What benefit do
>> we get out of changing the default? The major argument
Rod Taylor escribió:
> As much as I would like GUCs to disappear I think this one should
> proceed cautiously and probably be a 9.1 or even 9.2 item.
Note that this is *not* about removing the configuration setting, only
about flipping its default value. There has been *no* talk of removing
the
Joshua Tolley writes:
> I'd really like to see the data from pg_config and pg_controldata available
> through SQL, such as by adding output to pg_show_all_settings(), or adding new
> SRFs named something like pg_config() and pg_controldata(). Does this make as
> much sense to the rest of the world
On 02/03/2010 02:15 PM, Robert Haas wrote:
The longer we wait before making an
incompatible change, the more people will have adjusted their code to
the new reality (or upgraded their drivers, etc.) and the fewer things
will break.
In my experience, the opposite is true, although in this ca
Alex Hunsaker writes:
> On Wed, Feb 3, 2010 at 12:04, Tom Lane wrote:
>> Yes. Â I am not at all happy about inserting nonstandard permissions
>> checks into GUC assign hooks
> I think Tims solution is just to check in plperl.c right before we
> eval it so not at SET time.
Well, that would be *c
On 02/03/2010 01:20 PM, Robert Haas wrote:
I am not sure I really understand why anyone is a rush to make this
change. What harm is being done by the status quo? What benefit do
we get out of changing the default? The major argument that has been
offered so far is that "if we don't change it n
On Wed, Feb 3, 2010 at 12:04, Tom Lane wrote:
> Andrew Dunstan writes:
>> %_SHARED has been around for several years now, and if there are genuine
>> security concerns about it ISTM they would apply today, regardless of
>> these patches.
>
> Yes. I am not at all happy about inserting nonstandard
On Wed, Feb 3, 2010 at 1:49 PM, Alex Hunsaker wrote:
> On Wed, Feb 3, 2010 at 11:43, Alex Hunsaker wrote:
>> On Wed, Feb 3, 2010 at 11:28, Tom Lane wrote:
>>> Tim Bunce writes:
I do see a need for a GRANT check and I'm adding one now (based on
the code in CreateFunction() in functionc
"Greg Sabino Mullane" writes:
> Which fallout are we still dealing with? Are you saying that the
> developers are not up to the challenge of handling this before 9.0
> is released? (If this were anything more than a simple boolean GUC
> fix, I would be in your corner).
I'm not certain that Robert
On Wed, Feb 3, 2010 at 1:46 PM, Greg Sabino Mullane wrote:
>>> Perl (DBD::Pg anyway) has been compatible since May 2008.
>
>> I would interpret that to mean that there is a significant possibility
>> that a too-old DBD::Pg could get used with a new PostgreSQL, and
>> therefore we shouldn't change
On Feb 3, 2010, at 11:04 AM, Tom Lane wrote:
> What I was actually wondering about, however, is the extent to which
> the semantics of Perl code could be changed from an on_init hook ---
> is there any equivalent of changing search_path or otherwise creating
> trojan-horse code that might be execu
I'd really like to see the data from pg_config and pg_controldata available
through SQL, such as by adding output to pg_show_all_settings(), or adding new
SRFs named something like pg_config() and pg_controldata(). Does this make as
much sense to the rest of the world as it does to me? In particula
> I still think that changing it now is going to open a can of worms that
> we shouldn't be opening at this stage. We have got more than enough to
> worry about for 9.0 already. I think it is absolute folly to believe
> that this is only going to be a matter of "flip the default and nothing
> el
On Wed, Feb 3, 2010 at 13:20, Robert Haas wrote:
> On Wed, Feb 3, 2010 at 12:34 PM, Greg Sabino Mullane
> wrote:
>> Perl (DBD::Pg anyway) has been compatible since May 2008.
>
> I would interpret that to mean that there is a significant possibility
> that a too-old DBD::Pg could get used with a
Andrew Dunstan writes:
> %_SHARED has been around for several years now, and if there are genuine
> security concerns about it ISTM they would apply today, regardless of
> these patches.
Yes. I am not at all happy about inserting nonstandard permissions
checks into GUC assign hooks --- they ar
Tom Lane wrote:
Tim Bunce writes:
I do see a need for a GRANT check and I'm adding one now (based on
the code in CreateFunction() in functioncmds.c - thanks to RhodiumToad
on IRC for the pointer).
What exactly are you proposing to check, and where, and what do you
think that will fi
On Wed, Feb 3, 2010 at 11:43, Alex Hunsaker wrote:
> On Wed, Feb 3, 2010 at 11:28, Tom Lane wrote:
>> Tim Bunce writes:
>>> I do see a need for a GRANT check and I'm adding one now (based on
>>> the code in CreateFunction() in functioncmds.c - thanks to RhodiumToad
>>> on IRC for the pointer).
>
Alvaro Herrera writes:
> Tom Lane wrote:
>> The argument for doing this now hinges solely on a marketing-driven
>> choice of version name, and not on any actual evidence that applications
>> are ready for it. We really need to do this at the start of a devel
>> and alpha test cycle, not at the en
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
>> Perl (DBD::Pg anyway) has been compatible since May 2008.
> I would interpret that to mean that there is a significant possibility
> that a too-old DBD::Pg could
Alvaro Herrera writes:
> FWIW I think there's another problem with streaming replication here,
> which is that most data flows from client to server, so it would take
> quite some time for the threshold to be reached. Note that there's no
> size check in the libpq frontend code. Normally this is
On Wed, Feb 3, 2010 at 11:28, Tom Lane wrote:
> Tim Bunce writes:
>> I do see a need for a GRANT check and I'm adding one now (based on
>> the code in CreateFunction() in functioncmds.c - thanks to RhodiumToad
>> on IRC for the pointer).
>
> What exactly are you proposing to check, and where, and
Robert Haas wrote:
> What harm is being done by the status quo? What benefit do
> we get out of changing the default?
I really think that the biggest harm is that people trying to
convert to PostgreSQL, or testing PostgreSQL with their
applications, can get bad behavior from use of standard s
Tom Lane wrote:
> The argument for doing this now hinges solely on a marketing-driven
> choice of version name, and not on any actual evidence that applications
> are ready for it. We really need to do this at the start of a devel
> and alpha test cycle, not at the end.
Application writers proba
Tom Lane escribió:
> Michael Ledford writes:
> > One might argue that the current method is already weakened as it is
> > measured by the amount of data sent instead of of a length of time. A
> > session could live a long time under the 512MB threshold depending on
> > the queries that are being p
On Wed, Feb 3, 2010 at 08:23, Heikki Linnakangas
wrote:
> Fujii Masao wrote:
>> On Thu, Jan 14, 2010 at 7:04 PM, Heikki Linnakangas
>> wrote:
>>> 1. Walsender calls pq_wait() which calls select(), waiting for timeout,
>>> or data to become available for reading in the underlying socket.
>>>
>>> 2
Tim Bunce writes:
> I do see a need for a GRANT check and I'm adding one now (based on
> the code in CreateFunction() in functioncmds.c - thanks to RhodiumToad
> on IRC for the pointer).
What exactly are you proposing to check, and where, and what do you
think that will fix?
If the concern is th
On Wed, Feb 3, 2010 at 10:56, Tim Bunce wrote:
> On Wed, Feb 03, 2010 at 10:18:51AM -0700, Alex Hunsaker wrote:
>> On Wed, Feb 3, 2010 at 09:31, Tim Bunce wrote:
>> > On Tue, Feb 02, 2010 at 08:42:21PM -0700, Alex Hunsaker wrote:
>> >> On Sat, Jan 30, 2010 at 08:49, Tim Bunce wrote:
>> >>
>> >>
On Wed, Feb 3, 2010 at 12:34 PM, Greg Sabino Mullane wrote:
> Perl (DBD::Pg anyway) has been compatible since May 2008.
I would interpret that to mean that there is a significant possibility
that a too-old DBD::Pg could get used with a new PostgreSQL, and
therefore we shouldn't change anything fo
Joe Conway writes:
> The problem exists with all three dblink_build_sql_* functions. Here is
> a more complete patch. If there are no objections I'll apply this to
> HEAD and look at back-patching -- these functions have hardly been
> touched since inception.
Do you really need to copy the relati
On 02/03/2010 04:49 AM, Rushabh Lathia wrote:
>
> create table foo (a int );
> postgres=# SELECT dblink_build_sql_insert('foo','1 2',2,'{\"0\",
> \"a\"}','{\"99\", \"xyz\"}');
> HINT: Use the escape string syntax for escapes, e.g., E'\r\n'.
> server closed the connection unexpectedly
The proble
* Tom Lane [100203 12:39]:
> "Greg Sabino Mullane" writes:
> > As one of the more vocal critics of the 8.3 implicit casting
> > incident, I say +1 on making the change. Unlike casting, it's
> > a simple GUC change to "fix", and now (9.0) is the time to
> > do it.
>
> Unfortunately, no: six month
On Wed, Feb 03, 2010 at 10:18:51AM -0700, Alex Hunsaker wrote:
> On Wed, Feb 3, 2010 at 09:31, Tim Bunce wrote:
> > On Tue, Feb 02, 2010 at 08:42:21PM -0700, Alex Hunsaker wrote:
> >> On Sat, Jan 30, 2010 at 08:49, Tim Bunce wrote:
> >>
> >> > SPI functions are not available when the code is r
"Greg Sabino Mullane" writes:
> As one of the more vocal critics of the 8.3 implicit casting
> incident, I say +1 on making the change. Unlike casting, it's
> a simple GUC change to "fix", and now (9.0) is the time to
> do it.
Unfortunately, no: six months ago was the time to do it.
The argument
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
> The main problem of enabling standard_conforming_strings is
> that applications and/or programming language DB APIs are
> not prepared to support this. I don't see a change in DB
> APIs (that I know of -- Python, Perl, and PHP) to add
> suppor
Simon Riggs writes:
> On Wed, 2010-02-03 at 11:50 -0500, Tom Lane wrote:
>> I've concluded that that's too large a change to undertake for 9.0
> The purpose of this was to make the big changes in 9.0. If we aren't
> going to do that it seems like we shouldn't bother at all.
No, the purpose of th
On Feb 3, 2010, at 9:21 AM, Alex Hunsaker wrote:
>>> plperl.on_init - run on interpreter creation
>>> plperl.on_plperl_init - run when then specialized for plperl
>>> plperl.on_plperlu_init - run when then specialized for plperlu
>>
>> Hrm, I think I agree with Tom that we
On 02/03/2010 04:49 AM, Rushabh Lathia wrote:
> Testcase:
>
> create table foo (a int );
> postgres=# SELECT dblink_build_sql_insert('foo','1 2',2,'{\"0\",
> \"a\"}','{\"99\", \"xyz\"}');
> HINT: Use the escape string syntax for escapes, e.g., E'\r\n'.
> server closed the connection unexpectedly
On Wed, Feb 3, 2010 at 10:18, Alex Hunsaker wrote:
> On Wed, Feb 3, 2010 at 09:31, Tim Bunce wrote:
>> On Tue, Feb 02, 2010 at 08:42:21PM -0700, Alex Hunsaker wrote:
>> If we're going to bikeshed the names, I'd suggest:
>>
>> plperl.on_init - run on interpreter creation
>> plperl.o
On Wed, Feb 3, 2010 at 09:31, Tim Bunce wrote:
> On Tue, Feb 02, 2010 at 08:42:21PM -0700, Alex Hunsaker wrote:
>> On Sat, Jan 30, 2010 at 08:49, Tim Bunce wrote:
>>
>> > SPI functions are not available when the code is run.
>>
>> Hrm, we might want to stick why in the docs or as a comment som
On Wed, 2010-02-03 at 11:50 -0500, Tom Lane wrote:
> I've concluded that that's too large a change to undertake for 9.0
The purpose of this was to make the big changes in 9.0. If we aren't
going to do that it seems like we shouldn't bother at all.
So why not flip back to the easier approach of m
Tom Lane wrote:
> Chris Campbell writes:
> > Is there a way to detect when the SSL library has renegotiation disabled?
>
> Probably not. The current set of emergency security patches would
> certainly not have exposed any new API that would help us tell this :-(
>
> If said patches were done pr
Tom Lane wrote:
> I've been playing around with different alternatives for solving the
> problem of toast-pointer OIDs, but I keep coming back to the above as
> being the least invasive and most robust answer. There are two basic
> ways that we could do it: pass the OID to use to the toast logic,
On Wed, Feb 3, 2010 at 11:52 AM, Michael Ledford wrote:
> On Wed, Feb 3, 2010 at 11:09 AM, Tom Lane wrote:
>> Renegotiation after X amount of data is the recommended method AFAIK,
>> because it limits the volume of data available to cryptanalysis.
>> What makes you think that elapsed time is rele
Chris Campbell writes:
> Is there a way to detect when the SSL library has renegotiation disabled?
Probably not. The current set of emergency security patches would
certainly not have exposed any new API that would help us tell this :-(
If said patches were done properly they'd have also turned
On Wed, Feb 3, 2010 at 11:09 AM, Tom Lane wrote:
>
> Renegotiation after X amount of data is the recommended method AFAIK,
> because it limits the volume of data available to cryptanalysis.
> What makes you think that elapsed time is relevant at all?
>
> regards, tom lane
Y
I wrote:
> * We can not change the toast rel OID of a shared catalog -- there's no
> way to propagate that into the other copies of pg_class. So we need to
> rejigger the logic for heap rewriting a little bit. Toast rel swapping
> has to be handled by swapping their relfilenodes not their OIDs.
On Wed, Feb 3, 2010 at 11:18 AM, Marko Tiikkaja
wrote:
>> In ExecTopLevelStmtIsReadOnly, you might perhaps want to rephase the
>> comment in a way that doesn't use the word "Ehm." Like maybe: "Even
>> if this function returns true, the statement might still contain
>> INSERT,
>> UPDATE, or DELETE
Is there a way to detect when the SSL library has renegotiation disabled?
(Either at compile-time or runtime, although runtime would definitely be better
because we’ll change our behavior if/when the user updates their SSL library.)
If so, we could skip renegotiation when it’s disabled in the li
On 2010-02-03 18:41 UTC+2, Merlin Moncure wrote:
> On Wed, Feb 3, 2010 at 11:18 AM, Marko Tiikkaja
> wrote:
>> Right. The documentation in its current state is definitely lacking.
>> I've tried to focus all the time I have in making this patch technically
>> good.
> Do you need help with the doc
2010/2/3 Oleg Bartunov :
>>> I would like to see point #2 of the following email addressed before
>>> commit. As things stand, it is not clear (at least to me) whether
>>> this is a win.
>>>
>>> http://archives.postgresql.org/pgsql-hackers/2010-01/msg02552.php
>>
>> Specifically, on this web page:
Here's an overview of where we stand with the remaining 14 patches,
according to my best understanding of the situation.
* Fix large object support in pg_dump - I haven't looked at this, but
it seems like it's relatively close to being ready for commit. We
need to get this one done as it is a rel
On Wed, 3 Feb 2010, Robert Haas wrote:
On Wed, Feb 3, 2010 at 8:48 AM, Robert Haas wrote:
2010/2/3 Teodor Sigaev :
Can you rename RED and BLACK to RBRED and RBBLACK?
Yes, of course, done.
Any objections to commit?
I would like to see point #2 of the following email addressed before
commi
On Wed, Feb 3, 2010 at 11:18 AM, Marko Tiikkaja
wrote:
> On 2010-02-03 16:53 UTC+2, Robert Haas wrote:
>> Some thoughts:
>>
>> The comments in standard_ExecutorStart() don't do a good job of
>> explaining WHY the code does what it does - they just recapitulate
>> what you can already see from read
On Tue, Feb 02, 2010 at 08:42:21PM -0700, Alex Hunsaker wrote:
> On Sat, Jan 30, 2010 at 08:49, Tim Bunce wrote:
>
> > SPI functions are not available when the code is run.
>
> Hrm, we might want to stick why in the docs or as a comment somewhere.
> I think this was the main concern?
>
> * W
On Wed, 2010-02-03 at 10:48 -0500, Tom Lane wrote:
> > If so, there is some minor code cleanup and comment changes in
> > ProcessCommittedInvalidationMessages(). Would you like me to do that, or
> > should we wait?
>
> I saw that. I didn't touch it because it's not directly relevant to
> what I'
On 2010-02-03 16:53 UTC+2, Robert Haas wrote:
> Some thoughts:
>
> The comments in standard_ExecutorStart() don't do a good job of
> explaining WHY the code does what it does - they just recapitulate
> what you can already see from reading the code. You say "If there are
> DML WITH statements, we
Robert Haas writes:
> On Wed, Feb 3, 2010 at 10:58 AM, Tom Lane wrote:
>> We could probably make that work for error messages, but what about
>> documentation? It's going to be awkward to write something like
>> "INSERT/UPDATE/DELETE RETURNING" every time we need to make a general
>> statement a
On Wed, Feb 3, 2010 at 8:48 AM, Robert Haas wrote:
> 2010/2/3 Teodor Sigaev :
>>> Can you rename RED and BLACK to RBRED and RBBLACK?
>>
>> Yes, of course, done.
>>
>> Any objections to commit?
>
> I would like to see point #2 of the following email addressed before
> commit. As things stand, it i
Michael Ledford writes:
> One might argue that the current method is already weakened as it is
> measured by the amount of data sent instead of of a length of time. A
> session could live a long time under the 512MB threshold depending on
> the queries that are being performed.
Renegotiation afte
On Wed, Feb 3, 2010 at 10:58 AM, Tom Lane wrote:
> Robert Haas writes:
>> On Wed, Feb 3, 2010 at 4:09 AM, Marko Tiikkaja
>> wrote:
>>> We have yet to reach a consensus on the name for this feature. I don't
>>> think we have any really good candidates, but I like "DML WITH" best so far.
>
>> Why
Hi,
On 2010-02-03 16:09 UTC+2, Robert Haas wrote:
> Why can't we complain about the actual SQL statement the user issued?
> Like, say:
>
> INSERT requires RETURNING when used within a referenced CTE
The SELECT equivalent of this query looks like this:
=> with recursive t as (select * from t) val
Robert Haas writes:
> On Wed, Feb 3, 2010 at 4:09 AM, Marko Tiikkaja
> wrote:
>> We have yet to reach a consensus on the name for this feature. I don't
>> think we have any really good candidates, but I like "DML WITH" best so far.
> Why can't we complain about the actual SQL statement the user
On Wed, Feb 3, 2010 at 7:00 AM, Oleg Bartunov wrote:
> On Tue, 2 Feb 2010, Robert Haas wrote:
>
>> On Sat, Jan 30, 2010 at 1:12 AM, Oleg Bartunov wrote:
>>>
>>> I made available test data I used on
>>> http://www.sai.msu.su/~megera/wiki/2009-07-27,
>>> so anyone can reproduce my results. You can
On Wed, Feb 3, 2010 at 10:21 AM, Tom Lane wrote:
>
> Bad idea: once set, it'll never get unset, thus leaving installations
> with a weakened security posture even after they've installed fixed
> versions of openssl.
>
> regards, tom lane
One might argue that the current met
Simon Riggs writes:
> On Wed, 2010-02-03 at 01:14 +, Tom Lane wrote:
>> 1. Get rid of inval.c's dependency on relfilenode, by not having it emit
>> smgr invalidations as a result of relcache flushes. Instead, smgr sinval
>> messages are sent directly from smgr.c when an actual relation delete
Robert Haas writes:
> On Wed, Feb 3, 2010 at 9:51 AM, Alex Hunsaker wrote:
>> Hey! I don't think were quite to that nasty B word yet :) I would
>> argue that treating plperl and plperlu as the same language just
>> because it shares the same code is a mistake. But I hate the idea of
>> two cust
On Wed, Feb 3, 2010 at 10:21 AM, Tom Lane wrote:
> Robert Haas writes:
>> Should we think about adding a GUC to disable renegotiation until this
>> blows over?
>
> Bad idea: once set, it'll never get unset, thus leaving installations
> with a weakened security posture even after they've installed
Robert Haas writes:
> Should we think about adding a GUC to disable renegotiation until this
> blows over?
Bad idea: once set, it'll never get unset, thus leaving installations
with a weakened security posture even after they've installed fixed
versions of openssl.
regard
2010/2/1 KaiGai Kohei :
> I again wonder whether we are on the right direction.
I believe the proposed approach is to dump blob metadata if and only
if you are also dumping blob contents, and to do all of this for data
dumps but not schema dumps. That seems about right to me.
> Originally, the r
Robert Haas wrote:
On Wed, Feb 3, 2010 at 6:24 AM, Chris Campbell wrote:
The flurry of patches that vendors have recently been making to OpenSSL to
address
the potential man-in-the-middle attack during SSL renegotiation have disabled
SSL
renegotiation altogether in the OpenSSL libraries. Appl
On Wed, Feb 3, 2010 at 6:24 AM, Chris Campbell wrote:
> The flurry of patches that vendors have recently been making to OpenSSL to
> address
> the potential man-in-the-middle attack during SSL renegotiation have disabled
> SSL
> renegotiation altogether in the OpenSSL libraries. Applications tha
Our manual mentions that you can turn off partial page writes if your
file system guarantees full page writes. We used to mention ReiserFS 4 as
an example, but I have changed that example to mention ZFS, because ZFS
is now more popular.
--
Bruce Momjian http://momjian.us
EnterpriseD
On Wed, Feb 3, 2010 at 9:51 AM, Alex Hunsaker wrote:
> Hey! I don't think were quite to that nasty B word yet :) I would
> argue that treating plperl and plperlu as the same language just
> because it shares the same code is a mistake. But I hate the idea of
> two custom_variable_classes for plp
On Wed, Feb 3, 2010 at 5:31 AM, Marko Tiikkaja
wrote:
> On 2010-02-03 11:04, Takahiro Itagaki wrote:
>> * The patch includes regression tests, but no error cases in it.
>> More test cases are needed for stupid queries.
>
> Here's an updated patch.
Some thoughts:
The comments in standard_Execut
On Wed, Feb 3, 2010 at 06:41, Andrew Dunstan wrote:
>
>
> Alex Hunsaker wrote:
>
> Well its already in.
>
Well *that's* easily fixed. I think it's a bad idea, because it's
unclear what you should put there and what the security implications
are.
>>>
>>> I can't sp
On 02/03/10 14:42, Robert Haas wrote:
On Wed, Feb 3, 2010 at 6:53 AM, Greg Stark wrote:
On Tue, Feb 2, 2010 at 7:45 PM, Robert Haas wrote:
I think you're probably right, but it's not clear what the new name
should be until we have a comment explaining what the function is
responsible for.
S
On Wed, Feb 3, 2010 at 4:09 AM, Marko Tiikkaja
wrote:
> Hi,
>
> On 2010-02-03 11:04 UTC+2, Takahiro Itagaki wrote:
>> Hi, I'm reviewing the writable CTE patch. The code logic seems to be
>> pretty good, but I have a couple of comments about error cases:
>>
>> * Did we have a consensus about user-v
1 - 100 of 123 matches
Mail list logo
