Hello,
At Fri, 21 Feb 2014 16:33:32 +0900, Etsuro Fujita wrote
> (2014/02/21 15:23), Kyotaro HORIGUCHI wrote:
> NOTICE: Child foregn table child01 is affected.
> NOTICE: Child foregn table child02 is affected
> NOTICE: Child foregn table child03 rejected 'alter tempmin set
> de
On 2014-02-21 10:08:44 +0530, Amit Kapila wrote:
> On Fri, Feb 14, 2014 at 5:35 PM, Andres Freund wrote:
> > Hi,
> >
> > In WalSndLoop() we do:
> >
> > wakeEvents = WL_LATCH_SET | WL_POSTMASTER_DEATH | WL_TIMEOUT |
> > WL_SOCKET_READABLE;
> >
> > if (pq_is_send_pending())
> >
The following snippet reveals that 9.3.1 has a bug
in regexp_matches, which uninterruptably keeps CPU
spinning for minutes:
-8<---
\timing
SET statement_timeout = 2;
-- this is only to show statement_timeout is effective here
SELECT count(*) fr
I've just tested 9.3.3 and it is _also_ affected.
Should I report the regression somewhere else ?
--strk;
On Fri, Feb 21, 2014 at 10:17:59AM +0100, Sandro Santilli wrote:
> The following snippet reveals that 9.3.1 has a bug
> in regexp_matches, which uninterruptably keeps CPU
> spinning for minu
Hello,
The SQL-MED specification defines the IMPORT FOREIGN SCHEMA statement.
This adds discoverability to foreign servers. The structure of the statement
as I understand it is simple enough:
IMPORT FOREIGN SCHEMA remote_schema FROM SERVER some_server [ (LIMIT TO |
EXCEPT) table_list ] INTO loca
On Thu, Jan 16, 2014 at 5:22 PM, Tom Lane wrote:
> but adding
> volatility here seems like probably a waste of valuable terminal width.
> I think that the vast majority of operators have immutable or at worst
> stable underlying functions, so this doesn't seem like the first bit
> of information I
On Fri, Feb 21, 2014 at 4:01 PM, Ronan Dunklau wrote:
> Hello,
>
> The SQL-MED specification defines the IMPORT FOREIGN SCHEMA statement.
>
> This adds discoverability to foreign servers. The structure of the
> statement
> as I understand it is simple enough:
>
> IMPORT FOREIGN SCHEMA remote_schem
Hi,
On 2014-02-19 13:01:02 -0500, Robert Haas wrote:
> > I think it should be fairly easy to relax the restriction to creating a
> > slot, but not getting data from it. Do you think that would that be
> > sufficient?
>
> That would be a big improvement, for sure, and might be entirely sufficient.
> I havent had a look at the patch yet since I dont have a nice editor right
> now, but how do you handle inter operability between datatypes?
> Specifically, how do you handle those datatypes which have a different name
> from the PostgreSQL name for them and/or are stored in a different manner?
On 2014-02-19 13:31:06 -0500, Robert Haas wrote:
> TBH, as compared to what you've got now, I think this mostly boils
> down to a question of quoting and escaping. I'm not really concerned
> with whether we ship something that's perfectly efficient, or that has
> filtering capabilities, or that ha
It seems to be unlikely to me, but are the changed symbols mentioned in
git-log commit message 5f173040e324 supposed to be used other than
internally? Snip:
Avoid repeated name lookups during table and index DDL.
...
to the Constraint node (FkConstraint in 8.4). Third-party code
On Fri, Feb 21, 2014 at 4:39 PM, Ronan Dunklau wrote:
> > I havent had a look at the patch yet since I dont have a nice editor
> right
> > now, but how do you handle inter operability between datatypes?
> > Specifically, how do you handle those datatypes which have a different
> name
> > from the
Hi,
On 2014-02-21 12:11:42 +0100, Pavel Raiskup wrote:
> It seems to be unlikely to me, but are the changed symbols mentioned in
> git-log commit message 5f173040e324 supposed to be used other than
> internally? Snip:
>
> These seem to be pretty internal symbols to me, but I rather askin
Le vendredi 21 février 2014 16:45:20 Atri Sharma a écrit :
> On Fri, Feb 21, 2014 at 4:39 PM, Ronan Dunklau
wrote:
> > > I havent had a look at the patch yet since I dont have a nice editor
> >
> > right
> >
> > > now, but how do you handle inter operability between datatypes?
> > > Specifically
Hi,
On 19.02.2014 08:11, Amit Kapila wrote:
> I have looked into this patch. Below are some points which I
> think should be improved in this patch:
Thank you for your review.
> 1. New context added by this patch is display at wrong place
> […]
> Do this patch expect to print the context at canc
On Fri, Feb 21, 2014 at 4:56 PM, Ronan Dunklau wrote:
> Le vendredi 21 février 2014 16:45:20 Atri Sharma a écrit :
> > On Fri, Feb 21, 2014 at 4:39 PM, Ronan Dunklau
> wrote:
> > > > I havent had a look at the patch yet since I dont have a nice editor
> > >
> > > right
> > >
> > > > now, but how d
On 2014-02-19 13:07:11 -0500, Robert Haas wrote:
> On Tue, Feb 18, 2014 at 4:07 AM, Andres Freund wrote:
> >> 2. I think the snapshot-export code is fundamentally misdesigned. As
> >> I said before, the idea that we're going to export one single snapshot
> >> at one particular point in time strik
On Feb21, 2014, at 12:09 , Ronan Dunklau wrote:
>> I havent had a look at the patch yet since I dont have a nice editor right
>> now, but how do you handle inter operability between datatypes?
>> Specifically, how do you handle those datatypes which have a different name
>> from the PostgreSQL nam
> Who says that the OIDs are the same on the local and the remove postgres
> instance? For user-defined types, that's certainly not going to be true...
That's why the the result is casted as regtype[], and parsed as such. The oid
is not transmitted over the wire, but set by regtype_in.
>
> Al
Hi,
Is there a way to store the password in ".pgpass" file in an encrypted format
(for example, to be used by pg_dump).
Even though, there are ways to set the permissions on .pgpass, to disallow any
access to world or group, the security rules of many organizations disallow to
hold any kind of
On 2014-02-21 13:40:59 +0100, Christian Kruse wrote:
> diff --git a/src/backend/utils/adt/pgstatfuncs.c
> b/src/backend/utils/adt/pgstatfuncs.c
> index a4f31cf..e65b079 100644
> --- a/src/backend/utils/adt/pgstatfuncs.c
> +++ b/src/backend/utils/adt/pgstatfuncs.c
> @@ -536,7 +536,7 @@ pg_stat_get_
On 21 February 2014 13:49, firoz e v wrote:
> Hi,
>
>
>
> Is there a way to store the password in “.pgpass” file in an encrypted
> format (for example, to be used by pg_dump).
>
>
>
> Even though, there are ways to set the permissions on .pgpass, to disallow
> any access to world or group, the s
On Fri, Feb 21, 2014 at 6:07 AM, Andres Freund wrote:
> I can sympathize with the "too much during init" argument, but I don't
> see how moving stuff to the first call would get rid of the problems. If
> we fail later it's going to be just as confusing.
No, it isn't. If you fail during init the
On 2014-02-21 08:16:59 -0500, Robert Haas wrote:
> On Fri, Feb 21, 2014 at 6:07 AM, Andres Freund wrote:
> > I can sympathize with the "too much during init" argument, but I don't
> > see how moving stuff to the first call would get rid of the problems. If
> > we fail later it's going to be just a
On Fri, Feb 21, 2014 at 2:36 PM, Andres Freund wrote:
> On 2014-02-21 10:08:44 +0530, Amit Kapila wrote:
>>
>> I think the main reason of ping is to detect n/w break sooner.
>> On a busy server, wouldn't WALSender can detect it when next time it
>> will try to send the remaining data?
>
> Well, es
On 2014-02-21 19:03:29 +0530, Amit Kapila wrote:
> On Fri, Feb 21, 2014 at 2:36 PM, Andres Freund wrote:
> > On 2014-02-21 10:08:44 +0530, Amit Kapila wrote:
> >>
> >> I think the main reason of ping is to detect n/w break sooner.
> >> On a busy server, wouldn't WALSender can detect it when next t
On Thu, Feb 20, 2014 at 12:07 PM, Alvaro Herrera
wrote:
> I think "bulk" (maintenance) operations should legitimately configured
> separately from regular UPDATE etc operations. For the latter I think
> it's pretty reasonable to assume that users are going to want to tweak
> the GUC for each indi
On Fri, Feb 21, 2014 at 8:27 AM, Andres Freund wrote:
> On 2014-02-21 08:16:59 -0500, Robert Haas wrote:
>> On Fri, Feb 21, 2014 at 6:07 AM, Andres Freund
>> wrote:
>> > I can sympathize with the "too much during init" argument, but I don't
>> > see how moving stuff to the first call would get r
It's clear now that if what Greg wants is an uncontroversial patch to
commit, this is not it.
--
Álvaro Herrerahttp://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make cha
On 2014-02-21 08:51:03 -0500, Robert Haas wrote:
> On Fri, Feb 21, 2014 at 8:27 AM, Andres Freund wrote:
> > On 2014-02-21 08:16:59 -0500, Robert Haas wrote:
> >> On Fri, Feb 21, 2014 at 6:07 AM, Andres Freund
> >> wrote:
> >> > I can sympathize with the "too much during init" argument, but I do
Hello,
There is a callback function in fdw's which should also set estimates for
startup and total costs for each path. Assume a fdw adds only one path
(e.g. in file_fdw). I am trying to understand what can go wrong if we do a
bad job in estimating these costs.
Since we have only one scan path he
firoz e v wrote:
> Hi,
>
> Is there a way to store the password in ".pgpass" file in an encrypted format
> (for example, to be used by pg_dump).
>
> Even though, there are ways to set the permissions on .pgpass, to disallow
> any access to world or group, the security rules of many organization
Hi,
On 21/02/14 11:15, Alvaro Herrera wrote:
> Maybe you can memfrob() the password to encrypt it before writing, and
> then memfrob() it back before applying it. Would that be secure?
From `man memfrob`:
Note that this function is not a proper encryption routine as the XOR
constant is fixed,
On 21-02-2014 09:49, firoz e v wrote:
> Even though, there are ways to set the permissions on .pgpass, to disallow
> any access to world or group, the security rules of many organizations
> disallow to hold any kind of passwords, as plain text.
>
Is your goal hiding the password in .pgpass? You
Hadi Moshayedi writes:
> There is a callback function in fdw's which should also set estimates for
> startup and total costs for each path. Assume a fdw adds only one path
> (e.g. in file_fdw). I am trying to understand what can go wrong if we do a
> bad job in estimating these costs.
> Since we
Euler Taveira wrote:
> On 21-02-2014 09:49, firoz e v wrote:
> > Even though, there are ways to set the permissions on .pgpass, to disallow
> > any access to world or group, the security rules of many organizations
> > disallow to hold any kind of passwords, as plain text.
> >
> Is your goal hid
On 2014-02-21 12:04:47 -0300, Alvaro Herrera wrote:
> You could instead try to have an authentication agent that stores an
> encrypted password or certificate and asks the user to supply the key to
> decrypt it when trying to establish a connection; but that would force
> you to require user interv
On 02/21/2014 05:17 PM, Sandro Santilli wrote:
> The following snippet reveals that 9.3.1 has a bug
> in regexp_matches, which uninterruptably keeps CPU
> spinning for minutes:
Huh. So it does. That's interesting.
(You should generally report things to pgsql-b...@postgresql.org btw,
not -hackers
On Fri, Feb 21, 2014 at 7:49 AM, firoz e v wrote:
> Hi,
>
>
>
> Is there a way to store the password in ".pgpass" file in an encrypted
> format (for example, to be used by pg_dump).
>
>
>
> Even though, there are ways to set the permissions on .pgpass, to disallow
> any access to world or group,
I'm writing a pgsql extension in C, which is multithreaded. The SPI
connection is global, so do I have to implement a lock to make sql queries
in each thread, or can I make a connection on a per-thread basis?
On Feb21, 2014, at 16:46 , Craig Ringer wrote:
> The real question IMO is why it's taking so long. It looks like
> cfindloop(...) is being called multiple times, with each call taking a
> couple of seconds.
Yeah, I wondered about this too. I've shortened the example a bit - here
are a few observa
On Fri, Feb 21, 2014 at 7:04 AM, Alvaro Herrera wrote:
> Euler Taveira wrote:
> > On 21-02-2014 09:49, firoz e v wrote:
> > > Even though, there are ways to set the permissions on .pgpass, to
> disallow any access to world or group, the security rules of many
> organizations disallow to hold any k
On Feb21, 2014, at 13:44 , John Williams wrote:
> I'm writing a pgsql extension in C, which is multithreaded. The SPI
> connection is global, so do I have to implement a lock to make sql
> queries in each thread, or can I make a connection on a per-thread basis?
Postgres backends aren't multi-thr
Jeff Janes escribió:
> On Fri, Feb 21, 2014 at 7:04 AM, Alvaro Herrera
> wrote:
> > If you were to have a mechanism by which
> > libpq can store an md5'd password (or whatever hash) and send that md5
> > to the server and have the server accept it to grant a connection, then
> > the md5 has, in
Michael,
* Michael Paquier (michael.paqu...@gmail.com) wrote:
> While compiling on clang, I noticed the following warning:
> pg_backup_archiver.c:1950:32: warning: comparison of constant -1 with
> expression of type 'ArchiveFormat' (aka 'enum _archiveFormat') is always
> false
> [-Wtautologi
On 02/22/2014 12:04 AM, Florian Pflug wrote:
> On Feb21, 2014, at 16:46 , Craig Ringer wrote:
>> The real question IMO is why it's taking so long. It looks like
>> cfindloop(...) is being called multiple times, with each call taking a
>> couple of seconds.
>
> Yeah, I wondered about this too. I'v
On 02/22/2014 12:20 AM, Alvaro Herrera wrote:
> Jeff Janes escribió:
>> On Fri, Feb 21, 2014 at 7:04 AM, Alvaro Herrera
>> wrote:
>
>>> If you were to have a mechanism by which
>>> libpq can store an md5'd password (or whatever hash) and send that md5
>>> to the server and have the server accept
On 02/21/2014 11:52 PM, Christopher Browne wrote:
>
> The thing you could do instead that would *look* like it is encrypted is
> to use a certificate (e.g. - SSL). The certificate that you'd need to
> put on the client still needs to be in something that is effectively
> plain text (however much
On Feb21, 2014, at 17:29 , Craig Ringer wrote:
> The problem report claims that the issue does not occur on 9.1, but yet:
>
> git diff REL9_1_STABLE master -- ./src/backend/utils/adt/regexp.c
>
> is utterly trivial; a copyright date line change, and 1609797c which
> just tweaks the includes. 9.
Craig Ringer writes:
> So I'd like to confirm that this issue doesn't affect 9.1.
It doesn't. I suspect it has something to do with 173e29aa5 or one
of the nearby commits in backend/regex/.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgr
Hi,
On 21 Únor 2014, 16:52, Christopher Browne wrote:
> On Fri, Feb 21, 2014 at 7:49 AM, firoz e v wrote:
>
>> Hi,
>>
>>
>>
>> Is there a way to store the password in ".pgpass" file in an encrypted
>> format (for example, to be used by pg_dump).
>>
>>
>>
>> Even though, there are ways to set the
On Fri, Feb 21, 2014 at 8:42 AM, Craig Ringer wrote:
> On 02/22/2014 12:20 AM, Alvaro Herrera wrote:
> > Jeff Janes escribió:
> >> On Fri, Feb 21, 2014 at 7:04 AM, Alvaro Herrera <
> alvhe...@2ndquadrant.com>wrote:
> >
> >>> If you were to have a mechanism by which
> >>> libpq can store an md5'd
I think this thread deserves more attention:
http://www.postgresql.org/message-id/caazkufajufddfp1_vghbdfyru0sj6msovvkrp87acq53ov6...@mail.gmail.com
--
Álvaro Herrerahttp://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
--
Sent via pgsql-hackers
On 1/16/14, 9:19 PM, Craig Ringer wrote:
On 01/16/2014 11:52 PM, Tom Lane wrote:
Heikki Linnakangas writes:
On 01/16/2014 05:39 PM, Andres Freund wrote:
Do you see a reasonable way to implement this generically for all
commands? I don't.
In suitable safe places, check if you've written too
On 2/17/14, 7:31 PM, Robert Haas wrote:
But do you really want to keep that snapshot around long enough to
copy the entire database? I bet you don't: if the database is big,
holding back xmin for long enough to copy the whole thing isn't likely
to be fun.
I can confirm that this would be epic
On Fri, Feb 21, 2014 at 10:42 AM, Alvaro Herrera
wrote:
> I think this thread deserves more attention:
>
> http://www.postgresql.org/message-id/caazkufajufddfp1_vghbdfyru0sj6msovvkrp87acq53ov6...@mail.gmail.com
(I wrote that mail)
I'm still in interested in this idea and haven't found a good rea
Noah Misch writes:
> On Wed, Feb 19, 2014 at 08:22:13PM -0500, Tom Lane wrote:
>> How much of this is back-patch material, do you think?
> None of it. While many of the failures to validate against a character
> encoding are clear bugs, applications hum along in spite of such bugs and
> break wh
On 02/21/2014 09:11 AM, Tomas Vondra wrote:
> What I think might be useful and safe at the same time is encrypted
> .pgpass with tools asking for the encryption key. Think of it as a simple
> passord wallet - not really useful if you're connecting to a single
> database, very useful if you have man
On Fri, Feb 21, 2014 at 05:20:06PM -0500, Tom Lane wrote:
> Noah Misch writes:
> > On Wed, Feb 19, 2014 at 08:22:13PM -0500, Tom Lane wrote:
> >> How much of this is back-patch material, do you think?
>
> > None of it. While many of the failures to validate against a character
> > encoding are c
On 22.2.2014 00:02, Josh Berkus wrote:
> On 02/21/2014 09:11 AM, Tomas Vondra wrote:
>> What I think might be useful and safe at the same time is encrypted
>> .pgpass with tools asking for the encryption key. Think of it as a simple
>> passord wallet - not really useful if you're connecting to a si
Hi,
I've noticed that files for dropped databases aren't removed from
pg_stat_tmp. After a cluster-wide VACUUM ANALYSE, and restarting Postgres,
all the old database pg_stat_tmp files remain.
Shouldn't these be cleaned up?
--
Thom
Hi Rajeev,
From: "Rajeev rastogi"
Changed the patch as per your suggestion.
Now only one version of make_absolute_path there defined in src/port/path.c
Found one small memory leak in the existing function
make_absolute_path(miscinit.c),
fixed the same.
Thanks for refactoring. I confirmed t
Hi,
On 22.2.2014 01:13, Thom Brown wrote:
> Hi,
>
> I've noticed that files for dropped databases aren't removed from
> pg_stat_tmp. After a cluster-wide VACUUM ANALYSE, and restarting
> Postgres, all the old database pg_stat_tmp files remain.
>
> Shouldn't these be cleaned up?
Yeah, that's a
I wrote:
> Craig Ringer writes:
>> So I'd like to confirm that this issue doesn't affect 9.1.
> It doesn't. I suspect it has something to do with 173e29aa5 or one
> of the nearby commits in backend/regex/.
Indeed, git bisect fingers that commit as introducing the problem.
What seems to be happ
On 22 February 2014 01:07, Tomas Vondra wrote:
> Hi,
>
> On 22.2.2014 01:13, Thom Brown wrote:
> > Hi,
> >
> > I've noticed that files for dropped databases aren't removed from
> > pg_stat_tmp. After a cluster-wide VACUUM ANALYSE, and restarting
> > Postgres, all the old database pg_stat_tmp fil
On Fri, Feb 21, 2014 at 10:18 PM, Daniel Farina wrote:
> I'm still in interested in this idea and haven't found a good reason
> to rescind the general thinking there.
It's an interesting idea. I wonder if it would be possible to make it
compatible with existing tools like ssh-agent instead of inv
On 02/21/2014 03:54 PM, Tomas Vondra wrote:
> Depends on how you define external utility. It certainly needs to be
> somehow integrated with the tools using .pgpass. Do you have something
> particular in mind?
Yeah, I was thinking that the ideal would to be to make this generically
pluggable, like
On Fri, Feb 21, 2014 at 6:15 PM, Greg Stark wrote:
> On Fri, Feb 21, 2014 at 10:18 PM, Daniel Farina wrote:
>> I'm still in interested in this idea and haven't found a good reason
>> to rescind the general thinking there.
>
> It's an interesting idea. I wonder if it would be possible to make it
>
On Fri, Feb 21, 2014 at 7:10 PM, Andres Freund wrote:
> On 2014-02-21 19:03:29 +0530, Amit Kapila wrote:
>> On Fri, Feb 21, 2014 at 2:36 PM, Andres Freund
>> wrote:
>> > Well, especially on a pipelined connection, that can take a fair
>> > bit. TCP timeouts aren't fun.
>>
>> Okay, but the behavi
From: "Magnus Hagander"
Does somebody want to look at backpatching this to 9.1 and earlier, or
should we just say that it's not fully supported on those Windows versions
unless you apply the registry workaround?
Please use the attached patch. It applies cleanly to both 9.1 and 9.0.
We don't
On Fri, Feb 21, 2014 at 4:55 PM, Christian Kruse
wrote:
> Hi,
>> 1. New context added by this patch is display at wrong place
>> [...]
>> Do this patch expect to print the context at cancel request
>> as well?
>
> To be honest, I don't see a problem here. If you cancel the request in
> most cases
71 matches
Mail list logo
