On Thu, Sep 29, 2011 at 10:52 AM, Gurjeet Singh wrote:
> On Thu, Sep 29, 2011 at 1:11 AM, Tom Lane wrote:
>>
>> Gurjeet Singh writes:
>> > I noticed that the savepointLevel member of TransactionStateData struct
>> > is
>> > initialized to 0 from TopTransactionStateData, and never incremented or
On Thu, Sep 29, 2011 at 1:11 AM, Tom Lane wrote:
> Gurjeet Singh writes:
> > I noticed that the savepointLevel member of TransactionStateData struct
> is
> > initialized to 0 from TopTransactionStateData, and never incremented or
> > decremented afterwards.
>
> > Since this is a file-local struc
Gurjeet Singh writes:
> I noticed that the savepointLevel member of TransactionStateData struct is
> initialized to 0 from TopTransactionStateData, and never incremented or
> decremented afterwards.
> Since this is a file-local struct I think we can simply get rid of all
> usages of this without
On ons, 2011-09-28 at 11:53 -0300, Alvaro Herrera wrote:
> Excerpts from Peter Eisentraut's message of mié sep 28 04:49:43 -0300 2011:
> > On tis, 2011-09-27 at 16:13 -0700, Steve Crawford wrote:
> > > It would perhaps be useful to add optional --old-confdir and
> > > --new-confdir parameters to p
I noticed that the savepointLevel member of TransactionStateData struct is
initialized to 0 from TopTransactionStateData, and never incremented or
decremented afterwards.
Since this is a file-local struct I think we can simply get rid of all
usages of this without any risk. I visited all the commi
Alvaro Herrera wrote:
>
> Excerpts from Bruce Momjian's message of mi?? sep 28 13:48:28 -0300 2011:
> > Bruce Momjian wrote:
> > > OK, so it fails for all tables and you are using the newest version.
> > > Thanks for all your work. I am now guessing that pg_upgrade 9.1.X is
> > > just broken on
Jamie Fox wrote:
> Thanks, I'm following the thread "pg_upgrade automatic testing" and
> will try the patch just detailed there.
I have applied the patch to head and 9.1.X. We still have a win32 bug
to fix. It is a shame I was not able to fix these before 9.1.1 was
released. :-(
--
Bruce Momjian wrote:
> Bruce Momjian wrote:
> > Tom Lane wrote:
> > > Bruce Momjian writes:
> > > > I propose I just remove the 8.4
> > > > test and always allow toast table names not to match --- the oids are
> > > > still checked and are preserved.
> > >
> > > +1. You'll still make the check f
On Wed, Sep 28, 2011 at 10:39 AM, Marko Tiikkaja
wrote:
> Simply add this to your .psqlrc:
>
> \set ON_ERROR_ROLLBACK on
Thank you Marko and Alvaro for pointing me in the right direction. I
set it to 'interactive', which I think makes the most sense.
I do wish this behavior was a little more d
Excerpts from Bruce Momjian's message of mié sep 28 13:48:28 -0300 2011:
> Bruce Momjian wrote:
> > OK, so it fails for all tables and you are using the newest version.
> > Thanks for all your work. I am now guessing that pg_upgrade 9.1.X is
> > just broken on Windows.
> >
> > Perhaps the vari
On Wed, Sep 28, 2011 at 12:50 PM, Magnus Hagander wrote:
>
>> pg_receivexlog worked good in my tests.
>>
>> pg_basebackup with --xlog=stream gives me an already recycled wal
>> segment message (note that the file was in pg_xlog in the standby):
>> FATAL: could not receive data from WAL stream: FA
panam wrote:
> Hi Bruce,
>
> here is the file you asked for:
> http://postgresql.1045698.n5.nabble.com/file/n4850735/pg_upgrade_logfile.txt
> pg_upgrade_logfile.txt
>
OK, I see it using -b to pg_ctl:
""C:\Program Files\PostgreSQL\9.1\bin/pg_ctl" -w -l "nul" -D
"D:\applications\postgr
On Wed, Sep 28, 2011 at 1:02 PM, Kevin Grittner
wrote:
> Alvaro Herrera wrote:
>
>>> ON_ERROR_ROLLBACK ["on" can be a problem in a script file]
>
>> So set it to "interactive".
>
> I think we have an opportunity for a documentation enhancement there.
In the same vein, I think there may also be s
Florian Pflug wrote:
> On Sep28, 2011, at 15:32 , Alexander Soudakov wrote:
>> Here you can find www_fdw feature documentation:
>> http://wiki.postgresql.org/wiki/WWW_FDW
>
> Certainly looks useful (as a third-party extension, as others have
> already pointed out)
Our programmers agree that it
Hi Bruce,
here is the file you asked for:
http://postgresql.1045698.n5.nabble.com/file/n4850735/pg_upgrade_logfile.txt
pg_upgrade_logfile.txt
I guess you are not addressing me here, right?
> The server will need to
> be started with -b and this will disable autovacuum. Can someone on
> Windo
On Sep28, 2011, at 15:32 , Alexander Soudakov wrote:
> Here you can find www_fdw feature documentation:
> http://wiki.postgresql.org/wiki/WWW_FDW
Certainly looks useful (as a third-party extension, as others have already
pointed out)
What I didn't quite understand is how one would pass (dynamic)
Guys,
I suggest Alexander to announce his project just to let all us know and
avoid duplicate work. I hope it's a good starter project for Alexander !
I agree with Andrew, it's also should be posted to -general.
It's clear it should be an extension !
Oleg
On Wed, 28 Sep 2011, Tom Lane wrote:
2011/9/28 MauMau :
> Hello,
>
> Please let me ask you some questions about RelCache/SysCache/CatCache
> design. I know I should post this to pgsql-general, but I decided to post
> here because the content includes design questions.
>
> <>
> My customer is facing a "out of memory" problem during a b
Alvaro Herrera wrote:
>> ON_ERROR_ROLLBACK ["on" can be a problem in a script file]
> So set it to "interactive".
I think we have an opportunity for a documentation enhancement there.
-Kevin
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your sub
Brar Piening wrote:
The attached patch includes documentation changes and excludes my
versions of pgbison.pl and pgflex.pl which have been replaced by
Andrews' versions that are already commited.
Building current head today I noticed that the patch doesn't apply
cleanly anymore.
Attached
Excerpts from Stephen Frost's message of mié sep 28 16:22:58 -0300 2011:
> Be careful when running scripts, however.. Any invocation of psql will
> read you .psqlrc and if you've got ON_ERROR_ROLLBACK set there then
> psql -f blah ; will pick up on that and you'll end up running every
> command
* Kevin Grittner (kevin.gritt...@wicourts.gov) wrote:
> Alvaro Herrera wrote:
> > See ON_ERROR_ROLLBACK
> > http://www.postgresql.org/docs/9.0/static/app-psql.html
>
> I had missed that. Dang, this database product is rich with nice
> features! :-)
Be careful when running scripts, however..
On Wed, Sep 28, 2011 at 02:25:44PM -0400, Gurjeet Singh wrote:
> On Wed, Sep 28, 2011 at 1:51 PM, Kevin Grittner > wrote:
>
> > Alvaro Herrera wrote:
> >
> > > See ON_ERROR_ROLLBACK
> > > http://www.postgresql.org/docs/9.0/static/app-psql.html
> >
> > I had missed that. Dang, this database prod
On Wed, Sep 28, 2011 at 1:51 PM, Kevin Grittner wrote:
> Alvaro Herrera wrote:
>
> > See ON_ERROR_ROLLBACK
> > http://www.postgresql.org/docs/9.0/static/app-psql.html
>
> I had missed that. Dang, this database product is rich with nice
> features! :-)
>
+1
I would like it to be on/interactiv
On Wed, Sep 28, 2011 at 09:30, Jaime Casanova wrote:
> On Wed, Sep 28, 2011 at 1:38 AM, Jaime Casanova wrote:
>> On Tue, Aug 16, 2011 at 9:32 AM, Magnus Hagander wrote:
>>> Here's an updated version of pg_receivexlog, that should now actually
>>> work (it previously failed miserably when a repli
Alvaro Herrera wrote:
> See ON_ERROR_ROLLBACK
> http://www.postgresql.org/docs/9.0/static/app-psql.html
I had missed that. Dang, this database product is rich with nice
features! :-)
-Kevin
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subs
On Wed, Sep 28, 2011 at 08:38, Jaime Casanova wrote:
> On Tue, Aug 16, 2011 at 9:32 AM, Magnus Hagander wrote:
>> Here's an updated version of pg_receivexlog, that should now actually
>> work (it previously failed miserably when a replication record crossed
>> a WAL file boundary - something whic
Gurjeet Singh wrote:
> Will Leinweber wrote:
>
>> I ruined a 5 hour UPDATE by typoing a table name on a SELECT to
>> verify the update worked.
Ouch! I normally use tab-completion or copy/paste to save myself
from myself in such situations.
>> I only later found out about SAVEPOINT, which I
Excerpts from Will Leinweber's message of mar sep 27 20:57:52 -0300 2011:
> I ruined a 5 hour UPDATE by typoing a table name on a SELECT to verify
> the update worked. I suppose I have no one else to blame, but it was
> really frustrating, to say the least. I assume this has happened to
> others a
On 28/09/2011 02:57, Will Leinweber wrote:
psql console, while in a transaction, and while in interactive mode,
should savepoint for me.
You are lucky, since that feature has been in psql for some time
already. Simply add this to your .psqlrc:
\set ON_ERROR_ROLLBACK on
--
Marko Tiikkaja
On Tue, Sep 27, 2011 at 7:57 PM, Will Leinweber wrote:
> I ruined a 5 hour UPDATE by typoing a table name on a SELECT to verify
> the update worked. I suppose I have no one else to blame, but it was
> really frustrating, to say the least. I assume this has happened to
> others as well.
>
> I only
I ruined a 5 hour UPDATE by typoing a table name on a SELECT to verify
the update worked. I suppose I have no one else to blame, but it was
really frustrating, to say the least. I assume this has happened to
others as well.
I only later found out about SAVEPOINT, which I immediately ran the
next t
Bruce Momjian wrote:
> OK, so it fails for all tables and you are using the newest version.
> Thanks for all your work. I am now guessing that pg_upgrade 9.1.X is
> just broken on Windows.
>
> Perhaps the variables set by pg_upgrade_support.so are not being passed
> into the server variables?
Andrew Dunstan writes:
> Why should this be a core feature, as the subject suggests? It could
> just be an extension, like other FDWs, no?
In fact it had *better* be an extension, not core, because anything that
allows the server to go out and touch the web is going to be a security
hazard in so
On 09/28/2011 11:41 AM, Alexander Soudakov wrote:
On Wed, Sep 28, 2011 at 7:17 PM, David Fetter wrote:
On Wed, Sep 28, 2011 at 05:32:37PM +0400, Alexander Soudakov wrote:
Greetings postgres hackers!
Here you can find www_fdw feature documentation:
http://wiki.postgresql.org/wiki/WWW_FDW
Lo
inline
On Wed, Sep 28, 2011 at 7:21 PM, Andrew Dunstan wrote:
>
>
> On 09/28/2011 09:32 AM, Alexander Soudakov wrote:
>>
>> Greetings postgres hackers!
>>
>> Here you can find www_fdw feature documentation:
>> http://wiki.postgresql.org/wiki/WWW_FDW
>>
>> Looking forward for your feedback.
>>
>
>
On 09/28/2011 11:46 AM, Alexander Soudakov wrote:
Why should this be a core feature, as the subject suggests? It could just be
an extension, like other FDWs, no?
Subject?
I didn't mean this, truly speaking I missed this moment.
But now I guess it would be ok it to be extension like other FD
On Wed, Sep 28, 2011 at 7:17 PM, David Fetter wrote:
> On Wed, Sep 28, 2011 at 05:32:37PM +0400, Alexander Soudakov wrote:
>> Greetings postgres hackers!
>>
>> Here you can find www_fdw feature documentation:
>> http://wiki.postgresql.org/wiki/WWW_FDW
>>
>> Looking forward for your feedback.
>
> D
On 09/28/2011 09:32 AM, Alexander Soudakov wrote:
Greetings postgres hackers!
Here you can find www_fdw feature documentation:
http://wiki.postgresql.org/wiki/WWW_FDW
Looking forward for your feedback.
Why should this be a core feature, as the subject suggests? It could
just be an extensi
On 09/28/2011 12:49 AM, Peter Eisentraut wrote:
On tis, 2011-09-27 at 16:13 -0700, Steve Crawford wrote:
It would perhaps be useful to add optional --old-confdir and
--new-confdir parameters to pg_upgrade. If these parameters are absent
then pg_upgrade would work as it does now and assume that t
On Wed, Sep 28, 2011 at 05:32:37PM +0400, Alexander Soudakov wrote:
> Greetings postgres hackers!
>
> Here you can find www_fdw feature documentation:
> http://wiki.postgresql.org/wiki/WWW_FDW
>
> Looking forward for your feedback.
Do you have some libraries you plan to base this on, or will you
Excerpts from Peter Eisentraut's message of mié sep 28 04:49:43 -0300 2011:
> On tis, 2011-09-27 at 16:13 -0700, Steve Crawford wrote:
> > It would perhaps be useful to add optional --old-confdir and
> > --new-confdir parameters to pg_upgrade. If these parameters are absent
> > then pg_upgrade wo
Greetings postgres hackers!
Here you can find www_fdw feature documentation:
http://wiki.postgresql.org/wiki/WWW_FDW
Looking forward for your feedback.
--
Alexander Soudakov
Developer Programmer
email: cyga...@gmail.com
skype: asudakov
--
Sent via pgsql-hackers mailing list (pgsql-hackers@pos
Thanks, I'm following the thread "pg_upgrade automatic testing" and
will try the patch just detailed there.
Jamie
On Wed, Sep 28, 2011 at 12:50 AM, Peter Eisentraut wrote:
> On tis, 2011-09-27 at 16:19 -0700, Jamie Fox wrote:
>>
>> It fails at this stage:
>>
>> Restoring user relation files
Hi Marko,
On Wed, Sep 28, 2011 at 2:29 AM, Marko Tiikkaja
wrote:
> In a sequence such as this:
>
> BEGIN TRANSACTION ISOLATION LEVEL SERIALIZABLE;
> INSERT INTO foo VALUES (-1);
> SELECT pg_export_snapshot();
>
> the row added to "foo" is not visible in the exported snapshot. If that's
> the
panam wrote:
> Here are all generated log files.
>
> I just removed all other DBs except gnucash (which includes the accounts
> table), but the issue also emerges with other DBs.
> Upgraded the 9.1 instance to the new build (9.1.1.) as well but this
> apparently did not change anything.
> PG versi
Bruce Momjian wrote:
> Tom Lane wrote:
> > Bruce Momjian writes:
> > > I propose I just remove the 8.4
> > > test and always allow toast table names not to match --- the oids are
> > > still checked and are preserved.
> >
> > +1. You'll still make the check for non-toast tables, of course?
>
>
Hello,
Please let me ask you some questions about RelCache/SysCache/CatCache
design. I know I should post this to pgsql-general, but I decided to post
here because the content includes design questions.
<>
My customer is facing a "out of memory" problem during a batch job. I'd like
to know t
Here are all generated log files.
I just removed all other DBs except gnucash (which includes the accounts
table), but the issue also emerges with other DBs.
Upgraded the 9.1 instance to the new build (9.1.1.) as well but this
apparently did not change anything.
PG versions are (including generate
On tis, 2011-09-27 at 16:19 -0700, Jamie Fox wrote:
>
> It fails at this stage:
>
> Restoring user relation files
> linking /data/pgsql/prod-84/base/11564/2613 to
> /data/pgsql/prod-91/base/12698/12570
> linking /data/pgsql/prod-84/base/11564/2683 to
> /data/pgsql/prod-91/base/12698/1
On tis, 2011-09-27 at 16:13 -0700, Steve Crawford wrote:
> It would perhaps be useful to add optional --old-confdir and
> --new-confdir parameters to pg_upgrade. If these parameters are absent
> then pg_upgrade would work as it does now and assume that the config
> files are in the datadir.
It
On Wed, Sep 28, 2011 at 1:38 AM, Jaime Casanova wrote:
> On Tue, Aug 16, 2011 at 9:32 AM, Magnus Hagander wrote:
>> Here's an updated version of pg_receivexlog, that should now actually
>> work (it previously failed miserably when a replication record crossed
>> a WAL file boundary - something wh
52 matches
Mail list logo
