On 09/18/2014 09:44 AM, lud...@kni-online.de wrote:
Hi Adrian,
this database runs as develop-version on my PC and was created by hand,
no dumps or pg_upgrade.
The same database runs as production-version on another server
(PostgreSQL 9.3.1, compiled by Visual C++ build 1600, 32-bit), so far
witho
contents.
But I'm curious about what has caused the problems and how to avoid them...
Ludwig
Gesendet: Donnerstag, 18. September 2014 um 15:53 Uhr
Von: "Adrian Klaver"
An: "lud...@kni-online.de" , pgsql-general@postgresql.org
Betreff: Re: [GENERAL] strange p
On 09/18/2014 04:12 AM, lud...@kni-online.de wrote:
Hi Adrian,
data got into the database with normal update/insert-queries from
logged-in database-users using "normal" PG-Users/roles,
the "ghost-roles" (with these unusual numerical role-names) were never
created by me, I don't know where they co
ems?
Ludwig
Gesendet: Mittwoch, 17. September 2014 um 17:33 Uhr
Von: "Adrian Klaver"
An: "lud...@kni-online.de" , pgsql-general@postgresql.org
Betreff: Re: [GENERAL] strange problem with not existing roles
On 09/17/2014 08:08 AM, lud...@kni-online.de wrote:
> Hi list
On 09/17/2014 08:08 AM, lud...@kni-online.de wrote:
Hi list,
I have a strange problem in postgres (PostgreSQL 9.3.1, compiled by
Visual C++ build 1600, 64-bit), there are granted privileges on schemas,
tables, columns for roles that don't exist.
So how did the data get into the database?
Exa
On , Alban Hertroys wrote:
On 30 August 2012 10:12, Condor wrote:
Hello,
can I ask is exist some kind of automatic escape string in
postgresql ?
I use pgsql 9.1.5 and I have very interest problem, I have field
with text
string that I cant find normally.
Here is examples (I replace in examp
On 30 August 2012 10:12, Condor wrote:
> Hello,
> can I ask is exist some kind of automatic escape string in postgresql ?
> I use pgsql 9.1.5 and I have very interest problem, I have field with text
> string that I cant find normally.
> Here is examples (I replace in example Cyrillic encoding bec
BK wrote:
[server complains that wal_level is not set correctly]
>> Did you change the correct postgresql.conf?
>> Are there more than one lines for wal_level in the file
>> (try "grep wal_level postgresql.conf")?
>
> I tried greping, there is just one nstance of it and is set on
archive.
>
> Any
On 11/30/2011 01:43 PM, Tomas Vondra wrote:
On 30 Listopad 2011, 17:23, BK wrote:
Hi Albe,
On Nov 30, 2011, at 2:31 PM, Albe Laurenz wrote:
Verify the current setting with
SELECT setting, source, boot_val, reset_val,
sourcefile, sourceline
FROM pg_settings WHERE name = 'wal_level';
If
On 30 Listopad 2011, 17:23, BK wrote:
> Hi Albe,
>
> On Nov 30, 2011, at 2:31 PM, Albe Laurenz wrote:
>> Verify the current setting with
>>
>> SELECT setting, source, boot_val, reset_val,
>> sourcefile, sourceline
>> FROM pg_settings WHERE name = 'wal_level';
>>
>> If the setting is not right
Hi Albe,
On Nov 30, 2011, at 2:31 PM, Albe Laurenz wrote:
> Verify the current setting with
>
> SELECT setting, source, boot_val, reset_val,
> sourcefile, sourceline
> FROM pg_settings WHERE name = 'wal_level';
>
> If the setting is not right (which is likely the case), try to find out
> t
BK wrote:
> I've spent a couple of hours trying some WAL archiving functionality
on PostgrSQL 9.1 (running on Mac
> OS X). I turned on all the needed options as specified in the
documentation:
>
> wal_level = archive
> archive_mode = on
> archive_command='test ! -f /Volumes/baza/%f && cp %p /Volum
On Sun, Nov 06, 2011 at 09:34:24AM -0500, Tom Lane wrote:
> hubert depesz lubaczewski writes:
> > Any chance of getting the fix in patch format so we could test it on
> > this system?
>
> http://git.postgresql.org/gitweb/?p=postgresql.git;a=patch;h=23998fe99c1220ba3a9eefee194e37ec1f14ae07
hi
jus
hubert depesz lubaczewski writes:
> checked lengths of the text/varchar columns in database.
> there are 16 such columns in the table.
> full report of lengths is in
> http://www.depesz.com/various/lengths.report.gz
> it was obtained using:
> select length( "first_text_column" ) as length_1, cou
On Fri, Nov 04, 2011 at 09:04:02PM -0400, Tom Lane wrote:
> that. And that they are the only rows that, in addition to the above
> conditions, contain data fields wide enough to require out-of-line
> toasting.
checked lengths of the text/varchar columns in database.
there are 16 such columns in
hubert depesz lubaczewski writes:
> Any chance of getting the fix in patch format so we could test it on
> this system?
http://git.postgresql.org/gitweb/?p=postgresql.git;a=patch;h=23998fe99c1220ba3a9eefee194e37ec1f14ae07
regards, tom lane
--
Sent via pgsql-general mail
On Fri, Nov 04, 2011 at 09:04:02PM -0400, Tom Lane wrote:
> Hah ... I have a theory.
>
> I will bet that you recently added some column(s) to the source table
> using ALTER TABLE ADD COLUMN and no default value, so that the added
> columns were nulls and no table rewrite happened. And that these
I wrote:
> A different line of thought is that there's something about these
> specific source rows, and only these rows, that makes them vulnerable to
> corruption during INSERT/SELECT. Do they by any chance contain any
> values that are unusual elsewhere in your table? One thing I'm
> wondering
On Friday, November 04, 2011 6:04:02 pm Tom Lane wrote:
> I wrote:
> > A different line of thought is that there's something about these
> > specific source rows, and only these rows, that makes them vulnerable to
> > corruption during INSERT/SELECT. Do they by any chance contain any
> > values th
On Fri, Nov 04, 2011 at 05:06:35PM -0700, Adrian Klaver wrote:
> Another question.
> Between 07/20/11 and this recent attempt did you do a CREATE TABLE AS on this
> table and not have corrupted rows?
don't remember.
Best regards,
depesz
--
The best thing about modern society is how easy it is
On Fri, Nov 04, 2011 at 05:49:44PM -0400, Tom Lane wrote:
> You said that pg_dump does not show the corruption. That could be
> because the data is coming out through the COPY code path instead of
> the SELECT code path. Could you try a pg_dump with --inserts (which
> will fetch the data with SEL
On Friday, November 04, 2011 3:43:48 pm hubert depesz lubaczewski wrote:
> On Fri, Nov 04, 2011 at 05:49:44PM -0400, Tom Lane wrote:
> > You said that pg_dump does not show the corruption. That could be
> > because the data is coming out through the COPY code path instead of
> > the SELECT code pa
hubert depesz lubaczewski writes:
> On Fri, Nov 04, 2011 at 05:49:44PM -0400, Tom Lane wrote:
>> You said that pg_dump does not show the corruption. That could be
>> because the data is coming out through the COPY code path instead of
>> the SELECT code path. Could you try a pg_dump with --inser
On Fri, Nov 04, 2011 at 05:49:44PM -0400, Tom Lane wrote:
> You said that pg_dump does not show the corruption. That could be
> because the data is coming out through the COPY code path instead of
> the SELECT code path. Could you try a pg_dump with --inserts (which
> will fetch the data with SEL
On Fri, Nov 04, 2011 at 06:18:55PM -0400, Tom Lane wrote:
> BTW, did you try the separate INSERT/SELECT yet? Does that show
> corruption?
pg_dump --inserts is still working.
i did create table (like), insert into ... select and it also shows the
problem, as I showed (with other data) in email:
2
I wrote:
> Good detective work. So now we at least have a believable theory about
> *what* is happening (something is stomping the first 8 data bytes of
> these particular rows), if not *why*.
Scratch that: something is stomping the first *six* bytes of data.
On a hunch I converted the original a
On Fri, Nov 04, 2011 at 05:49:44PM -0400, Tom Lane wrote:
> You said that pg_dump does not show the corruption. That could be
> because the data is coming out through the COPY code path instead of
> the SELECT code path. Could you try a pg_dump with --inserts (which
> will fetch the data with SEL
hubert depesz lubaczewski writes:
> OK. So based on it all, it looks like for some rows, first two columns got
> mangled.
Good detective work. So now we at least have a believable theory about
*what* is happening (something is stomping the first 8 data bytes of
these particular rows), if not *w
On 11/04/2011 01:47 PM, hubert depesz lubaczewski wrote:
On Fri, Nov 04, 2011 at 01:43:55PM -0700, Adrian Klaver wrote:
Does it tell you anything?
You are very thorough.
I hate mysteries. Especially the ones that break stuff.
Know the feeling.
I don't know enough about Postgres internal
On Fri, Nov 04, 2011 at 01:43:55PM -0700, Adrian Klaver wrote:
> >Does it tell you anything?
> You are very thorough.
I hate mysteries. Especially the ones that break stuff.
> I don't know enough about Postgres internals to be much help there.
> All I can point out is the problem seemed to appear
On 11/04/2011 01:17 PM, hubert depesz lubaczewski wrote:
On Thu, Nov 03, 2011 at 11:03:45PM +0100, hubert depesz lubaczewski wrote:
looking for some other info. will post as soon as i'll gather it, but
that will be in utc morning :(
I looked closer at the rows that got -1 xobject_id.
Does
On Thu, Nov 03, 2011 at 11:03:45PM +0100, hubert depesz lubaczewski wrote:
> looking for some other info. will post as soon as i'll gather it, but
> that will be in utc morning :(
I looked closer at the rows that got -1 xobject_id.
$ select magic_id, count(*) from qqq where xobject_id = -1 group
On Thu, Nov 03, 2011 at 06:02:04PM -0400, Tom Lane wrote:
> select * from pg_attribute where attrelid = 'sss.xobjects'::regclass
> and attisdropped;
no dropped columns.
looking for some other info. will post as soon as i'll gather it, but
that will be in utc morning :(
Best regards,
depesz
hubert depesz lubaczewski writes:
> i tried:
> create table qqq as select cmax as o_cmax, xmax as o_xmax, cmin as
> o_cmin, xmin as o_xmin, ctid as o_ctid, * from sss.xobjects;
> but the resulting table didn't have -1 values:
Oh, that's pretty interesting ... suggests that the targetlist has
> I would like to know the ctid's of the -1 rows in the copied table,
> along with the ctid's of the rows they share magic_ids with, and
> the ctid's of the rows with those same magic_ids in the original.
> I'm wondering whether the affected rows are physically clustered ...
i tried:
create table
Adrian Klaver writes:
> On Thursday, November 03, 2011 1:03:12 pm hubert depesz lubaczewski wrote:
>> as you can see counts of rows in created table are more or less
>> sensible, but whatever method I used - create table as, insert into,
>> using sychronized_scans (initially) or not (later) - copy
On Thursday, November 03, 2011 1:03:12 pm hubert depesz lubaczewski wrote:
> On Thu, Nov 03, 2011 at 10:55:20AM -0400, Tom Lane wrote:
>
> So, did some tests:
>
> as you can see counts of rows in created table are more or less
> sensible, but whatever method I used - create table as, insert int
On Thu, Nov 03, 2011 at 10:55:20AM -0400, Tom Lane wrote:
> hubert depesz lubaczewski writes:
> > index on xobject_id might be corrupted, but it doesn't explain that I
> > don't see duplicates with group_by/having query on xobjects, which uses
> > seqscan:
>
> I was just going to ask you to check
On Thursday, November 03, 2011 8:30:34 am hubert depesz lubaczewski wrote:
> On Thu, Nov 03, 2011 at 08:23:01AM -0700, Adrian Klaver wrote:
> > On Thursday, November 03, 2011 8:05:38 am hubert depesz lubaczewski wrote:
> > > On Thu, Nov 03, 2011 at 08:04:19AM -0700, Adrian Klaver wrote:
> > > > So
hubert depesz lubaczewski writes:
> other tests are running, but simple question - how to get number of rows
> affected from psql?
> create table xxx as select * from xobjects;
> returns just:
> SELECT
We fixed that in 9.0, but 8.4 won't provide the count (unless you care to
patch it). That's w
On Thu, Nov 03, 2011 at 08:23:01AM -0700, Adrian Klaver wrote:
> On Thursday, November 03, 2011 8:05:38 am hubert depesz lubaczewski wrote:
> > On Thu, Nov 03, 2011 at 08:04:19AM -0700, Adrian Klaver wrote:
> > > So just to be clear there is and never has been a -1 value for xobject_id
> > > in the
On Thu, Nov 03, 2011 at 04:21:37PM +0100, Alban Hertroys wrote:
> On 3 November 2011 09:25, hubert depesz lubaczewski wrote:
> > All looks good. pg_dump of the table also doesn't show any strange
> > problems, and is duplicate free. But:
> >
> > $ create table zzz as select * from sss.xobject
On Thursday, November 03, 2011 8:05:38 am hubert depesz lubaczewski wrote:
> On Thu, Nov 03, 2011 at 08:04:19AM -0700, Adrian Klaver wrote:
> > So just to be clear there is and never has been a -1 value for xobject_id
> > in the source table?
>
> yes. min value of xobject_id is 1000, and we had tr
On 3 November 2011 09:25, hubert depesz lubaczewski wrote:
> All looks good. pg_dump of the table also doesn't show any strange problems,
> and is duplicate free. But:
>
> $ create table zzz as select * from sss.xobjects;
> SELECT
>
> $ select xobject_id, count(*) from zzz group by 1 having c
On Thu, Nov 03, 2011 at 08:04:19AM -0700, Adrian Klaver wrote:
> So just to be clear there is and never has been a -1 value for xobject_id in
> the
> source table?
yes. min value of xobject_id is 1000, and we had trigger in place on the
table which logged all inserts/updates/deletes and the val
On Thursday, November 03, 2011 7:15:22 am hubert depesz lubaczewski wrote:
> On Thu, Nov 03, 2011 at 07:00:30AM -0700, Adrian Klaver wrote:
> > > I also verified that there are no concurrent updates that would set
> > > xobject_id to -1, so it's not a problem of isolation.
> > >
> > > During the n
On Thu, Nov 03, 2011 at 10:55:20AM -0400, Tom Lane wrote:
> > index on xobject_id might be corrupted, but it doesn't explain that I
> > don't see duplicates with group_by/having query on xobjects, which uses
> > seqscan:
> I was just going to ask you to check that. Weird as can be.
> Does plain ol
hubert depesz lubaczewski writes:
> index on xobject_id might be corrupted, but it doesn't explain that I
> don't see duplicates with group_by/having query on xobjects, which uses
> seqscan:
I was just going to ask you to check that. Weird as can be.
Does plain old "SELECT COUNT(*)" show a diff
On Thu, Nov 03, 2011 at 03:19:36PM +0100, Alban Hertroys wrote:
> On 3 November 2011 15:15, hubert depesz lubaczewski wrote:
> >> Do the xobject_id values have other negative numbers or is -1 just a
> >> special
> >> case? The only thing I can think of is a corrupted index on xobject_id.
> >
> >
On 3 November 2011 15:15, hubert depesz lubaczewski wrote:
>> Do the xobject_id values have other negative numbers or is -1 just a special
>> case? The only thing I can think of is a corrupted index on xobject_id.
>
> minimal xobject_id in source table is 1000.
>
> index on xobject_id might be cor
On Thu, Nov 03, 2011 at 07:00:30AM -0700, Adrian Klaver wrote:
> > I also verified that there are no concurrent updates that would set
> > xobject_id to -1, so it's not a problem of isolation.
> >
> > During the night I repeated the procedure and the rows that got duplicated
> > seem to be the sam
On Thursday, November 03, 2011 1:25:58 am hubert depesz lubaczewski wrote:
> Hi
> We have pretty weird situation, which seems to be impossible, but perhaps
> you'll notice something that will let me fix the problem.
>
> System: SunOS 5.11 snv_130
> Pg: PostgreSQL 8.4.7 on i386-pc-solaris2.11,
On Jul 9, 2007, at 9:22 AM, Gustavo Ces wrote:
Hi all,
I´ve got a strange problem, hope you could help. I´ve got a
table (a ) with n tuples, and two fields , birthplace and birth
date. There´s another table ( say b) with m tuples, where i´ve got
a lot of polygons ( with their code, sam
> > One other thing about our particular setup is that we use separate
> > schema's for all user data and the functions go in the public schema.
> > So before executing this function we issue something like 'set_path to
> > username,public'.
>
> Mph. Are you expecting the function to work for mor
snacktime <[EMAIL PROTECTED]> writes:
> I have a very strange issue that I'm not sure how to debug.
Hm, are you certain there is always only one row for each value of
s_oid? This command:
> status := active from recurbilling_transactions where s_oid = in_s_oid;
is going to give you a random one
On Fri, 17 Nov 2000, Robert D. Nelson wrote:
> Try uninstalling everything related to postgres that is now installed. Then
> remove /var/lib/pgsql and any data directories that may exist. Start from
> scratch. Oh, and as to order? I just installed them all together, like "rpm
> -ivh postgresql-7.
Rich Shepard wrote:
> Thanks, Lamar. I upgraded the server package, and that appeared to work
> just fine. Then I installed the others. Is 'initdb' the proper way to
> restart everything, and creat a new /var/lib/pgsql? It's been a while since
> I worked with postgres, but I need to really dig i
> I actually do understand the differences among -i (install) -U (upgrade)
>and -F (freshen). What I don't understand is why what _should_ work _isn't_
>working.
>
> For example, as Lamar and others suggested:
>
>[root@salmo rshepard]# rpm -qa | grep postgres
>postgresql-server-6.5.3-1
>postgres
On Fri, 17 Nov 2000, Lamar Owen wrote:
> Once you have verified with rpm -qa|grep postgres that there are no more
> postgresql RPM's on your system, then you will need to clean out the old
> 6.5.3 data directory (rm -rf /var/lib/pgsql).
>
> Now you should be able to install the new RPMset.
Tha
Rich Shepard wrote:
> On Thu, 16 Nov 2000, Lamar Owen wrote:
> > The result of 'rpm -qa|grep postgres' would be educational here.
> [root@salmo rshepard]# rpm -qa | grep postgres
> postgresql-server-6.5.3-1
> postgresql-test-6.5.3-1
> postgresql-7.0.3-2
> "Aha, I said. The rpm database thinks
On Thu, 16 Nov 2000, Lamar Owen wrote:
> The result of 'rpm -qa|grep postgres' would be educational here.
I actually do understand the differences among -i (install) -U (upgrade)
and -F (freshen). What I don't understand is why what _should_ work _isn't_
working.
For example, as Lamar and o
On Wed, 15 Nov 2000, Lamar Owen wrote:
> Use --nodeps to override dependencies. It is complaining because RPM
> apparently has no record of /lib/cpp -- rpm --rebuilddb may be needed.
> RPM's dependencies are not checked against the filesystem, but against
> the RPM database. You can verify this
Rich Shepard wrote:
> So, can someone please explain to me why the 7.0.3-1 package complains
> that /lib/cpp isn't there when it is? FWIW, I got the same error when I
> tried using the --force switch with rpm. Something's screwy here.
Use --nodeps to override dependencies. It is complaining be
63 matches
Mail list logo
