Peter Eisentraut writes:
> In file included from ./src/include/utils/catcache.h:25:0,
> from /tmp/cpluspluscheck.bt8VZr/test.cpp:3:
> src/include/lib/ilist.h: In function âdlist_node*
> dlist_head_node(dlist_head*)â:
> src/include/lib/ilist.h:470:39: error: invalid conversion
Pavan Deolasee writes:
> On Tue, Nov 27, 2012 at 9:01 AM, Tom Lane wrote:
>> Either state of indcheckxmin is valid with all three of these
>> combinations, so the specific kluge I was contemplating above doesn't
>> work. But there is no valid reason for an index to be in this state:
>> indisvali
In file included from ./src/include/utils/catcache.h:25:0,
from /tmp/cpluspluscheck.bt8VZr/test.cpp:3:
src/include/lib/ilist.h: In function ‘dlist_node* dlist_head_node(dlist_head*)’:
src/include/lib/ilist.h:470:39: error: invalid conversion from ‘void*’ to
‘dlist_node*’ [-fpermis
On Tue, Nov 27, 2012 at 9:01 AM, Tom Lane wrote:
> I wrote:
>
> Either state of indcheckxmin is valid with all three of these
> combinations, so the specific kluge I was contemplating above doesn't
> work. But there is no valid reason for an index to be in this state:
>
> indisvalid = true, indi
> -Original Message-
> From: pgsql-hackers-ow...@postgresql.org [mailto:pgsql-hackers-
> ow...@postgresql.org] On Behalf Of Peter Eisentraut
> Sent: 27 November 2012 13:35
> To: Kevin Grittner
> Cc: Pgsql Hackers
> Subject: Re: [HACKERS] Materialized views WIP patch
>
> On Mon, 2012-11-26
On Tue, Nov 27, 2012 at 12:31 PM, Tom Lane wrote:
> I wrote:
> > I'm a bit inclined to think that DROP INDEX CONCURRENTLY should have an
> > additional step that somehow marks the pg_index row in a new way that
> > makes RelationGetIndexList ignore it, and then wait out existing
> > transactions
On Mon, 2012-11-26 at 09:26 -0800, Thangalin wrote:
> Is it possible to build an XML (or JSON) document using a map database
> columns to XPath expressions? For example:
>
> root > people
> person > person
> person.first_name -> name/first
> person.last_name -> name/last
On Mon, 2012-11-26 at 13:14 -0500, Bruce Momjian wrote:
> I would normally agree with this analysis, but pg_ctl -w certainly
> need this ping functionality, so it kind of makes sense that others
> might need it too.
Sure, PQping is useful for this very specific use case of seeing whether
the serv
On 11/26/2012 09:30:48 PM, Karl O. Pinc wrote:
> On 11/26/2012 08:45:08 PM, Josh Kupershmidt wrote:
> > It is a common administrative task to selectively restore some
> > existing tables' contents from a backup, and IIRC was the impetus
> for
> > this patch.
>
> Yes. (And aside from listing tabl
Andres Freund writes:
> On 2012-10-05 19:56:40 -0400, Tom Lane wrote:
>> I think this could possibly be fixed by using nontransactional
>> update-in-place when we're trying to change indisvalid and/or
>> indisready, but I've not really thought through the details.
> I couldn't really think of any
I wrote:
> I'm a bit inclined to think that DROP INDEX CONCURRENTLY should have an
> additional step that somehow marks the pg_index row in a new way that
> makes RelationGetIndexList ignore it, and then wait out existing
> transactions before taking the final step of dropping the index. The
> Rig
On 11/26/2012 08:45:08 PM, Josh Kupershmidt wrote:
> On Mon, Nov 26, 2012 at 3:42 PM, Robert Haas
> wrote:
> > On Mon, Nov 26, 2012 at 4:51 PM, Karl O. Pinc wrote:
> >> P.S. An outstanding question regards --truncate-tables
> >> is whether it should drop indexes before truncate
> >> and re-creat
Alvaro Herrera writes:
> I gather that this is supposed to be back-patched to all supported
> branches.
FWIW, I don't like that patch any better than Robert does. It seems
as likely to do harm as good. If there are places where libpq itself
is leaving entries on the error stack, we should fix t
On Mon, Nov 26, 2012 at 3:42 PM, Robert Haas wrote:
> On Mon, Nov 26, 2012 at 4:51 PM, Karl O. Pinc wrote:
>> P.S. An outstanding question regards --truncate-tables
>> is whether it should drop indexes before truncate
>> and re-create them after restore. Sounds like it should.
>
> Well, that wo
On Mon, 2012-11-26 at 09:46 -0500, Peter Eisentraut wrote:
> On 11/14/12 9:28 PM, Kevin Grittner wrote:
> > 17. Since the data viewed in an MV is not up-to-date with the latest
> > committed transaction,
>
> So, the way I understand it, in Oracle terms, this feature is a
> "snapshot", not a ma
Bruce Momjian writes:
> Testing pg_dump for 4k tables (16 seconds) shows the first row is not
> output by pg_dump until 15 seconds, meaning there can't be any
> parallelism with a pipe. (Test script attached.) Does anyone know how
> to get pg_dump to send some output earlier?
You can't. By the
Lars Kanis wrote:
> While investigating a ruby-pg issue [1], we noticed that a libpq SSL
> connection can fail, if the running application uses OpenSSL for
> other work, too. Root cause is the thread local error queue of
> OpenSSL, that is used to transmit textual error messages to the
> applicatio
On Mon, Nov 26, 2012 at 3:03 PM, Robert Haas wrote:
> On Mon, Nov 26, 2012 at 3:29 PM, Jeff Davis wrote:
>> Your intuition here is better than mine, but I am still missing
>> something here. If we keep the buffer pinned, then there will be very
>> few pin/unpin cycles here, so I don't see where
On Mon, Nov 26, 2012 at 4:51 PM, Karl O. Pinc wrote:
> Where I would like to go with this is to first introduce,
> as a new patch, an ALTER TABLE option to disable a
> constraint. Something like
>
> ALTER TABLE foo UNVALIDATE CONSTRAINT "constraintname";
This doesn't really make sense, because
Satoshi Nagayasu escribió:
> I attached the latest one, which splits the reset_time
> for bgwriter and walwriter, and provides new system view,
> called pg_stat_walwriter, to show the dirty write counter
> and the reset time.
Thanks. I gave this a look and I have a couple of comments:
1. The co
On Wed, Nov 14, 2012 at 10:08:15AM -0500, Bruce Momjian wrote:
> > I agree that parallel restore for schemas is a hard problem. But I
> > didn't mean parallelism within the restore, I meant that we could
> > start both postmasters and pipe the output from dump directly to
> > restore. This way the
On Mon, 2012-11-26 at 16:10 -0500, Tom Lane wrote:
> There's still the issue of whether the IOS code is safe in machines with
> weak memory ordering. I think that it probably is safe, but the
> argument for it in the current code comment is wrong; most likely, a
> correct argument has to depend on
On 11/26/2012 12:06:56 PM, Robert Haas wrote:
> On Wed, Nov 21, 2012 at 12:53 AM, Josh Kupershmidt
> wrote:
> > TBH, I didn't find the example above particularly compelling for
> > demonstrating the need for this feature. If you've just got one
> table
> > with dependent views which needs to be re
Andres Freund writes:
> On 2012-10-31 11:41:37 +0530, Amit Kapila wrote:
>> There seems to be a problem in behavior of Create Index Concurrently and Hot
>> Update in HEAD code .
> At pgcon.it I had a chance to discuss with Simon how to fix this
> bug. Please check the attached patches - and their
On Mon, Nov 26, 2012 at 04:34:36PM -0500, Kevin Grittner wrote:
> David Fetter wrote:
> > On Mon, Nov 26, 2012 at 09:46:33AM -0500, Peter Eisentraut wrote:
>
> >> So, the way I understand it, in Oracle terms, this feature is a
> >> "snapshot", not a materialized view. Maybe that's what it should
>
David Fetter wrote:
> On Mon, Nov 26, 2012 at 09:46:33AM -0500, Peter Eisentraut wrote:
>> So, the way I understand it, in Oracle terms, this feature is a
>> "snapshot", not a materialized view. Maybe that's what it should
>> be called then.
>
> "Snapshot" is one of the options for refreshing an
Marko Tiikkaja wrote:
> On 15/11/2012 03:28, Kevin Grittner wrote:
> I have been testing the patch a bit
Thanks!
> and I'm slightly disappointed by the fact that it still doesn't
> solve this problem (and I apologize if I have missed discussion
> about this in the docs or in this thread):
>
>
Peter Eisentraut wrote:
> Here is a patch to support RFC 2255 LDAP URLs in pg_hba.conf. So,
> instead of, say
>
> host ... ldap ldapserver=ldap.example.net ldapbasedn="dc=example, dc=net"
> ldapsearchattribute=uid
>
> you could write
>
> host ... ldap lapurl="ldap://ldap.example.net/dc=example
Jeff Davis writes:
> On Sun, 2012-11-25 at 22:30 -0500, Tom Lane wrote:
>> Another possibly important point is that reducing the number of
>> pin/unpin cycles for a given VM page might actually hurt the chances of
>> it being found in shared buffers, because IIRC the usage_count is bumped
>> once
On Mon, Nov 26, 2012 at 3:05 PM, Tom Lane wrote:
> The analogy to other aggregates is probably a better thing to argue
> from. On the other hand, I don't know anyone outside the SQL standards
> committee who thinks it's actually a good idea that SUM() across no rows
> returns null rather than zer
On Mon, Nov 26, 2012 at 3:29 PM, Jeff Davis wrote:
> Your intuition here is better than mine, but I am still missing
> something here. If we keep the buffer pinned, then there will be very
> few pin/unpin cycles here, so I don't see where the contention would
> come from (any more than there is co
Hannu Krosing writes:
> On 11/26/2012 09:05 PM, Tom Lane wrote:
>> The analogy to other aggregates is probably a better thing to argue
>> from. On the other hand, I don't know anyone outside the SQL standards
>> committee who thinks it's actually a good idea that SUM() across no rows
>> returns n
On 11/26/2012 09:05 PM, Tom Lane wrote:
Hannu Krosing writes:
In some previous mail Tom Lane claimed that by SQL standard
either an array of all NULLs or a record with all fields NULLs (I
don't remember which) is also considered NULL. If this is true,
then an empty array - which can be said to
On Sun, 2012-11-25 at 22:30 -0500, Tom Lane wrote:
> I'd be worried about the case of a lot of sessions touching a lot of
> unrelated tables. This change implies doubling the number of buffers
> that are held pinned by any given query, and the distributed overhead
> from that (eg, adding cycles to
Hannu Krosing writes:
> In some previous mail Tom Lane claimed that by SQL standard
> either an array of all NULLs or a record with all fields NULLs (I
> don't remember which) is also considered NULL. If this is true,
> then an empty array - which can be said to consist of nothing
> but NULLs - sh
On 11/22/2012 11:54 AM, Dimitri Fontaine wrote:
Andrew Dunstan writes:
Here is a WIP patch for enhancements to json generation.
First, there is the much_requested json_agg, which will aggregate rows
directly to json. So the following will now work:
select json_agg(my_table) from mytable;
On 11/26/2012 02:46 PM, Hannu Krosing wrote:
On 11/26/2012 08:12 PM, Peter Eisentraut wrote:
On 11/21/12 3:16 PM, Andrew Dunstan wrote:
One open question regarding this feature is whether this should return
NULL or '[]' for 0 rows. Currently it returns NULL but I could be
convinced to return '
On Mon, Nov 26, 2012 at 4:55 PM, Heikki Linnakangas wrote:
>
> Great, that top-level comment helped tremendously! I feel enlightened.
>
> I fixed some spelling, formatting etc. trivial stuff while reading through
> the patch, see attached. Below is some feedback on the details:
>
> * I don't like
On 11/26/2012 08:12 PM, Peter Eisentraut wrote:
On 11/21/12 3:16 PM, Andrew Dunstan wrote:
One open question regarding this feature is whether this should return
NULL or '[]' for 0 rows. Currently it returns NULL but I could be
convinced to return '[]', and the change would be very small.
Altho
On Sat, Nov 24, 2012 at 09:42:08PM -0800, Jeff Janes wrote:
> On Fri, Nov 23, 2012 at 7:22 PM, Bruce Momjian wrote:
> > On Mon, Nov 19, 2012 at 12:11:26PM -0800, Jeff Janes wrote:
> >
> >>
> >> Yes, it is with synchronous_commit=off. (or if it wasn't originally,
> >> it is now, with the same resu
On 11/21/12 3:16 PM, Andrew Dunstan wrote:
> One open question regarding this feature is whether this should return
> NULL or '[]' for 0 rows. Currently it returns NULL but I could be
> convinced to return '[]', and the change would be very small.
Although my intuition would be [], the existing co
Andres Freund escribió:
> On 2012-11-26 17:27:11 +0100, Magnus Hagander wrote:
> > On Mon, Nov 26, 2012 at 5:21 PM, Andres Freund
> > wrote:
> > > I have submitted a proposed fix for it friday:
> > >
> > > http://archives.postgresql.org/message-id/20121124155005.GA10299%40awork2.anarazel.de
> >
On Mon, Nov 26, 2012 at 10:26:27AM -0500, Peter Eisentraut wrote:
> On 11/23/12 9:48 AM, Michael Paquier wrote:
> > We waited a couple of days for feedback for this feature. So based on
> > all the comments provided by everybody on this thread, perhaps we should
> > move on and implement the option
On Wed, Nov 21, 2012 at 12:53 AM, Josh Kupershmidt wrote:
> TBH, I didn't find the example above particularly compelling for
> demonstrating the need for this feature. If you've just got one table
> with dependent views which needs to be restored, it's pretty easy to
> manually TRUNCATE and have p
On Thu, Nov 22, 2012 at 4:54 AM, Dimitri Fontaine
wrote:
> Andrew Dunstan writes:
>> Here is a WIP patch for enhancements to json generation.
>>
>> First, there is the much_requested json_agg, which will aggregate rows
>> directly to json. So the following will now work:
>>
>> select json_agg
On Mon, Nov 26, 2012 at 11:43 AM, Andrew Dunstan wrote:
> I don't understand why you would want to create such a cast. If the cast
> doesn't exist it will do exactly what it does now, i.e. use the type's
> output function and then json quote and escape it, which in the case of
> citext is the Righ
On Mon, Nov 26, 2012 at 5:33 PM, Tom Lane wrote:
> Magnus Hagander writes:
>> It's no longer possible to build pgadmin with libpq from git master:
>> /opt/pgsql/inst-pg/head/include/libpq-fe.h:551:8: error: ‘pg_int64’
>> does not name a type
>
> [ scratches head ... ] That should be typedef'd in
On 11/26/2012 10:55 AM, Robert Haas wrote:
On Wed, Nov 21, 2012 at 3:16 PM, Andrew Dunstan wrote:
Non-builtin types are now searched for a cast to json, and if it exists it
is used instead of the type's text representation. I didn't add a special
type to look for a cast to, as was discussed be
Magnus Hagander writes:
> It's no longer possible to build pgadmin with libpq from git master:
> /opt/pgsql/inst-pg/head/include/libpq-fe.h:551:8: error: pg_int64
> does not name a type
[ scratches head ... ] That should be typedef'd in postgres_ext.h.
regards, tom lan
On 2012-11-26 17:27:11 +0100, Magnus Hagander wrote:
> On Mon, Nov 26, 2012 at 5:21 PM, Andres Freund wrote:
> > On 2012-11-26 21:35:05 +0530, Pavan Deolasee wrote:
> >> On Mon, Nov 26, 2012 at 9:17 PM, Tom Lane wrote:
> >>
> >> > We're about due for a new set of back-branch update releases. Aft
On Mon, Nov 26, 2012 at 5:21 PM, Andres Freund wrote:
> On 2012-11-26 21:35:05 +0530, Pavan Deolasee wrote:
>> On Mon, Nov 26, 2012 at 9:17 PM, Tom Lane wrote:
>>
>> > We're about due for a new set of back-branch update releases. After
>> > some discussion among the packagers, it seems the best
It's no longer possible to build pgadmin with libpq from git master:
/opt/pgsql/inst-pg/head/include/libpq-fe.h:551:8: error: ‘pg_int64’
does not name a type
and related messages about it.
This seems to be related to
http://git.postgresql.org/gitweb/?p=postgresql.git&a=commitdiff&h=95d035e66d8e4
On 2012-11-26 21:35:05 +0530, Pavan Deolasee wrote:
> On Mon, Nov 26, 2012 at 9:17 PM, Tom Lane wrote:
>
> > We're about due for a new set of back-branch update releases. After
> > some discussion among the packagers, it seems the best window for
> > getting this done before the holiday season se
On Fri, Nov 23, 2012 at 5:34 PM, Jeff Janes wrote:
> On Thu, Nov 15, 2012 at 7:05 PM, Jeff Janes wrote:
>> On Wed, Nov 14, 2012 at 11:49 AM, Tom Lane wrote:
>>> Jeff Janes writes:
On Thu, Nov 8, 2012 at 9:50 PM, Tom Lane wrote:
> There are at least three ways we could whack that mole:
Robert Haas writes:
> On Mon, Nov 26, 2012 at 10:55 AM, Tom Lane wrote:
>> We have to do something about this one way or another before we can ship
>> 9.2.2. Is the consensus to revert this patch:
>> http://git.postgresql.org/gitweb/?p=postgresql.git;a=commitdiff;h=d573e239f03506920938bf0be56c86
On Mon, Nov 26, 2012 at 5:04 PM, Tom Lane wrote:
> Magnus Hagander writes:
>> I noticed after a pg_upgrade on a system, that the same oid is used
>> both for a database and a user (repeated many times for different
>> combinations of databases and users). This is because pg_upgrade
>> doesn't pre
On Mon, Nov 26, 2012 at 9:17 PM, Tom Lane wrote:
> We're about due for a new set of back-branch update releases. After
> some discussion among the packagers, it seems the best window for
> getting this done before the holiday season sets in is next week.
>
> Also, as previously mentioned, we're
On Mon, Nov 26, 2012 at 04:02:17PM +, Peter Geoghegan wrote:
> On 26 November 2012 15:24, David Fetter wrote:
> > I hate to add to the bike-shedding, but we should probably add
> > REFRESH SNAPSHOT as an optional piece of the grammar, with more
> > REFRESH options to come.
>
> I don't know th
Magnus Hagander writes:
> I noticed after a pg_upgrade on a system, that the same oid is used
> both for a database and a user (repeated many times for different
> combinations of databases and users). This is because pg_upgrade
> doesn't preserve the database oid, and it reused the oid of the row
On 26 November 2012 15:24, David Fetter wrote:
> I hate to add to the bike-shedding, but we should probably add REFRESH
> SNAPSHOT as an optional piece of the grammar, with more REFRESH
> options to come.
I don't know that they should be called materialised views, but do we
really need to overloa
On Mon, Nov 26, 2012 at 10:55 AM, Tom Lane wrote:
> Simon Riggs writes:
>> On 11 October 2012 20:43, Tom Lane wrote:
>>> Robert Haas writes:
So we have to take the snapshot before you begin execution, but it
seems that to avoid surprising behavior we also have to take it after
ac
I noticed after a pg_upgrade on a system, that the same oid is used
both for a database and a user (repeated many times for different
combinations of databases and users). This is because pg_upgrade
doesn't preserve the database oid, and it reused the oid of the row in
pg_authid.
The reason I noti
Simon Riggs writes:
> On 11 October 2012 20:43, Tom Lane wrote:
>> Robert Haas writes:
>>> So we have to take the snapshot before you begin execution, but it
>>> seems that to avoid surprising behavior we also have to take it after
>>> acquiring locks. And it looks like locking is intertwined w
On Wed, Nov 21, 2012 at 3:16 PM, Andrew Dunstan wrote:
> Non-builtin types are now searched for a cast to json, and if it exists it
> is used instead of the type's text representation. I didn't add a special
> type to look for a cast to, as was discussed before, as it seemed a bit
> funky and unne
We're about due for a new set of back-branch update releases. After
some discussion among the packagers, it seems the best window for
getting this done before the holiday season sets in is next week.
Also, as previously mentioned, we're experimenting with weekday
rather than over-the-weekend rele
On Tue, Nov 27, 2012 at 12:26 AM, Peter Eisentraut wrote:
> On 11/23/12 9:48 AM, Michael Paquier wrote:
> > We waited a couple of days for feedback for this feature. So based on
> > all the comments provided by everybody on this thread, perhaps we should
> > move on and implement the options that
On 11/23/12 9:48 AM, Michael Paquier wrote:
> We waited a couple of days for feedback for this feature. So based on
> all the comments provided by everybody on this thread, perhaps we should
> move on and implement the options that would make pg_ping a better
> wrapper for PQPing. Comments?
Person
On Mon, Nov 26, 2012 at 09:46:33AM -0500, Peter Eisentraut wrote:
> On 11/14/12 9:28 PM, Kevin Grittner wrote:
> > 17. Since the data viewed in an MV is not up-to-date with the
> > latest committed transaction,
>
> So, the way I understand it, in Oracle terms, this feature is a
> "snapshot", not a
On 11/26/2012 09:46 AM, Peter Eisentraut wrote:
On 11/14/12 9:28 PM, Kevin Grittner wrote:
17. Since the data viewed in an MV is not up-to-date with the latest
committed transaction,
So, the way I understand it, in Oracle terms, this feature is a
"snapshot", not a materialized view. Mayb
On Mon, Nov 26, 2012 at 8:14 AM, Marko Tiikkaja wrote:
> First of all, I have to apologize. Re-reading the email I sent out last
> night, it does indeed feel a bit harsh and I can understand your reaction.
>
> At no point did I mean to belittle Kevin's efforts or the patch itself. I
> was mostly
Amit Kapila writes:
> On Monday, November 26, 2012 7:01 PM Heikki Linnakangas wrote:
>> Hmm, if it's just for locking purposes, how about using a lwlock or a
>> heavy-weight lock instead?
> Its not only for lock, the main idea is that we create temp file and write
> modified configuration in that
On 11/14/12 9:28 PM, Kevin Grittner wrote:
> 17. Since the data viewed in an MV is not up-to-date with the latest
> committed transaction,
So, the way I understand it, in Oracle terms, this feature is a
"snapshot", not a materialized view. Maybe that's what it should be
called then.
--
Se
On Monday, November 26, 2012 7:01 PM Heikki Linnakangas wrote:
> On 26.11.2012 14:53, Amit Kapila wrote:
> > I have one usecase in feature (SQL Command to edit postgresql.conf)
> very
> > similar to OpenFile/CloseFile, but I want that when CloseFile is
> called from
> > abort, it should remove(unli
Friday, November 23, 2012 5:38 AM Muhammad Usama wrote:
> Hi Amit
> I have reviewed and tested the patch, Following are my observations and
comments.
Thank you for the review.
I need some clarification regarding some of the comments
> Observations and Comments
> --
On 26.11.2012 14:53, Amit Kapila wrote:
I have one usecase in feature (SQL Command to edit postgresql.conf) very
similar to OpenFile/CloseFile, but I want that when CloseFile is called from
abort, it should remove(unlink) the file as well and during open it has to
retry few times if open is not s
On 26 November 2012 13:07, Robert Haas wrote:
> None of those patches were small patches. It's going to take multiple
> years to get materialized views up to a state where they're really
> useful to a broad audience in production applications, but I don't
> think we should sneer at anyone for wri
On 11/26/12 2:07 PM, Robert Haas wrote:
On Sun, Nov 25, 2012 at 7:30 PM, Marko Tiikkaja wrote:
As others have pointed out, replacing the contents of a table is something
which people have been wanting to do for a long time, and I think having
this ability would make this patch a lot better; now
On Sun, Nov 25, 2012 at 7:30 PM, Marko Tiikkaja wrote:
> As others have pointed out, replacing the contents of a table is something
> which people have been wanting to do for a long time, and I think having
> this ability would make this patch a lot better; now it just feels like
> syntactic sugar
On 25.11.2012 22:55, Alexander Korotkov wrote:
On Tue, Nov 20, 2012 at 1:43 PM, Heikki Linnakangas
wrote:
Glad to see this patch hasn't been totally forgotten. Being able to use
indexes for regular expressions would be really cool!
Back in January, I asked for some high-level description of h
On Friday, November 23, 2012 7:03 PM Heikki Linnakangas
> On 15.11.2012 17:16, Heikki Linnakangas wrote:
> > On 15.11.2012 16:55, Tom Lane wrote:
> >> Heikki Linnakangas writes:
> >>> This is a fairly general issue, actually. Looking around, I can see
> >>> at least two similar cases in existing co
version of the patch.
I fixed bugs in the previous version of the patch. Please find attached an
updated version of the patch.
Thanks,
Best regards,
Etsuro Fujita
copy-popen-20121126.patch
Description: Binary data
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make chan
On 23/11/12 17:24:48 mailto:t...@sss.pgh.pa.us wrote :
> "Cyril VELTER" writes:
> >I follow up on my previous message. Just got two more crash today very
> > similar to the first ones :
>
> > PANIC: could not write to log file 118, segment 237 at offset 2686976,
> > length 5578752: Invali
82 matches
Mail list logo
