Hello PostgreSQL gurus,
(I have already posted a very similar message to comp.mail.sendmail
newsgroup on August 22nd, but I haven't received any responses there. I
have also tried pgsql-interfa...@postgresql.org but to no avail. Solving
this problem requires some Sendmail/Postfix experience becau
The attached patch implements INSERT...ON DUPLICATE KEY LOCK FOR
UPDATE. This is similar to INSERT...ON DUPLICATE KEY IGNORE (which is
also proposed at part of this new revision of the patch), but
additionally acquires a row exclusive lock on the row that prevents
insertion from proceeding in respe
On Mon, Sep 9, 2013 at 2:35 AM, Jeff Janes wrote:
> On Thu, Sep 5, 2013 at 7:00 PM, Bruce Momjian wrote:
>> On Thu, Sep 5, 2013 at 09:10:06PM -0400, Robert Haas wrote:
>>> On Thu, Sep 5, 2013 at 8:14 PM, Bruce Momjian wrote:
>>> > Actually, I now realize it is more complex than that, and worse.
On 8.9.2013 23:04, Jeff Janes wrote:
> On Tue, Sep 3, 2013 at 10:09 PM, Satoshi Nagayasu
> wrote:
>> Hi,
>>
>>
>> (2013/09/04 13:07), Alvaro Herrera wrote:
>>>
>>> Satoshi Nagayasu wrote:
>>>
As you may know, this file could be handreds of MB in size,
because pgstat.stat holds all
On Thu, Sep 5, 2013 at 7:00 PM, Bruce Momjian wrote:
> On Thu, Sep 5, 2013 at 09:10:06PM -0400, Robert Haas wrote:
>> On Thu, Sep 5, 2013 at 8:14 PM, Bruce Momjian wrote:
>> > Actually, I now realize it is more complex than that, and worse. There
>> > are several questions to study to understan
On Tue, Sep 3, 2013 at 10:09 PM, Satoshi Nagayasu wrote:
> Hi,
>
>
> (2013/09/04 13:07), Alvaro Herrera wrote:
>>
>> Satoshi Nagayasu wrote:
>>
>>> As you may know, this file could be handreds of MB in size, because
>>> pgstat.stat holds all access statistics in each database, and it needs
>>> to
Andres Freund writes:
> On 2013-09-08 20:00:58 +0200, Daniel Vérité wrote:
>> Or is there a simpler way to deal with the above case?
> One would be to use open(O_NOFOLLOW)?
That would only stop symlink attacks, not hardlink variants;
and it'd probably stop some legitimate use-cases too.
> But m
On 2013-09-08 20:00:58 +0200, Daniel Vérité wrote:
> Or is there a simpler way to deal with the above case?
One would be to use open(O_NOFOLLOW)?
But more generally I am of the opinion that it's the superusers
responsibility to make sure that cannot happen by only using properly
secured files.
G
Hi,
When a superuser creates a foreign table with file_fdw, the target file
can belong to any user, as long as postgres can read it.
This is useful when the data files are handed by non-postgres tools,
such as a spreadsheet.
In such a case, it makes sense that the superuser would additionally gr
On Sat, Sep 7, 2013 at 1:47 AM, Tom Lane wrote:
> Alexander Korotkov writes:
> > PostGIS spotted that picksplit algorithm freezes in infinite loop when
> > dealing with nan values. I discovered same bug is present in core
> > opclasses. Attached patch fixes this issue interpreting nan as value
>
10 matches
Mail list logo
