Attached herewith is a patch based on description in my previous mail.
This patch would need revision since the error situation in case of
authentication timeout on the server needs to be handled; probably in
simple_prompt()?
--
Amit Langote
--
Sent via pgsql-hackers mailing list (pgsql-hacker
Hello,
> > >> Is the point of this discussion that the patch may leave out some
> > >> glich about timing of timeline-related changing and Heikki saw an
> > >> egress of that?
> > >
> > > AFAIU, the committed patch has some gap in overall scenario which is
> > the
> > > fast promotion issue.
> >
On Wed, May 15, 2013 at 3:08 PM, Daniel Farina wrote:
> On Mon, May 13, 2013 at 5:50 AM, Heikki Linnakangas
> wrote:
>> pgbench -S is such a workload. With 9.3beta1, I'm seeing this profile, when
>> I run "pgbench -S -c64 -j64 -T60 -M prepared" on a 32-core Linux machine:
>>
>> - 64.09% postgre
Sorry that I am writing separate emails on the same topic.
I seem to have a solution that allows us to accomplish what we are
trying to without much change to the existing libpq interface
(especially what to expect about return values and connection state
that we are in when we return from connectD
Re: Tom Lane 2013-05-15 <244.1368675...@sss.pgh.pa.us>
> You sure that wholesale override of CFLAGS is a good idea?
> This report doesn't show what flags the rest of your system was built
> with, but seems like there could be a compatibility issue. Or maybe
> you prevented plperl from being built
2013-05-15 20:05 keltezéssel, Andrew Dunstan írta:
On 05/15/2013 02:00 PM, Josh Berkus wrote:
Obviously we need a meta-manager who makes sure we have managers, and is
able to notice that a manager is MIA and needs replaced (or at least
backed-up).
And then a meta-meta-manager to make sure that
>>> I created a patch which enables it to use the existing connection in
>>> such a case (unlike what we currently do). It modifies
>>> connectDBComplete() and PQconnectPoll() to also include states
>>> pertaining to password being accepted from the user. That is, the
>>> state machine in PQconnect
On Wed, May 15, 2013 at 10:17 PM, Alvaro Herrera
wrote:
> Jon Nelson escribió:
>> On Wed, May 15, 2013 at 4:46 PM, Jon Nelson
>> wrote:
>
>> > That's true. I originally wrote the patch using fallocate(2). What
>> > would be appropriate here? Should I switch on the return value and the
>> > six (
Christoph Berg writes:
> Here's what I did:
> ./configure
> cd src && make
> cd pl/plperl && make clean && make CFLAGS="-g"
> make check
You sure that wholesale override of CFLAGS is a good idea?
This report doesn't show what flags the rest of your system was built
with, but seems like there cou
Jon Nelson escribió:
> On Wed, May 15, 2013 at 4:46 PM, Jon Nelson wrote:
> > That's true. I originally wrote the patch using fallocate(2). What
> > would be appropriate here? Should I switch on the return value and the
> > six (6) or so relevant error codes?
>
> I addressed this, hopefully in a
On Wed, May 15, 2013 at 4:46 PM, Jon Nelson wrote:
> On Wed, May 15, 2013 at 4:34 PM, Andres Freund wrote:
..
>> Some where quick comments, without thinking about this:
>
> Thank you for the kind feedback.
>
>> * needs a configure check for posix_fallocate. The current version will
>> e.g. fail
On 2013-05-15 18:35:35 +0300, Heikki Linnakangas wrote:
> Truncating a heap at the end of vacuum, to release unused space back to
> the OS, currently requires taking an AccessExclusiveLock. Although it's only
> held for a short duration, it can be enough to cause a hiccup in query
> processing whil
All,
Starting a new thread to avoid hijacking Heikki's original, but..
* Heikki Linnakangas (hlinnakan...@vmware.com) wrote:
> Truncating a heap at the end of vacuum, to release unused space back to
> the OS, currently requires taking an AccessExclusiveLock. Although
> it's only held for a shor
Basically I was referring to this link http://mbk.projects.postgresql.org
Any suggestions here?
Thanks!
Robert Haas writes:
> I've been thinking for a while that we need some other system for
> managing other kinds of invalidations. For example, suppose we want
> to cache relation sizes in blocks. So we allocate 4kB of shared
> memory, interpreted as an array of 512 8-byte entries. Whenever you
>
> Please do not top-post on the PostgreSQL lists. See <
http://idallen.com/topposting.html>
> Also, note that pgsql-hackers is entirely the wrong list for this sort of
question. You should have been asking on pgsql-general.
Apologies for top-post!
Well I thought pgsql-hackers will suggest some new
On Wed, May 15, 2013 at 7:10 PM, Tom Lane wrote:
>> Another problem is that sinval resets are bad for performance, and
>> anything we do that pushes more messages through sinval will increase
>> the frequency of resets.
>
> I've been thinking that we should increase the size of the sinval ring;
>
Robert Haas writes:
> On Wed, May 15, 2013 at 11:35 AM, Heikki Linnakangas
> wrote:
>> To not slow down common backend
>> operations, the values (or lack thereof) are cached in relcache. To sync the
>> relcache when the values change, there will be a new shared cache
>> invalidation event to forc
> In any case, that restriction isn't breaking pg_dump so I don't feel
> a need to change it during beta.
Sure. Maybe put it on the stack for 9.4.
--
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make chang
On 05/15/2013 02:22 PM, Dev Kumkar wrote:
> Well ya, stored procedure also was thinking about pre-insert trigger.
>
> Am sure folks here must have gone thru this and had alternatives. Also was
> reading about merge_by_key.
It's been on the TODO list forever. It's harder to implement well than
yo
Josh Berkus writes:
>> Comments?
> I personally think that FOREIGN should be optional on most commands
> where ambiguity is unlikely. In addition to ALTER, there's no
> particularly good reason why "DROP TABLE myforeigntable" doesn't work.
Well, it's certainly bizarre that we allow ALTER TABLE
On Wed, May 15, 2013 at 3:46 AM, Robert Haas wrote:
> One possible objection to this line of attack is that, IIUC, waits to
> acquire a LWLock are non-interruptible. If someone tells PostgreSQL
> to wait for some period of time before performing each WAL write,
> other backends that grab the WALW
On Mon, May 13, 2013 at 5:50 AM, Heikki Linnakangas
wrote:
> pgbench -S is such a workload. With 9.3beta1, I'm seeing this profile, when
> I run "pgbench -S -c64 -j64 -T60 -M prepared" on a 32-core Linux machine:
>
> - 64.09% postgres postgres [.] tas
>- tas
> - 99.83% s_loc
On Wed, May 15, 2013 at 4:34 PM, Andres Freund wrote:
> Hi,
>
> On 2013-05-15 16:26:15 -0500, Jon Nelson wrote:
>> >> I have written up a patch to use posix_fallocate in new WAL file
>> >> creation, including configuration by way of a GUC variable, but I've
>> >> not contributed to the PostgreSQL
Hi,
On 2013-05-15 16:26:15 -0500, Jon Nelson wrote:
> >> I have written up a patch to use posix_fallocate in new WAL file
> >> creation, including configuration by way of a GUC variable, but I've
> >> not contributed to the PostgreSQL project before. Therefore, I'm
> >> fairly certain the patch is
On Tue, May 14, 2013 at 9:43 PM, Robert Haas wrote:
> On Mon, May 13, 2013 at 9:54 PM, Jon Nelson wrote:
>> Pertinent to another thread titled
>> [HACKERS] corrupt pages detected by enabling checksums
>> I hope to explore the possibility of using fallocate (or
>> posix_fallocate) for new WAL file
Well ya, stored procedure also was thinking about pre-insert trigger.
Am sure folks here must have gone thru this and had alternatives. Also was
reading about merge_by_key.
On Wed, May 15, 2013 at 12:51 PM, Daniel Farina wrote:
> On Wed, May 15, 2013 at 11:44 AM, Dev Kumkar
> wrote:
> > Hello,
On Wed, May 15, 2013 at 11:35 AM, Heikki Linnakangas
wrote:
> Shared memory space is limited, but we only need the watermarks for any
> in-progress truncations. Let's keep them in shared memory, in a small
> fixed-size array. That limits the number of concurrent truncations that can
> be in-progre
Tom,
> Comments?
I personally think that FOREIGN should be optional on most commands
where ambiguity is unlikely. In addition to ALTER, there's no
particularly good reason why "DROP TABLE myforeigntable" doesn't work.
--
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com
--
Sent via p
While fooling with the issue of serial columns for foreign tables,
I noticed that pg_dump will sometimes try to restore a default
expression with a command like this:
ALTER TABLE ONLY rem ALTER COLUMN f1 SET DEFAULT
nextval('rem_f1_seq'::regclass);
which when applied to a foreign table gets you
On Wed, May 15, 2013 at 3:04 PM, Noah Misch wrote:
> On Tue, May 14, 2013 at 12:15:24PM -0300, Claudio Freire wrote:
>> You know what would be a low-hanging fruit that I've been thinking
>> would benefit many of my own queries?
>>
>> "Parallel" sequential scan nodes. Even if there's no real parall
On 15.05.2013 22:50, Benedikt Grundmann wrote:
On Wed, May 15, 2013 at 2:50 PM, Heikki Linnakangas
The subject says 9.2.3. Are you sure you're running 9.2.4 on all the
servers? There was a fix to a bug related to starting a standby server from
a filesystem snapshot. I don't think it was quite the
On Wed, May 15, 2013 at 2:50 PM, Heikki Linnakangas wrote:
> On 15.05.2013 15:42, David Powers wrote:
>
>> First, thanks for the replies. This sort of thing is frustrating and hard
>> to diagnose at a distance, and any help is appreciated.
>>
>> Here is some more background:
>>
>> We have 3 9.2.
On Wed, May 15, 2013 at 11:44 AM, Dev Kumkar wrote:
> Hello,
>
> Is there an alternative of Sybase "on existing update" construct in pgsql.
>
> "ON DUPLICATE KEY UPDATE" doesn't work.
>
> Thanks in advance!
No, you'll have to either handle this in the application or use a
stored procedure at this
Kevin,
It's fairly common for matviews to be constructed such that updates to
them are strictly appends. For example, a matview which has a daily
summary would just get appended to each day, and existing rows would not
change barring a major historical database cleanup.
It seems like we could ..
On Wed, May 15, 2013 at 11:32 AM, Peter Geoghegan wrote:
> I think that this effort could justify itself independently of any
> attempt to introduce parallelism to in-memory sorting. I abandoned a
> patch to introduce timsort to Postgres, because I knew that there was
> no principled way to reap t
On 15.05.2013 15:42, David Powers wrote:
First, thanks for the replies. This sort of thing is frustrating and hard
to diagnose at a distance, and any help is appreciated.
Here is some more background:
We have 3 9.2.4 databases using the following setup:
The subject says 9.2.3. Are you sure y
On 2013-05-13 10:28:59 -0400, Noah Misch wrote:
> Each worker needs to make SnapshotNow visibility decisions coherent with the
> master. For sorting, this allows us to look up comparison functions, even
> when the current transaction created or modified those functions. This will
> also be an ess
Hello,
Is there an alternative of Sybase "on existing update" construct in pgsql.
"ON DUPLICATE KEY UPDATE" doesn't work.
Thanks in advance!
Regards - Dev
On 05/15/2013 11:05 AM, Andrew Dunstan wrote:
>
> On 05/15/2013 02:00 PM, Josh Berkus wrote:
>>> Obviously we need a meta-manager who makes sure we have managers, and is
>>> able to notice that a manager is MIA and needs replaced (or at least
>>> backed-up).
Actuall, on a more serious basis, we c
Le mercredi 15 mai 2013 16:43:17, Andrew Dunstan a écrit :
> On 05/15/2013 10:05 AM, Tom Lane wrote:
> > Peter Eisentraut writes:
> >> That said, I'm obviously outnumbered here. What about the following
> >> compromise: Use the configure-selected install program inside
> >> PostgreSQL (which we
On Mon, May 13, 2013 at 7:28 AM, Noah Misch wrote:
> We should decide whether to actually sort in parallel based on the comparator
> cost and the data size. The system currently has no information on comparator
> cost: bt*cmp (and indeed almost all built-in functions) all have procost=1,
> but bt
Merlin Moncure wrote:
> Kevin Grittner wrote:
>> Merlin Moncure wrote:
>>
>>> #1 issue I have with current matview functionality is locking.
>>> currently refresh takes out an access exclusive lock. so,
>>> question is, do you think your proposal will be such that it
>>> will no longer require
On Wed, May 15, 2013 at 12:26:52PM +0530, Amit Kapila wrote:
> On Monday, May 13, 2013 7:59 PM Noah Misch wrote:
> > We can allocate a small amount of permanent shared memory for
> > coordination
> > among a group of processes, but sorting will benefit from a region as
> > large as
> > maintenance_
On Wed, May 15, 2013 at 08:12:34AM +0900, Michael Paquier wrote:
> The concept of clause parallelism for backend worker is close to the
> concept of clause shippability introduced in Postgres-XC. In the case of
> XC, the equivalent of the master backend is a backend located on a node
> called Coord
On 05/15/2013 02:00 PM, Josh Berkus wrote:
Obviously we need a meta-manager who makes sure we have managers, and is
able to notice that a manager is MIA and needs replaced (or at least
backed-up).
And then a meta-meta-manager to make sure that the meta-manager is
meta-managing.
And an Inspecto
On Tue, May 14, 2013 at 12:15:24PM -0300, Claudio Freire wrote:
> You know what would be a low-hanging fruit that I've been thinking
> would benefit many of my own queries?
>
> "Parallel" sequential scan nodes. Even if there's no real parallelism
> involved, when a query has to scan the same table
> Obviously we need a meta-manager who makes sure we have managers, and is
> able to notice that a manager is MIA and needs replaced (or at least
> backed-up).
And then a meta-meta-manager to make sure that the meta-manager is
meta-managing.
And an Inspector General. Anyone have Danny Kaye's ph
Josh Berkus wrote:
> On 05/15/2013 10:30 AM, Alvaro Herrera wrote:
> > Uhm. If I've been anything wrt the 9.3 schedule, happy is not it. We
> > completely failed to manage it in any kind of sane way. I vote +1 for
> > keeping the same commitfest schedule this year, but please let's do
> > everyo
First, thanks for the replies. This sort of thing is frustrating and hard
to diagnose at a distance, and any help is appreciated.
Here is some more background:
We have 3 9.2.4 databases using the following setup:
- A primary box
- A standby box running as a hot streaming replica from the primar
On 05/15/2013 10:30 AM, Alvaro Herrera wrote:
> Uhm. If I've been anything wrt the 9.3 schedule, happy is not it. We
> completely failed to manage it in any kind of sane way. I vote +1 for
> keeping the same commitfest schedule this year, but please let's do
> everyone a favor and make sure we g
Heikki Linnakangas wrote:
> On 14.05.2013 05:34, Peter Eisentraut wrote:
> >In the last two years, the first commit fest started in June, which is
> >about a month from now. If we are going to do that again, we should
> >clarify that as soon as possible. And if we are not, then we should
> >also
On Wed, May 15, 2013 at 11:33 AM, Kevin Grittner wrote:
> Merlin Moncure wrote:
>
>> #1 issue I have with current matview functionality is locking.
>> currently refresh takes out an access exclusive lock. so,
>> question is, do you think your proposal will be such that it will
>> no longer requi
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Il 14/05/2013 20:24, Josh Berkus ha scritto:
> Hackers,
>
> I'd like to add the following todo items to the TODO list:
>
> PL/Python:
> * add support for anyelement and anyarray to PL/Python
> * add support for VARIADIC "ANY" to PL/Python
>
> PL/Per
Merlin Moncure wrote:
> #1 issue I have with current matview functionality is locking.
> currently refresh takes out an access exclusive lock. so,
> question is, do you think your proposal will be such that it will
> no longer require taking out full lock for refresh purposes
> (either increment
On Tue, May 14, 2013 at 2:52 PM, Kevin Grittner wrote:
> In surveying the literature on $subject, I find that most of the
> theoretical work related to how to incrementally update
> materialized views based on the matview declaration was published
> between 1988 and 1993. The best paper I have be
On Wed, May 15, 2013 at 09:51:15AM -0400, Peter Eisentraut wrote:
> On 5/14/13 10:38 AM, Cédric Villemain wrote:
> > If I follow your example, then I would rewrite http://manager.pgxn.org/howto
>
> Oh that's where that is coming from? Well that example has all kinds of
> problems.
Would you be s
On Wed, May 15, 2013 at 11:04 PM, Kyotaro HORIGUCHI
wrote:
>> Is it right that it is only in the case a password prompt is needed
>> that a new connection is created after dropping the just-failed
>> connection?
>
> It's quite doubtful.\:-p The sequense seems fragile to say the
> least. Inserting
Truncating a heap at the end of vacuum, to release unused space back to
the OS, currently requires taking an AccessExclusiveLock. Although it's
only held for a short duration, it can be enough to cause a hiccup in
query processing while it's held. Also, if there is a continuous stream
of querie
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> The generic issue there is whether we can allow column defaults to be
> evaluated on the remote end. The original postgres_fdw submission tried
> to support that, but it had enough bugs and logical inconsistencies that
> I ended up ripping that out before c
Stephen Frost writes:
> I'm alright with allowing it and making it the 'default', but I can
> certainly see use-cases for having a sequence on the remote side which
> is used for new values for that table and I'd suggest that we figure out
> a way to support that.
The generic issue there is wheth
* Andrew Dunstan (and...@dunslane.net) wrote:
> On 05/15/2013 10:27 AM, Tom Lane wrote:
> >You can certainly argue that it might be silly to have a local sequence
> >generating the default value for insertions into a remote table; but
> >on the other hand, it might not be silly, depending on usage
On 05/15/2013 10:05 AM, Tom Lane wrote:
Peter Eisentraut writes:
That said, I'm obviously outnumbered here. What about the following
compromise: Use the configure-selected install program inside
PostgreSQL (which we can test easily), and use install-sh under
USE_PGXS? Admittedly, the make i
On 05/15/2013 10:27 AM, Tom Lane wrote:
You can certainly argue that it might be silly to have a local sequence
generating the default value for insertions into a remote table; but
on the other hand, it might not be silly, depending on usage scenario.
I don't think the database should be enforci
Albe Laurenz writes:
> Tom Lane wrote:
>> "Nicholson, Brad (Toronto, ON, CA)" writes:
>>> [ this error message sucks: ]
>>> test=# create foreign table local_foo (id serial) server test_server
>>> options (table_name 'foo');
>>> ERROR: referenced relation "local_foo" is not a table
>> Yeah, I'
Tom Lane wrote:
> "Nicholson, Brad (Toronto, ON, CA)" writes:
>> [ this error message sucks: ]
>> test=# create foreign table local_foo (id serial) server test_server options
>> (table_name 'foo');
>> ERROR: referenced relation "local_foo" is not a table
>
> Yeah, I'd noticed that myself. We c
Le mardi 14 mai 2013 15:08:42, Andrew Dunstan a écrit :
> On 05/14/2013 07:59 AM, Peter Eisentraut wrote:
> > On 5/14/13 4:17 AM, Marti Raudsepp wrote:
> >> On Tue, May 14, 2013 at 5:27 AM, Peter Eisentraut
wrote:
> >>> On Tue, 2013-05-14 at 04:12 +0300, Marti Raudsepp wrote:
> It's caused b
Peter Eisentraut writes:
> That said, I'm obviously outnumbered here. What about the following
> compromise: Use the configure-selected install program inside
> PostgreSQL (which we can test easily), and use install-sh under
> USE_PGXS? Admittedly, the make install time of extensions is probabl
> Is it right that it is only in the case a password prompt is needed
> that a new connection is created after dropping the just-failed
> connection?
It's quite doubtful.\:-p The sequense seems fragile to say the
least. Inserting password request state into the client-side state
machine looks quit
On 5/14/13 10:38 AM, Cédric Villemain wrote:
> If I follow your example, then I would rewrite http://manager.pgxn.org/howto
Oh that's where that is coming from? Well that example has all kinds of
problems.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes t
On 5/14/13 5:45 PM, Tom Lane wrote:
> We changed to using install-sh unconditionally back in 2001 because
> we had too many problems with system-provided scripts that didn't do
> what we expected. I see very little reason to believe that the
> compatibility problems have disappeared since then, an
Sent from my iPad
On 15-May-2013, at 18:56, Tom Lane wrote:
> "Nicholson, Brad (Toronto, ON, CA)" writes:
>> [ this error message sucks: ]
>> test=# create foreign table local_foo (id serial) server test_server options
>> (table_name 'foo');
"Nicholson, Brad (Toronto, ON, CA)" writes:
> [ this error message sucks: ]
> test=# create foreign table local_foo (id serial) server test_server options
> (table_name 'foo');
> ERROR: referenced relation "local_foo" is not a table
Yea
On Tue, May 14, 2013 at 10:30 PM, Stephen Frost wrote:
> * Tom Lane (t...@sss.pgh.pa.us) wrote:
>> I still think we should revert 9db7ccae2000524b72a4052352cbb5407fb53b02.
>> The argument that the system-provided program might be faster carries
>> very little weight for me --- "make install" is fa
> Please add patches here so they don't get forgotten:
>
> https://commitfest.postgresql.org/action/commitfest_view/open
>
> Do we really need to add *2* new libpq functions just to support this?
I will add the patches to commitfest after reviewing it a bit to see
if we can do away without having
Hi,
I'm kicking the tires on the 9.3 postgres_fdw stuff - I'm not sure if this is
an issue or intended behavior, but it was pretty confusing based on the error
message that was output. If you try creating a foreign table with a reference
to a serial data type, it comes back with a "referenced
+1
2013/5/15 Robert Haas :
> On Tue, May 14, 2013 at 2:24 PM, Josh Berkus wrote:
>> Hackers,
>>
>> I'd like to add the following todo items to the TODO list:
>>
>> PL/Python:
>> * add support for anyelement and anyarray to PL/Python
>> * add support for VARIADIC "ANY" to PL/Python
>>
>> PL/Perl:
On Tue, May 14, 2013 at 2:24 PM, Josh Berkus wrote:
> Hackers,
>
> I'd like to add the following todo items to the TODO list:
>
> PL/Python:
> * add support for anyelement and anyarray to PL/Python
> * add support for VARIADIC "ANY" to PL/Python
>
> PL/Perl:
> * add support for anyelement and anya
On Tue, May 14, 2013 at 11:20 AM, Amit Langote wrote:
> Hello,
>
> Is it right that it is only in the case a password prompt is needed
> that a new connection is created after dropping the just-failed
> connection?
> I created a patch which enables it to use the existing connection in
> such a cas
On Tue, May 14, 2013 at 12:23 AM, Daniel Farina wrote:
> On Mon, May 13, 2013 at 3:02 PM, Peter Geoghegan wrote:
>> Has anyone else thought about approaches to mitigating the problems
>> that arise when an archive_command continually fails, and the DBA must
>> manually clean up the mess?
>
> Nota
There are a few .sql files in src/test/regress/sql/, that AFAICS are not
used for anything:
drop.sql
Looking at the history, this was used for some kind of cleanup in the
ancient regress.sh script. It has been unused since Nov 2000, when
regress.sh was removed.
euc_cn.sql
euc_jp.sql
euc_kr.
2013/5/14 Pavel Stehule :
> 2013/5/14 Magnus Hagander :
>> On Tue, May 14, 2013 at 9:36 PM, Pavel Stehule
>> wrote:
>>> 2013/5/14 Magnus Hagander :
psql in "connection string mode"
>>>
>>> Hi Magnus, can me send some link?
>>
>> http://www.postgresql.org/docs/9.2/static/app-psql.html
>>
>> "
Hello, Heikki.
You wrote:
HL> On 14.05.2013 21:36, Josh Berkus wrote:
>>
>>> I'm proposing this now as a possible GSoC project; I don't propose to
>>> actively work on it myself.
>>
>> The deadline for submitting GSOC projects (by students) was a week ago.
>> So is this a project suggestion for
83 matches
Mail list logo
