On Fri, May 8, 2009 at 3:43 AM, higepon wrote:
> Hi.
> Is the following todo item still necessary?
>
> Create dump tool for write-ahead logs for use in determining
> transaction id for point-in-time recovery.
> This is useful for checking PITR recovery.
>
> If so, I want to make it.
> What is
2009.05.09
pg_migrator alpha 5 results
from PostgreSQL 8.3.7 to 8.4cvs
Centos 5.2 x86_64 GNU/Linux
pg_migrator ran without errors.
Of 120 tables, all smaller tables
have the correct rowcount, but all
larger tables are 'truncated' at
around 10 million rows. I haven't
looked at table content.
Joshua D. Drake wrote:
Hello,
Here is a diff of version_stamp.pl. It is not quite done as I can't
actually get it to run. No matter what I do it doesn't appear to be able
to open configure.in.
If someone could help me figure out where I am being stupid I would
appreciate it.
Maybe you
On May 8, 2009, at 4:00 PM, Peter Eisentraut wrote:
(You can't be serious that for reverting a WC file to the repository
state you use "git checkout"?)
Why not? The purpose of the operation is to get a file from the
repository.
It's not much different whether you do it the first or the seco
On Fri, May 8, 2009 at 5:50 PM, Tom Lane wrote:
> "Joshua D. Drake" writes:
>> Yes I apologize for that. Git reacted differently than I expected to a
>> "git diff". I have since reposted a proper patch.
>
> mmm ... I've recently been forced into using git for another project,
> and I find myself
On Fri, May 8, 2009 at 6:41 PM, Alvaro Herrera
wrote:
> Andres Freund wrote:
>> Hi Alvaro,
>>
>> On 05/09/2009 12:26 AM, Alvaro Herrera wrote:
Perhaps a more difficult problem is that there is no easy way to update
a single file within a git repo. In cvs or svn, if I blow something up
>>
>
> Please add it to wiki.postgresql.org/wiki/CommitFestInProgress
>
Submitted under http://wiki.postgresql.org/wiki/CommitFest_2009-First#Clients
Regards,
Khee Chin.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresq
On Saturday 09 May 2009 01:41:20 Alvaro Herrera wrote:
> (You can't be serious that for reverting a WC file to the repository
> state you use "git checkout"?)
Why not? The purpose of the operation is to get a file from the repository.
It's not much different whether you do it the first or the s
Andres Freund wrote:
> Hi Alvaro,
>
> On 05/09/2009 12:26 AM, Alvaro Herrera wrote:
>>> Perhaps a more difficult problem is that there is no easy way to update
>>> a single file within a git repo. In cvs or svn, if I blow something up
>>> on a particular file and I just want to take a fresh look, I
Hi Alvaro,
On 05/09/2009 12:26 AM, Alvaro Herrera wrote:
Perhaps a more difficult problem is that there is no easy way to update
a single file within a git repo. In cvs or svn, if I blow something up
on a particular file and I just want to take a fresh look, I just rm;svn
update.
Hmm, you shoul
Hi Joshua,
On 05/09/2009 12:22 AM, Joshua D. Drake wrote:
Obviously, an unchecked cvs diff would have produced the same garbage. Any
other problems?
There are a number of conceptual differences. For example as a majority
svn user, svn diff does not act the way git diff does. In that svn diff
w
Joshua D. Drake wrote:
> Perhaps a more difficult problem is that there is no easy way to update
> a single file within a git repo. In cvs or svn, if I blow something up
> on a particular file and I just want to take a fresh look, I just rm;svn
> update.
Hmm, you should use "git revert" for that
On Sat, 2009-05-09 at 01:18 +0300, Peter Eisentraut wrote:
> On Saturday 09 May 2009 00:50:28 Tom Lane wrote:
> > "Joshua D. Drake" writes:
> > > Yes I apologize for that. Git reacted differently than I expected to a
> > > "git diff". I have since reposted a proper patch.
> >
> > mmm ... I've rece
Khee Chin escribió:
> > Hi,
>
> > I think that can be useful the command \di on psql show the method of
> > index (hash, btree, ...) like:
>
> > test=# \di
> >List of relations
> > Schema | Name | Type | Owner| Table | Method
> > -
On Saturday 09 May 2009 00:50:28 Tom Lane wrote:
> "Joshua D. Drake" writes:
> > Yes I apologize for that. Git reacted differently than I expected to a
> > "git diff". I have since reposted a proper patch.
>
> mmm ... I've recently been forced into using git for another project,
> and I find mysel
> Hi,
> I think that can be useful the command \di on psql show the method of
> index (hash, btree, ...) like:
> test=# \di
>List of relations
> Schema | Name | Type | Owner| Table | Method
> +---+---+--
Tom Lane wrote:
> Bruce Momjian writes:
> > Tom Lane wrote:
> >> No, that sounds like it should be sufficient ... but you need to check
> >> the template0 encodings match too, assuming that we make encoding and
> >> locale work the same here.
>
> > OK, are you suggesting checking the pg_database.
Magnus asked me for this, when the subject came up on IRC. This is a
longstanding ignored issue, for example
http://archives.postgresql.org/message-id/slrnemslp5.2rcr.andrew+non...@atlantis.supernews.net
http://archives.postgresql.org/message-id/15d55918-fa9c-4e6a-ba15-bdc9142a6...@contegix.com
--
In message <14727.1241816...@sss.pgh.pa.us>, Tom Lane writes:
> It is of course possible to support both at the same time (at
> compile-time, if nowhere else).
Yes, I suppose we'd not wish to just drop openssl completely.
I wonder how much code duplication would ensue from a
"Joshua D. Drake" writes:
> Yes I apologize for that. Git reacted differently than I expected to a
> "git diff". I have since reposted a proper patch.
mmm ... I've recently been forced into using git for another project,
and I find myself mystified as to why anyone would want to use it.
Seems lik
On Fri, 2009-05-08 at 17:44 -0400, Tom Lane wrote:
> "Joshua D. Drake" writes:
> > Here is a diff of version_stamp.pl.
>
> ... and nearly a megabyte of irrelevant junk. Please take a closer look at
> what you're sending before you send it ...
Never mind on this. I have obviously not re-honed my
On Fri, 2009-05-08 at 17:44 -0400, Tom Lane wrote:
> "Joshua D. Drake" writes:
> > Here is a diff of version_stamp.pl.
>
> ... and nearly a megabyte of irrelevant junk. Please take a closer look at
> what you're sending before you send it ...
Yes I apologize for that. Git reacted differently th
On Fri, 2009-05-08 at 14:16 -0700, Joshua D. Drake wrote:
> Hello,
>
> Here is a diff of version_stamp.pl. It is not quite done as I can't
> actually get it to run. No matter what I do it doesn't appear to be able
> to open configure.in.
>
> If someone could help me figure out where I am being st
"Joshua D. Drake" writes:
> Here is a diff of version_stamp.pl.
... and nearly a megabyte of irrelevant junk. Please take a closer look at
what you're sending before you send it ...
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
Bruce Momjian writes:
> Tom Lane wrote:
>> No, that sounds like it should be sufficient ... but you need to check
>> the template0 encodings match too, assuming that we make encoding and
>> locale work the same here.
> OK, are you suggesting checking the pg_database.encoding for
> template0 for b
Tom Lane wrote:
> Bruce Momjian writes:
> > Tom Lane wrote:
> >> One problem that just occurred to me is that this solution may not be
> >> adequate for pg_migrator. It will need to check that the new database
> >> has the same "default" settings (where "default" means "those of
> >> template0")
Seth Robertson writes:
> In message <12314.1241809...@sss.pgh.pa.us>, Tom Lane writes:
> BTW, I was reminded today that Fedora/Red Hat are hoping to standardize
> all crypto-related functionality in their entire distro on the NSS
> libraries:
> I am not perfectly up to speed, but swit
Bruce Momjian writes:
> Tom Lane wrote:
>> One problem that just occurred to me is that this solution may not be
>> adequate for pg_migrator. It will need to check that the new database
>> has the same "default" settings (where "default" means "those of
>> template0") as the old installation did.
Tom Lane wrote:
> One problem that just occurred to me is that this solution may not be
> adequate for pg_migrator. It will need to check that the new database
> has the same "default" settings (where "default" means "those of
> template0") as the old installation did. I think that's probably doa
Ricardo Bessa escribió:
> Hi,
>
> I think that can be useful the command \di on psql show the method of
> index (hash, btree, ...) like:
>
> test=# \di
>List of relations
> Schema | Name | Type | Owner| Table | Method
> +--
In message <12314.1241809...@sss.pgh.pa.us>, Tom Lane writes:
Seth Robertson writes:
> In message <8766.1241799...@sss.pgh.pa.us>, Tom Lane writes:
>> Hmm, shouldn't we fix *that* rather than inventing a hack like this?
> Basically doing this would probably become a proj
Hi,
I think that can be useful the command \di on psql show the method of
index (hash, btree, ...) like:
test=# \di
List of relations
Schema | Name | Type | Owner| Table | Method
+---+---+++--
Greg Smith writes:
> On Thu, 7 May 2009, Tom Lane wrote:
>> The tables will be created and used in schema 'a', and the effective
>> search path depth will be the same.
> The case to be concerned about here is where the search_path changes
> between initialization and the pgbench run, which cert
Seth Robertson writes:
> In message <8766.1241799...@sss.pgh.pa.us>, Tom Lane writes:
>> Hmm, shouldn't we fix *that* rather than inventing a hack like this?
> Basically doing this would probably become a project instead of a 5
> minute hack to support 80% of the functionality. I understand
On Thu, 7 May 2009, Tom Lane wrote:
The tables will be created and used in schema 'a', and the effective
search path depth will be the same.
The case to be concerned about here is where the search_path changes
between initialization and the pgbench run, which certainly isn't
impossible. Tha
Alvaro Herrera writes:
> Heikki Linnakangas wrote:
>> If we go with that, we should probably make the notion of a default
>> collation explicit. We could set pg_database.datcollate/datctype column
>> to NULL to mean "use the cluster default".
> I'm not sure how this would work. If I initdb w
Heikki Linnakangas wrote:
> If we go with that, we should probably make the notion of a default
> collation explicit. We could set pg_database.datcollate/datctype column
> to NULL to mean "use the cluster default".
I'm not sure how this would work. If I initdb with a certain
locale/encoding
Peter Eisentraut writes:
> On Friday 08 May 2009 19:09:51 Heikki Linnakangas wrote:
>> How about only outputting the LC_COLLATE/CTYPE options for databases
>> that use a non-default setting?
> That was my latest thinking as well.
Logically we should handle database encoding the same way, no?
I'
In message <8766.1241799...@sss.pgh.pa.us>, Tom Lane writes:
Seth Robertson writes:
> I had a situation where I needed to connect to multiple postgresql
> servers in a variety of programs written in a variety of languages,
> including some which connected to multiple servers at t
On Friday 08 May 2009 19:09:51 Heikki Linnakangas wrote:
> How about only outputting the LC_COLLATE/CTYPE options for databases
> that use a non-default setting? In the common scenarios where you have
> the same collation for the whole cluster it would work just like in
> previous releases. If you
On Fri, May 8, 2009 at 12:10 PM, Tom Lane wrote:
> Seth Robertson writes:
>> I had a situation where I needed to connect to multiple postgresql
>> servers in a variety of programs written in a variety of languages,
>> including some which connected to multiple servers at the same time.
>> As some
Seth Robertson writes:
> I had a situation where I needed to connect to multiple postgresql
> servers in a variety of programs written in a variety of languages,
> including some which connected to multiple servers at the same time.
> As some of you might know, you cannot usefully put multiple
> c
Tom Lane wrote:
Peter Eisentraut writes:
On Thursday 07 May 2009 20:54:37 Alvaro Herrera wrote:
I don't think there's much we can do apart from telling the user not to
move stuff across platforms that do not have equally named locales.
The other part of the problem is that there is no guaran
I had a situation where I needed to connect to multiple postgresql
servers in a variety of programs written in a variety of languages,
including some which connected to multiple servers at the same time.
As some of you might know, you cannot usefully put multiple
certificates or keys in the postgr
On Fri, May 8, 2009 at 3:49 PM, Kevin Grittner
wrote:
> Greg Stark wrote:
>
>> Well I don't understand what storing locks in an index can
>> accomplish if other queries might use other indexes or sequential
>> scans to access the records and never see those locks.
>>
>> Or does this method only r
Tom Lane wrote:
> Greg Stark writes:
>> ... Argh, sorry, as soon as I hit send I realized this is wrong.
>> Writers already need to insert into every index, so that's not a
>> problem.
>
> What about HOT?
I think that a read would need to lock both the row or tuple (not sure
exactly how that
Greg Stark writes:
> ... Argh, sorry, as soon as I hit send I realized this is wrong. Writers
> already need to insert into every index, so that's not a problem.
What about HOT?
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To m
Peter Eisentraut writes:
> On Thursday 07 May 2009 20:54:37 Alvaro Herrera wrote:
>> I don't think there's much we can do apart from telling the user not to
>> move stuff across platforms that do not have equally named locales.
> The other part of the problem is that there is no guarantee that eq
On Fri, May 8, 2009 at 4:12 PM, Greg Stark wrote:
> On Fri, May 8, 2009 at 3:49 PM, Kevin Grittner
> wrote:
>> Greg Stark wrote:
>>
>>> Well I don't understand what storing locks in an index can
>>> accomplish if other queries might use other indexes or sequential
>>> scans to access the records
Greg Stark wrote:
> Well I don't understand what storing locks in an index can
> accomplish if other queries might use other indexes or sequential
> scans to access the records and never see those locks.
>
> Or does this method only require that writers discover the locks and
> therefore only
Zdenek Kotala wrote:
Dne 24.04.09 07:17, Heikki Linnakangas napsal(a):
This diff in tsearch2.out surprised me:
@@ -2390,7 +2390,7 @@
Sea view wow foo bar qq
http://www.google.com/foo.bar.html"; target="_blank">YES
- ff-bg
+ ff-bg
document.write(15);
Any idea what's c
"Albe Laurenz" wrote:
> As far as I know, only the table rows that are found in the index
> scan are examined for visibility. Which would be only one in my
> example.
S2PL locking schemes routinely use index range locks.
> But in your attempt to sketch a way how true serializability could
>
On Fri, May 8, 2009 at 3:00 PM, Kevin Grittner
wrote:
> Greg Stark wrote:
>> On Thu, May 7, 2009 at 11:08 PM, Kevin Grittner
>> wrote:
>>> I would assume that SELECT shown above would either resolve to a
>>> table scan, in which case you would have to have an SIREAD lock at
>>> the table level
>
On Fri, May 8, 2009 at 3:00 PM, Kevin Grittner
wrote:
>
>> I've removed the broken email address for now -- please re-add the
>> correct email address.
>
> I'll see what I can find. When I last corresponded with him, he was
> still at the University of Sidney, working on his PhD by applying
> the
Greg Stark wrote:
> On Thu, May 7, 2009 at 11:08 PM, Kevin Grittner
> wrote:
>> I would assume that SELECT shown above would either resolve to a
>> table scan, in which case you would have to have an SIREAD lock at
>> the table level
>
> That sounds like we're back to the MSSQL/Sybase way of do
On Thursday 07 May 2009 20:54:37 Alvaro Herrera wrote:
> I don't think there's much we can do apart from telling the user not to
> move stuff across platforms that do not have equally named locales.
The other part of the problem is that there is no guarantee that equally or
similarly named locale
Hi.
Is the following todo item still necessary?
Create dump tool for write-ahead logs for use in determining
transaction id for point-in-time recovery.
This is useful for checking PITR recovery.
If so, I want to make it.
What is the expected output of the dump tool?
TransactionId, TimeLineI
Hi.
> fashion --- for instance, each page is read only once. Index scan will
> result in a random sequence of accesses to the heap. (Of course, it
> might have some order if the index is well correlated with the heap
> order, but most of the time that's not true.)
Thank you. I finally understan
58 matches
Mail list logo
